Комментарии 77
Полагаю, что этот релиз станет существенным толчком для развития Python 3.
Как только mysql-python портируют. Не все готовы разворачивать PGSQL.
По опыту, mysql-python стоит забыть, как страшный сон. PyMySQL наш новый друг. Даже поддержку в South недавно добавили.
Есть замечательный проект oursql. Он поддерживает Python3 и для него есть django-backend. В продакшене и под нагрузкой не пользовался, но теоретически особых отличий быть не должно.
Какая пробелма перейти на pg?
Покамест современные серверные дистрибутивы Linux не работают на py3k, так что использовать в проде не стал бы.
Более того, пока еще много критических «батареек» не портировано, либо будут портированы с убитием обратной совместимости.
А по новости: ждем 1.5.1 и тогда уже перейдем :)
Более того, пока еще много критических «батареек» не портировано, либо будут портированы с убитием обратной совместимости.
А по новости: ждем 1.5.1 и тогда уже перейдем :)
ArchLinux использует Python3 по умолчанию уже больше года. Или это не серверный дистрибутив? (я просто не очень понимаю, что значит «серверный»)
Как верно заметили ниже — а как же PIL/Pillow/pylibmc/South? Для полноценного django-стека их очень не хватает, так что переход на py3k пока что откладывается.
Из всего того что вы сказали, я соглашусь только про South. (да и то, не совсем)
А для работы с картинками есть много альтернатив, разной степени готовности.
— Python3 пока не подходит для production. Но начинать на нем новые проекты, целью которых будет выход через год-полтора. Можно и нужно уже сейчас.
А для работы с картинками есть много альтернатив, разной степени готовности.
— Python3 пока не подходит для production. Но начинать на нем новые проекты, целью которых будет выход через год-полтора. Можно и нужно уже сейчас.
Незарелизенный Pillow из репозитория вполне под 3.х работает (с мелкими недочетами, правда — к примеру, exif данные из jpeg не читаются); незарелизенный South из официального репозитория ( bitbucket.org/andrewgodwin/south/overview ) — вроде как тоже должен.
Как уже отметил выше, PIL для Python 3.x есть порт. Отлично работает у нас на продакшене.
Centos 7 c py3k летом, а Debian Wheezy уже больше чем пол года «заморожен» — новая эра не за горами!
С дебианом, кстати, отдельный вопрос — судя по всему, 1.5 в стэйбл уже не попадет, а к следующему — уже 1.6 подтянется. Поэтому для тех, кто ставит питоньи пакеты из деб-пакетов придется скакать через 2 версии.
Собственно, переход с Debian Squeeze на Debian Wheezy = изменение версии Django с 1.2 на 1.4.
Странные люди без virtualenv.
Поправил :)
В этом нет ничего странного. Дебиановский стэйбл намного стабильней, нежели pypi. Кроме того, виртуалэнвы несколько перечат правилам установки питоньих пакетов в дебиане (согласно инструкции). Плюс, деб-пакеты несколько удобней в плане разрешения зависимостей.
Что значит «Дебиановский стэйбл намного стабильней, нежели pypi»? Хочу пояснений с примерами не стабильности pypi.
P.S. Намекну: pip freeze
P.S. Намекну: pip freeze
Ах да, ещё покажу вот это: github.com/utahta/pythonbrew А то в стабильном дебиане до сих пор 2.6…
Виртуаленвы не перечат дебиану, так как собираются у пользователя и не срут в систему. В обшем, нет с ними проблем.
Виртуаленвы не перечат дебиану, так как собираются у пользователя и не срут в систему. В обшем, нет с ними проблем.
Не работает только всякий антиквариат, который и на сервере то держать опасно.
Pil/Pillow, pylibmc — когда будет поддержка для тройки не известно, а так же на данный момент South тоже не работает. Ложка дегтя при переносе это что для тройки force_unicode стал force_text.
Таки чем-то меня цепляет команда «пип шоу» как на скриншоте ))
А вы уверены в истинности результатов второго опроса? Я лично отметил все три галочки, потому что опрос позволяет =)
Блин, я думал у меня терминал открыт
Очень радостная весть! Настраиваемая модель пользователя User особенно порадовала, теперь процесс работы гораздо удобней будет.
На 3000 только года через два. Да и не ясно до конца, какой профит от перехода на py3?
OFF: Тень у окошка убойная. Сами делали?
Ура.
Воистину ура.
Можно приступать к отложенным было до неопределённого времени частям проектов, требующим работы с пользователями.
И вот что совсем-совсем приятно, так это тэг {% verbatim %}.
Ну и что, что сторонним решением он давно уже был, зато теперь можно обходиться штатными тэгами при использовании всяких js-шаблонов.
Воистину ура.
Можно приступать к отложенным было до неопределённого времени частям проектов, требующим работы с пользователями.
И вот что совсем-совсем приятно, так это тэг {% verbatim %}.
Ну и что, что сторонним решением он давно уже был, зато теперь можно обходиться штатными тэгами при использовании всяких js-шаблонов.
Verbatim можно было сделать быстро так, но в 1.5 реализовано было чуть сложнее.
Django 1.5 стал первым релизом с поддержкой питона 3 версии (3.2 и выше). Стоит обратить внимание, что поддержка пока только экспериментальная, [...]
На прошлой неделе Джейкоб забегал, рассказал про «экспериментальность» — github.com/idlesign/django-sitetree/pull/93#issuecomment-13890792
Спасибо за комментарий, вносит ясность.
Промахнулся. Должно было быть ответом на:
На прошлой неделе Джейкоб забегал, рассказал про «экспериментальность» — github.com/idlesign/django-sitetree/pull/93#issuecomment-13890792
Промахнулся. Должно было быть ответом на:
На прошлой неделе Джейкоб забегал, рассказал про «экспериментальность» — github.com/idlesign/django-sitetree/pull/93#issuecomment-13890792
Собственно отлаживаю новый проект на Python 3.2 ещё до беты с дев версии. Сильно глубоко не забирался, но пока всё работает стабильно.
> Как скоро вы планируете перейти на django 1.5?
Не нашёл варианта «ХЗ, меня и в django 1.3 всё устраивает»
Не нашёл варианта «ХЗ, меня и в django 1.3 всё устраивает»
Были ли у вас проблемы с моделью User?
Нет, просто прикручиваю модель профиля через OneToOneField поле
А через юзер менеджер в саб модели профиля?
class Account(User):
city = models.CharField(verbose_name=«Город»)
phone = models.CharField(verbose_name=«телефон»)
objects = UserManager()
З.Ы. Джанга 1.4
class Account(User):
city = models.CharField(verbose_name=«Город»)
phone = models.CharField(verbose_name=«телефон»)
objects = UserManager()
З.Ы. Джанга 1.4
Не знаю, что это такое, у меня всё уже много лет через OneToOneField прекрасно работает.
docs.djangoproject.com/en/dev/ref/contrib/auth/#manager-methods
Удобная вещь если честно. Создаём класс доп модели (расширенный профиль), наследуем от модели
from django.contrib.auth.models import User
В модели прописываем дополнительные поля, к примеру город, пол, телефон etc
Указываем в ней objects = UserManager()
Который берётся из
from django.contrib.auth.models import UserManager
И всё… Классический объект User будет обладать объектами из вашего саб класса.
И уже можно обращаться.
request.user.username
request.user.email
request.user.account.phone
При этом в БД, данная модель будет без ИД класического, а будет сразу с связью на ИД в модели User.
python manage.py sqlall account
Посмотрите на вариант выдачи
Удобная вещь если честно. Создаём класс доп модели (расширенный профиль), наследуем от модели
from django.contrib.auth.models import User
В модели прописываем дополнительные поля, к примеру город, пол, телефон etc
Указываем в ней objects = UserManager()
Который берётся из
from django.contrib.auth.models import UserManager
И всё… Классический объект User будет обладать объектами из вашего саб класса.
И уже можно обращаться.
request.user.username
request.user.email
request.user.account.phone
При этом в БД, данная модель будет без ИД класического, а будет сразу с связью на ИД в модели User.
python manage.py sqlall account
Посмотрите на вариант выдачи
Ещё можно манкипатчить её, хорошо работает.
Кто нибудь в курсе South когда будет поддерживаться?
в смысле добавят в contrib?
Слава Аллаху, никогда не добавят. Это пару лет назад обсуждали…
А что страшного случится, если south добавят в контриб?
Да нечего ему там делать. Не самое хорошее приложение с кодом хуже, чем в самой джанге (а это редкость).
В общем, это плохо сочитается с монолитностью джанги, так как syncdb ничего не знает про миграции и знать не должен, ибо они далеко не всегда нужны и часто создают больше проблем, чем пользы.
В общем, это плохо сочитается с монолитностью джанги, так как syncdb ничего не знает про миграции и знать не должен, ибо они далеко не всегда нужны и часто создают больше проблем, чем пользы.
syncdb знает, есть ключик --migrate
Уже 2-3 года юзаю south, даже не знаю, чтобы я без него делал.
Какие-то грабли раньше были, сейчас разобрался и всё работает отлично.
Уже 2-3 года юзаю south, даже не знаю, чтобы я без него делал.
Какие-то грабли раньше были, сейчас разобрался и всё работает отлично.
Так, ещё раз, syncdb ничего про миграции не знает. А то, что какая-то библиотечка переопределяет стандартные manage-команды, то это плохой тон и повод оторвать руки разработчикам. Обрати внимание на количество разных мигралок для джанги. Соус не нравится не только мне…
Я знаю вот уже все команды джангистов, котороые осознано отказалась отказались. Лично я считаю, что использовать соус можно только до продакшена. На продакшене безопаснее мигрировать руками.
Я знаю вот уже все команды джангистов, котороые осознано отказалась отказались. Лично я считаю, что использовать соус можно только до продакшена. На продакшене безопаснее мигрировать руками.
Давай конкретные описания историй, когда south чего-то запорол. Мне интересно. Шаблон истории:
* есть такое-то состояние системы
* меняем модели
* создаём миграцию
*…
* south всё испортил
* есть такое-то состояние системы
* меняем модели
* создаём миграцию
*…
* south всё испортил
Изменилось имя поля. Что делает соус? Правильно, удаляет старое и создаёт новое. Чтобы сделать альтертабл руками, надо знать об этой особенности. В моей практике были такие ошибки у средне опытных программистов, ибо это нихрена не очевидно. Слава великой Бжне, до продакшена дело не доходило. И ведь реально, после сдачи проекта в поддержку, там вполне могут оказаться программисты, которые с такой траблой не сталкивались. Впрочем, PEP-20 (Explicit is better than implicit) вообще чужд джанге и большенству её приложений…
Дальше спорить не буду. Если вы не понимаете, что миграции реально нужны не всегда, а введение их в джангу, лишь усложнит её, то и говорить с вами нечего.
P.S. Про качество кода самого соуса я уже высказывался. Мне не раз приходилось его ковырять и это реально ад… Хотя поймут это, наверное, только питонщики, а никак не джангисты.
P.P.S. Свой шаблон можешь распечатать и съесть. Не люблю необоснованую дерзость.
Дальше спорить не буду. Если вы не понимаете, что миграции реально нужны не всегда, а введение их в джангу, лишь усложнит её, то и говорить с вами нечего.
P.S. Про качество кода самого соуса я уже высказывался. Мне не раз приходилось его ковырять и это реально ад… Хотя поймут это, наверное, только питонщики, а никак не джангисты.
P.P.S. Свой шаблон можешь распечатать и съесть. Не люблю необоснованую дерзость.
> Изменилось имя поля. Что делает соус? Правильно, удаляет старое и создаёт новое
Так это и есть explicit is better than implicit Вот если бы south угадывал, что поле сменило имя, то это было бы implicit
Я вообще поля переименовываю так: создаю новое поле, далее отдельной data миграцией переношу данные и затем новой миграцией удаляю старое поле.
> Дальше спорить не буду
С тобой никто не спорит, это ты сам придумал. Я просто спрашивал у тебя твоё мнение про south, я ни в чём тебя не убеждаю.
> Если вы не понимаете, что миграции реально нужны не всегда, а введение их в джангу, лишь усложнит её, то и говорить с вами нечего.
Я не говорил, что миграции нужны всегда, ты это придумал. Я не говорил, что south надо вводить в джангу, ты это придумал.
> P.P.S. Свой шаблон можешь распечатать и съесть. Не люблю необоснованую дерзость
Пока в этом топике дерзость только за тобой замечена.
Так это и есть explicit is better than implicit Вот если бы south угадывал, что поле сменило имя, то это было бы implicit
Я вообще поля переименовываю так: создаю новое поле, далее отдельной data миграцией переношу данные и затем новой миграцией удаляю старое поле.
> Дальше спорить не буду
С тобой никто не спорит, это ты сам придумал. Я просто спрашивал у тебя твоё мнение про south, я ни в чём тебя не убеждаю.
> Если вы не понимаете, что миграции реально нужны не всегда, а введение их в джангу, лишь усложнит её, то и говорить с вами нечего.
Я не говорил, что миграции нужны всегда, ты это придумал. Я не говорил, что south надо вводить в джангу, ты это придумал.
> P.P.S. Свой шаблон можешь распечатать и съесть. Не люблю необоснованую дерзость
Пока в этом топике дерзость только за тобой замечена.
Я согласен, что если бы он угадывал переименование, то это было бы ещё хуже. Но, блин, это же такая почва для ошибок, что лучше десять раз подумать, чем вообще вводить в проект такой инструмент.
> Я вообще поля переименовываю так: создаю новое поле, далее отдельной data миграцией переношу данные и затем новой миграцией удаляю старое поле.
Вот это жесть… А вместо mv делаешь cp и rm?
> Я не говорил, что миграции нужны всегда, ты это придумал. Я не говорил, что south надо вводить в джангу, ты это придумал.
Не, ну можно конечно сказать, что это я придумал, но это не очень хорошо выглядет после слов «А что страшного случится, если south добавят в контриб?». Вот вроде бы и придумал, а на деле, просто задродство, уродство и цепляние к словам. И это я не придумал. Надеюсь не встретиться с тобой в реале, удачи!
> Я вообще поля переименовываю так: создаю новое поле, далее отдельной data миграцией переношу данные и затем новой миграцией удаляю старое поле.
Вот это жесть… А вместо mv делаешь cp и rm?
> Я не говорил, что миграции нужны всегда, ты это придумал. Я не говорил, что south надо вводить в джангу, ты это придумал.
Не, ну можно конечно сказать, что это я придумал, но это не очень хорошо выглядет после слов «А что страшного случится, если south добавят в контриб?». Вот вроде бы и придумал, а на деле, просто задродство, уродство и цепляние к словам. И это я не придумал. Надеюсь не встретиться с тобой в реале, удачи!
> Но, блин, это же такая почва для ошибок, что лучше десять раз подумать, чем вообще вводить в проект такой инструмент.
> На продакшене безопаснее мигрировать руками.
А ты думаешь, если ты руками делаешь изменение схемы базы данных, то это не почва для ошибок?
> Вот это жесть… А вместо mv делаешь cp и rm?
Да честно говоря, я уже не помню когда последний раз колонку переименовывал в south Ну, скажем, если бы я работал с таблицей, содержащей миллионы строк, я бы уже задумался, как именно делать миграцию, может быть использовал бы функцию rename_column, если бы это помогло избежать изменения данных на диске.
Для очень больших таблиц south может оказаться бесполезным, например, добавление новой колонки или update значений в старой с помощью data migration может затянуться на часы и дни, если данных много. Поэтому там уже надо использовать более продвинутые методики: например копировать таблицу с данными, отключать индексы, добавлять новую колонку или update делать колонки и потом новые данные пихать в старую таблицу или переключать софт на использование новой таблицы.
> Вот вроде бы и придумал, а на деле, просто задродство, уродство и цепляние к словам. И это я не придумал.
Ты дурачком то не прикидывайся. Твои слова выше: «Если вы не понимаете, что миграции реально нужны не всегда, а введение их в джангу, лишь усложнит её, то и говорить с вами нечего.». Я не писал, что миграции нужны всегда. Я не писал, что введение их в джангу не усложнит оную. Ты это придумал. Это факт.
Ты бы лучше по делу писал, пока вижу только эмоции.
> На продакшене безопаснее мигрировать руками.
А ты думаешь, если ты руками делаешь изменение схемы базы данных, то это не почва для ошибок?
> Вот это жесть… А вместо mv делаешь cp и rm?
Да честно говоря, я уже не помню когда последний раз колонку переименовывал в south Ну, скажем, если бы я работал с таблицей, содержащей миллионы строк, я бы уже задумался, как именно делать миграцию, может быть использовал бы функцию rename_column, если бы это помогло избежать изменения данных на диске.
Для очень больших таблиц south может оказаться бесполезным, например, добавление новой колонки или update значений в старой с помощью data migration может затянуться на часы и дни, если данных много. Поэтому там уже надо использовать более продвинутые методики: например копировать таблицу с данными, отключать индексы, добавлять новую колонку или update делать колонки и потом новые данные пихать в старую таблицу или переключать софт на использование новой таблицы.
> Вот вроде бы и придумал, а на деле, просто задродство, уродство и цепляние к словам. И это я не придумал.
Ты дурачком то не прикидывайся. Твои слова выше: «Если вы не понимаете, что миграции реально нужны не всегда, а введение их в джангу, лишь усложнит её, то и говорить с вами нечего.». Я не писал, что миграции нужны всегда. Я не писал, что введение их в джангу не усложнит оную. Ты это придумал. Это факт.
Ты бы лучше по делу писал, пока вижу только эмоции.
> А ты думаешь, если ты руками делаешь изменение схемы базы данных, то это не почва для ошибок?
Ошибиться можно везде, но когда ты вдумчиво описываешь миграцию, вероятность ошибки куда ниже, чем с помощью соуса.
Для очень больших таблиц, понятное дело, надо выдумывать серьёзный велосипед. И, кстати, вот ещё одна проблема: многие ли задумаются о том, что сделал соус и сколько времени оно будет отрабатывать? Как показывает практика, не многие.
Ошибиться можно везде, но когда ты вдумчиво описываешь миграцию, вероятность ошибки куда ниже, чем с помощью соуса.
Для очень больших таблиц, понятное дело, надо выдумывать серьёзный велосипед. И, кстати, вот ещё одна проблема: многие ли задумаются о том, что сделал соус и сколько времени оно будет отрабатывать? Как показывает практика, не многие.
Я думаю, всё упирается в культуру и опыт разработчика(разработчиков в команде). Вменяемые люди смогут сделать миграции как с south, так и без него, смогут понять, когда south не нужно использовать а мастер-ломастеры или просто новички везде дров наломают.
Я лично south использую во всех проектах, он существенно экономит время, особенно на стадии разработки прототипа, я даже обленился и сделал fabric команду:
В консоли просто пишу fab automig:someapp и получаю новую схему, автоматически изменённую под новую структуру моделей.
Ещё при работе с south имеет смысл периодически удалять старые миграции, смысла которые хранить особо нет и делать новую initial миграцию
Сейчас изучаю алхимию, меня дико ломает отсутствие south-миграций. Нашёл alembic, разбираюсь с ним потихоньку. Он тоже умеет автогенерацию миграций делать.
Я лично south использую во всех проектах, он существенно экономит время, особенно на стадии разработки прототипа, я даже обленился и сделал fabric команду:
def automig(name):
"""
Create auto south migration and apply it to database.
"""
api.local('./manage.py schemamigration %s --auto' % name)
api.local('./manage.py migrate %s' % name)В консоли просто пишу fab automig:someapp и получаю новую схему, автоматически изменённую под новую структуру моделей.
Ещё при работе с south имеет смысл периодически удалять старые миграции, смысла которые хранить особо нет и делать новую initial миграцию
Сейчас изучаю алхимию, меня дико ломает отсутствие south-миграций. Нашёл alembic, разбираюсь с ним потихоньку. Он тоже умеет автогенерацию миграций делать.
В реальном мире, код могут поддерживать не самые высококлассные специалисты и я считаю, что надо думать о том, кто и как после тебя будет работать с этим кодом. И чем меньше магии в нём будет, тем лучше.
Ну да, сносить старые миграции это хорошо и правильно. Но не всегда это хорошо получается. Вот, например, сейчас мы построили большую сложную библиотеку для постоения социальных сетей (ну так, приближённо). В данный момент на ней построенно два проекта и сности миграции очень сложно, так как эти проекты работают с разной версией этих библиотек. Можно, конечно, если заморочиться, но желания ни у кого не возникает.
В что до fabric, то у нас всё куда сложнее. Дело в том, что локально код не крутится и поэтому получается так, что надо отправить последний код на разработческий сервер, создать миграцию и притянуть её в локальное дерево. До сих пор последний момент не до конца автомотизировал…
alembic объективно приятнее в использовании. Пока, конечно, ещё далека от совершентва, но всё равно куда приятнее. Между прочим, либа от создателя самой алхимии.
Кстати, раз уж изучаешь алхимию, могу порекомендовать Elixir. Не знаю, насколько проект жив сегодня, но пару лет назад я с большим удовольствием им пользовался.
Ну да, сносить старые миграции это хорошо и правильно. Но не всегда это хорошо получается. Вот, например, сейчас мы построили большую сложную библиотеку для постоения социальных сетей (ну так, приближённо). В данный момент на ней построенно два проекта и сности миграции очень сложно, так как эти проекты работают с разной версией этих библиотек. Можно, конечно, если заморочиться, но желания ни у кого не возникает.
В что до fabric, то у нас всё куда сложнее. Дело в том, что локально код не крутится и поэтому получается так, что надо отправить последний код на разработческий сервер, создать миграцию и притянуть её в локальное дерево. До сих пор последний момент не до конца автомотизировал…
$ fab rsync.source dj.south.schemamigration:app_name
$ fab deploy.get_path:path/to/app/migrations/XXX_my_mega_migration.py
alembic объективно приятнее в использовании. Пока, конечно, ещё далека от совершентва, но всё равно куда приятнее. Между прочим, либа от создателя самой алхимии.
Кстати, раз уж изучаешь алхимию, могу порекомендовать Elixir. Не знаю, насколько проект жив сегодня, но пару лет назад я с большим удовольствием им пользовался.
Я так понимаю эликсир делали, когда в алхимии ещё не было своей ORM, а сейчас можно из коробки получить функционал ORM
> В реальном мире, код могут поддерживать не самые высококлассные специалисты и я считаю, что надо думать о том, кто и как после тебя будет работать с этим кодом. И чем меньше магии в нём будет, тем лучше
У тебя есть возможность передать потомкам, код использующий для миграции стандартный инструмент (South) или код, который:
а) вообще не использует миграции (т.е. еб… сь как хотите, дорогие будущие разработчики)
б) использует какой-нить адовый велосипед со специфическими багами, дающий 10% того, что даёт south
Выбор за тобой.
Меня лично мало волнуют будущие разработчики проекта. Если это будут школьники, которые не осилили south — то это проблема менеджера проекта, подобравшего таких людей, это не моя проблема. Меня волнует удобство разработки для меня, а не для будущих разработчиков.
> В что до fabric, то у нас всё куда сложнее. Дело в том, что локально код не крутится и поэтому получается так, что надо отправить последний код на разработческий сервер, создать миграцию и притянуть её в локальное дерево.
В чём проблема поднять копию проекта на своей машине?
> В реальном мире, код могут поддерживать не самые высококлассные специалисты и я считаю, что надо думать о том, кто и как после тебя будет работать с этим кодом. И чем меньше магии в нём будет, тем лучше
У тебя есть возможность передать потомкам, код использующий для миграции стандартный инструмент (South) или код, который:
а) вообще не использует миграции (т.е. еб… сь как хотите, дорогие будущие разработчики)
б) использует какой-нить адовый велосипед со специфическими багами, дающий 10% того, что даёт south
Выбор за тобой.
Меня лично мало волнуют будущие разработчики проекта. Если это будут школьники, которые не осилили south — то это проблема менеджера проекта, подобравшего таких людей, это не моя проблема. Меня волнует удобство разработки для меня, а не для будущих разработчиков.
> В что до fabric, то у нас всё куда сложнее. Дело в том, что локально код не крутится и поэтому получается так, что надо отправить последний код на разработческий сервер, создать миграцию и притянуть её в локальное дерево.
В чём проблема поднять копию проекта на своей машине?
> Я так понимаю эликсир делали, когда в алхимии ещё не было своей ORM, а сейчас можно из коробки получить функционал ORM
Ну как бы алхимия это и есть ORM… Изначально. Самой первой версии, ещё до первого коммита.
> Выбор за тобой.
Это я опущу. Я соус я не считаю чем-то стандартным, ибо не дорос ещё.
> В чём проблема поднять копию проекта на своей машине?
PostgreSQL, Solr, RabbitMQ, nodejs… И как мне объяснить обычному прграммисту, как весь этот зоопарк у себя собрать и поддерживать? А верстальщики? А обновим чего? Некоторые, блин, хотят дома из винды работать, так там даже fabric по человечески собрать, это уже проблема!
У нас всё централизованно на одной виртуалке с дебианом. Все довольны.
Ну как бы алхимия это и есть ORM… Изначально. Самой первой версии, ещё до первого коммита.
> Выбор за тобой.
Это я опущу. Я соус я не считаю чем-то стандартным, ибо не дорос ещё.
> В чём проблема поднять копию проекта на своей машине?
PostgreSQL, Solr, RabbitMQ, nodejs… И как мне объяснить обычному прграммисту, как весь этот зоопарк у себя собрать и поддерживать? А верстальщики? А обновим чего? Некоторые, блин, хотят дома из винды работать, так там даже fabric по человечески собрать, это уже проблема!
У нас всё централизованно на одной виртуалке с дебианом. Все довольны.
Да, не так выразился, я имел в виду declarative_base — описание логики и структуры данных сразу в одном классе, раньше в алхими так нельзя было, судя по докам до 5 версии.
> PostgreSQL, Solr, RabbitMQ, nodejs… И как мне объяснить обычному программисту, как весь этот зоопарк у себя собрать и поддерживать?
Думаю, надо объяснять, повышать их уровень — я не думаю, что нужны какие-то сверхусилия, чтобы установить весь этот софт. В нормальном проекте должна быть документация о разоворачивании проекта с нуля. Не важно, используется там south или нет. Верстальщикам да, им геморой с установкой локальной копии проекта не нужен.
Если ты печёшься о будущих разработчиках, то прикинь каково будет им разбираться с системой, если с единственным человеком, знающим систему, случится что-то. Например, ты станешь недоступным на долгое время, а им потом вникать, как эти rabbitmq конфигурятся. Надо щас им втолковывать.
> PostgreSQL, Solr, RabbitMQ, nodejs… И как мне объяснить обычному программисту, как весь этот зоопарк у себя собрать и поддерживать?
Думаю, надо объяснять, повышать их уровень — я не думаю, что нужны какие-то сверхусилия, чтобы установить весь этот софт. В нормальном проекте должна быть документация о разоворачивании проекта с нуля. Не важно, используется там south или нет. Верстальщикам да, им геморой с установкой локальной копии проекта не нужен.
Если ты печёшься о будущих разработчиках, то прикинь каково будет им разбираться с системой, если с единственным человеком, знающим систему, случится что-то. Например, ты станешь недоступным на долгое время, а им потом вникать, как эти rabbitmq конфигурятся. Надо щас им втолковывать.
Я догадался, если честно, но не мог не подколоть… Да, с появлением declarative_base стало удобнее. Эликсир, это немного другое.
Ключевая фраза «в нормальном проекте». Но у нас в околоправительственных кругах ничего нормального нет. Даже тестов код на плакал, ибо на них времени нет. Сначала нет времени, так как надо быстро показать рабочий продукт, а потом надо допиливать функционал, перепиливать архитектуру, а писать тесты для кода, который уже давно написан, это дело гиблое и неблагодарное. Надо что-то менять.
И да, это действительно нужны сверхусилия. Реально много геморроя получится, а смысло мало. Просто
Но на самом деле, там, на сервере, всё просто и красиво. Всегда можно почитать скрипты фабрика про то, как это ставить и настраивать. Но только на дебиане — извращенцы, желающие получить это на винде, пусть трахаются сами. Даже на маке, это очень не тривиально.
Ключевая фраза «в нормальном проекте». Но у нас в околоправительственных кругах ничего нормального нет. Даже тестов код на плакал, ибо на них времени нет. Сначала нет времени, так как надо быстро показать рабочий продукт, а потом надо допиливать функционал, перепиливать архитектуру, а писать тесты для кода, который уже давно написан, это дело гиблое и неблагодарное. Надо что-то менять.
И да, это действительно нужны сверхусилия. Реально много геморроя получится, а смысло мало. Просто
$ fab deploy.sync и через несколько секунд можно смотреть результат на личном разработческом поддомене. Кому нужна отладка, с помощью ssh пробросили порты от солра, реббита и постгри себе в локалхост. Но это для особых извращенцев, а меня устраивает отладка на сервере.Но на самом деле, там, на сервере, всё просто и красиво. Всегда можно почитать скрипты фабрика про то, как это ставить и настраивать. Но только на дебиане — извращенцы, желающие получить это на винде, пусть трахаются сами. Даже на маке, это очень не тривиально.
Вы наверно не разрабатывали в команде большой проект. А всё вели сами.
Раз миграция вас пугает
Раз миграция вас пугает
По правде сказать, я не люблю большие команды. Сейчас нас три программиста, два яваскриптизёра-верстальщика, один дизайнер и один айосник. Больше не надо. :-)
ZZZ_Sochi И как у вас организован процесс параллельной разработки несколькими программистами одного проекта? Вы же используете системы контроля версий? Если да, то вы льёте файлик log.sql(имя произвольно) в репозитарий, чтобы другие разработчики могли увидеть что изменилось в структуре БД? Или при каждом изменении структуры, вы подходите к каждому и просите выполнить ваш код в их локальной БД?
У нас gitolite с пачкой репозиториев.
Нет, мы тоже используем соус. И именно на основании его использования и ковыряния, я о нём сужу.
Выше я писал, что для допродакшеневой разработки какая-то система миграции необходима. Но после запуска в продакшен, много изменений БД быть не должно. Вот тогда лучше мигрироваться руками.
По большому счёту, это конечно же зависит от проекта и личных предпочтений. Лично я уж очень брезгливо отношусь к плохому коду.
Нет, мы тоже используем соус. И именно на основании его использования и ковыряния, я о нём сужу.
Выше я писал, что для допродакшеневой разработки какая-то система миграции необходима. Но после запуска в продакшен, много изменений БД быть не должно. Вот тогда лучше мигрироваться руками.
По большому счёту, это конечно же зависит от проекта и личных предпочтений. Лично я уж очень брезгливо отношусь к плохому коду.
Промах…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Наконец-то. Зарелизился Django 1.5