Комментарии 19
Хорошая сборка, спасибо.
отлично… как раз приходится начинать изучение :)
тогда сборкам нет
Да, изучать лучше начинать с самой минимальной конфигурации, Джангу — лучше без сборки.
Сборку с buildout мне показали в проекте, где я работал. Когда понадобилось сделать её самому, я долго мучался и правил чужие, но в конце концов взял и прочитал доки, начиная с самой простой конфиуграции.
Сборку с buildout мне показали в проекте, где я работал. Когда понадобилось сделать её самому, я долго мучался и правил чужие, но в конце концов взял и прочитал доки, начиная с самой простой конфиуграции.
Уф… Мне бы, самое основное, мозг сломать в сторону окружений Python'a после «пыха»… это самое сложное у меня по ходу. Само программирование, более-менее прозрачное, пробовал просто уже. Выбрал тут небольшой проектик и пытаюсь его написать, вместо переписывания очередного «бложика» из документации. В любом случае пасиба! :)
Тогда могу посоветовать писать реальный проект, сборка поможет. А чтобы разбираться в Джанге, можно задавать вопросы, искать готовые пакеты. Их можно подключать в buildout.cfg. А если чего-то не хватает, писать самому. Для этого надо лезть в исходники самой Джанги, чтобы понять, что и как дорабатывать.
Спасибо большой за статью. Не знал, что уже появилось нечто вроде HamlPy. Думал, что по-прежнему есть только не сильно юзабельный shpaml.
Копнул чуть глубже и открыл для себя djaml (https://github.com/chartjes/djaml), который позволяет интегрировать HamlPy в Django, то есть по сути приближайет поддержку HAML в Django к виду, аналогичному RoR. На мой взгляд за этим будущее. Там пока, судя по всему, есть проблемы, например шаблоны не кешируются. Вы не пробовали использовать djaml?
Копнул чуть глубже и открыл для себя djaml (https://github.com/chartjes/djaml), который позволяет интегрировать HamlPy в Django, то есть по сути приближайет поддержку HAML в Django к виду, аналогичному RoR. На мой взгляд за этим будущее. Там пока, судя по всему, есть проблемы, например шаблоны не кешируются. Вы не пробовали использовать djaml?
Насчет использования Make — ужас. Вы просто заменили одни команды, другими.
Нет, не ужас. Вместо последовательного набора
python bootstrap.py --distribute
bin/buildout
bin/django rebuilddb (или syncdb)
я просто делаю
make rebuilddb
Кричать «ужас» всякий умеет. Если у вас есть другое, элегантное решение, присылайте, применим.
python bootstrap.py --distribute
bin/buildout
bin/django rebuilddb (или syncdb)
я просто делаю
make rebuilddb
Кричать «ужас» всякий умеет. Если у вас есть другое, элегантное решение, присылайте, применим.
alias rebuilddb='python bootstrap.py --distribute;bin/buildout;bin/django rebuilddb'
Я же предпочитаю fabric. писать fab на 1 символ меньше чем make :D
Я же предпочитаю fabric. писать fab на 1 символ меньше чем make :D
Также давным давно использую Makefile для шорткатов на действия с проектом. Что в этом плохого?
Не только шорткаты, ещё можно прописывать зависимости (вот документация).
Делать команды — фигня. Можно shell скрипт тогда накатать, разницы ни какой. А вот если бы сделали для make all зависимость от языков, что бы если языки меняются то пересобирало при деплое — другое дело. (ну и всякие такие вот мелочи-вкусности)
all: mo
buildout foo
mo: local/ru/.../app.po
bin/django compilemessagesВот пример:
run: bin/django syncdb bin/sass
bin/django runserver 0.0.0.0:8000
Команда run запускает разработческий сервер, но перед этим проверяет, установлен ли скрипт django, сделан ли syncdb, есть ли sass. Если их нет, они устанавливаются.
При этом её можно запускать сразу как только склонировали репозиторий:
$ hg clone…
$ cd myproject
$ make run
После этого их при желании можно вручную обновить:
make bin/sass
вызовет скрипт, который переустановит рубёвый пакет sass. Ну и другие зависимости.
Конечно, можно завести шеллскрипты и на них всё делать, но тогда каждый раз вам придётся проверять, всё ли установлено, или что-то надо обновить. Не знаю, как остальные, а я по незнанию когда-то написал такую выполнялку обновлений на питоне. Только оказалось, что это намного сложнее, чем кажется, и она не работала как надо. Поэтому там, где есть последовательности операций и зависимости, разумно будет полагаться на makefile.
run: bin/django syncdb bin/sass
bin/django runserver 0.0.0.0:8000
Команда run запускает разработческий сервер, но перед этим проверяет, установлен ли скрипт django, сделан ли syncdb, есть ли sass. Если их нет, они устанавливаются.
При этом её можно запускать сразу как только склонировали репозиторий:
$ hg clone…
$ cd myproject
$ make run
После этого их при желании можно вручную обновить:
make bin/sass
вызовет скрипт, который переустановит рубёвый пакет sass. Ну и другие зависимости.
Конечно, можно завести шеллскрипты и на них всё делать, но тогда каждый раз вам придётся проверять, всё ли установлено, или что-то надо обновить. Не знаю, как остальные, а я по незнанию когда-то написал такую выполнялку обновлений на питоне. Только оказалось, что это намного сложнее, чем кажется, и она не работала как надо. Поэтому там, где есть последовательности операций и зависимости, разумно будет полагаться на makefile.
Не понимаю при чем тут тогда make, если он вызовет все равно скрипт который проверит у установит зависимости. Что я имел ввиду я описал в комментарии выше. А просто делать прослойку из make которая одни команды заменит другими — чур меня.
Так в том-то и дело, что make здесь не просто прослойка для замены скриптов. Зависимости в виде яиц питона — это одно, а зависимости операций внутри проекта — это другое.
syncdb можно делать только после того как есть скрипт bin/django. Поэтому в Makefile есть такое правило:
syncdb: bin/django
bin/django syncdb
touch syncdb
(touch делает файл, который как метка времени)
поэтому, повторяю, если у меня есть makefile, я могу склонировать проект и сразу запускать, например, syncdb. Make увидит, что нет bin/django и запустит развёртывание проекта.
Вы посмотрите в исходники прежде чем хаять.
syncdb можно делать только после того как есть скрипт bin/django. Поэтому в Makefile есть такое правило:
syncdb: bin/django
bin/django syncdb
touch syncdb
(touch делает файл, который как метка времени)
поэтому, повторяю, если у меня есть makefile, я могу склонировать проект и сразу запускать, например, syncdb. Make увидит, что нет bin/django и запустит развёртывание проекта.
Вы посмотрите в исходники прежде чем хаять.
У каждого разработчика со временем подобный шаблон появляется, который он использует для своих проектов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Шаблон проекта на Джанго с инструментами сборки и утилитами