Вышла долгожданная версия Джанго 1.0. Мои самые искренние поздравления всем, кто участвовал и всем, кто сочувствовал. Совершенно серьезно я считаю, что на данный момент это лучший питоновый веб-фреймворк.
Тем не менее, я хочу по случаю посмотреть на этот релиз с нетрадиционной стороны и, возможно, несколько войти в диссонанс с эйфорией, которая сейчас начнется :-).
Разговаривая с людьми о Джанго, я обнаружил, что многие ждут релиз 1.0 как некое одиозное событие, которое... что? Оно, очевидно, что-то такое знаменует и означает. Но вот что именно в релизе 1.0 такого отличительного, что его все ждут.
Стабильность
Слышу, что ждут стабильности. Но это слово означает две разные вещи. По поводу одной — стабильности работы — в джанговском FAQ'е есть запись о том, что Джанго и так стабилен, и был стабильным еще до того, как даже исходники открылись. На нем работают реальные сайты и не падают. И это все правда.
Поэтому речь, конечно, не об этой стабильности. Речь о стабильности API, который в версии 1.0 перестанет изменяться.
Но секундочку... Возьмите любую произвольную ревизию кода, сохраните ее на диск и, уверяю вас, ее API тоже не будет меняться. Никогда. Вы можете написать на ней сайт, можете — два. Можете работать с ней 10 лет. API будет стабильным.
Развитие
Однако те, кто так пробовал делать, знают, что такая жизнь имеет свой существенный недостаток. Фреймворк развивается, в нем появляются новые фичи, рефакторятся старые неудачные подходы, и с ним становится проще жить. Наступает момент, когда вы на самом деле уже не хотите той стабильности, а хотите вот эту новую штуку, с которой кода в три раза меньше получается.
Позвольте снова спросить, чем в этом смысле отличается релиз 1.0 от произвольно зафиксированной ревизии? Что, Джанго после 1.0 перестанет развиваться? Да нет, корные разработчики уже заявляли, что довольно быстро после 1.0 появятся 1.1, 1.2. Думаю и 2.0 будет довольно быстро... Может быть эти самые 1.1 и 1.2 будут сохранять обратную совместимость с 1.0? Да, наверняка. Но штука в том, что поддержка обратной совместимости — священная корова в разработке Джанго, и она ломается крайне редко и крайне неохотно. И только по делу. Номера версий тут не причина, а следствие. Фактически, версией 2.0 Джанго скорее всего станет первая же, в которой придется избавиться от какого-нибудь старого API, проявившего себя не слишком удачно.
Сторонние компоненты
Третий аспект "особенности" версии 1.0 — предполагается, что ее API будут использовать в качестве ориентира разработчики сторонних компонентов. И это снова правда. Но я, убейте меня, не верю, что разработчики сторонних компонентов не будут использовать и новые API. А значит их уже нельзя будет использовать с 1.0 напрямую. Да еще и эти компоненты не будут обязаны соблюдать полную обратную совместимость с 1.0, тут уж все зависит от специфики кода и желания разработчика. Если разработчик вменяемый, то он, опять таки, тоже старается сохранять обратную совместимость независимо от того, в какой версии фреймворка его стукнуло желание написать что-нибудь полезное.
Транк
Чтобы не быть голословным, расскажу, что у нас в Яндексе внутренние релизы Джанго — событие вполне заурядное. Как только кому-то из разработчиков нужна какая-то фича из транка, ближайшая удобная ревизия заворачивается в пакет, объявляется следующим релизом, и дальше разработчик-инициатор начинает кодить свой код, а остальные — апдейтить свои проекты под те несовместимости, которые к тому моменту накопились.
Думаю, мы продолжим делать это и после 1.0.
И вот это в Джанго, на мой взгляд, самое главное. Имея такой транк, который живет и практически не ломается, лично мне никаких релизов не надо :-)
И тем не менее...
Тем не менее, версия 1.0 — это хорошо. Я могу сходу придумать две причины, почему это так:
Это большой символ, и очень хороший стимул: я давно не помню такого шквала активности в разработке Джанго, который начался с тех пор, как был объявлен план на 1.0. Были наконец-то доделаны и влиты в транк важнейшие рефакторинги, ждавшие своей очереди: новая админка, обработка аплоудов, подключаемые файловые хранилища и т.д. Фреймворк стал гораздо лучше за последние пару месяцев.
Это знаковое событие с маркетинговой точки зрения. Вокруг Джанго есть много людей, которые не интересуются процессом подробно, и которые привыкли к тому, что версия 1.0 — это "готово, можно пользоваться". Теперь они, наконец-то, заткнутся о том, что Джанго "все еще бета" :-).
Поздравляем нас всех!
Комментарии: 44
Я думаю Иван ты сам ответил на вопросы заданные в начале поста. :) Целиком тебя поддерживаю.
Полностью согласен. 1.0 - это просто чекпоинт.
Собственно, я как сидел на транке, так и буду сидеть :)
Поздравляю с долгожданным чекпоинтом!
Есть одно важное обстоятельство, которое вы не учли. 1.0 - версия, которая заменит 0.96 в дистрибутивах. Например, сегодня в Debian поставляется джанго 0.95 в stable и 0.96 в testing (http://packages.debian.org/search?keywords=python-django)). И пакеты не обновляются после каждого commit-а разработчиков.
Еще: стабильность - это еще поддержка. Заплатку на дырку в безопасности ставят на все поддерживаемые версии и на транк. И никто не будет ставить ее на конкретный SVN-rev. А значит, если мы под 1.0, то получаем поддержку и нам не нужно тратить время на то, чтобы повторить действия, которые уже сделаны в 1.0 или на решение проблем связанных с обновлением до транка через пачку ревизий, меняющих API.
Штука в том, что большинство (по моим наблюдениям) проектов работает на транке, и уже давно. Пакеты любой ОС, даже если это Ubuntu с полугодовым циклом обновлений, всегда будут отставать от транка на полгода минимум, а это редко приемлемо.
Ничто не мешает поставить ее вручную. Раз уж человек пользуется непакетированной версией.
Но по факту я согласен, да. Это выбор того, кому быть майнтейнером — пользователю или разработчикам.
ОДИОЗНЫЙ (от латинского odiosus - ненавистный, противный), известный своими отрицательными качествами, вызывающий резко неприязненное отношение.
вы наверное имели в виду "некое знаковое событие"
Да, никогда не знал, что у слова "одиозный" есть отрицательная эмоциональная окраска... Использовал всю жизнь именно как "знаковый", "значительный".
Для меня самое главное в любом релизе — это психология. Релиз это чекпоинт, который кое к чему обязывает разработчиков.
Бывают такие тикеты, которые в принципе важны, но не очень интересны и желания разбираться с ними нет. К релизу они должны быть исправлены.
Кроме того, я считаю, команде, разрабатывающей фреймворк «for perfectionsts with deadlines», давно не хватало этого самого deadline для самих себя.
Конечно, я люблю транк и я буду на транке. Но из-за релиза транк стал намного лучше в очень сжатые сроки.
Вот так: я люблю и транки и релизы. И я испытываю благодарность и зависть. Зависть — потому что я не участвовал в этом :-)
Выход 1.0 хорош для опенсорсных проектов, где нельзя простым движением руки собрать новый пакетик и заставить всех заапдейтиться. А декларировать использование 1.0 и поддерживать проект именно на уровне 1.0 намного проще, чем вести его по транку и одновременно пытаться решать проблемы тех, у кого они есть (и они просто забыли обновить джангу час назад ;).
В общем, мне кажется, жить проще станет. И, надеюсь, ревизии будут почаще выходить. :)
Есть мнение, что народ массово сидит на trunk когда нет достаточно частых и планомерных релизов. Так что отсутствие релиза хотя бы раз в 3-6 месяцев — это плохо для проекта и для пользователей такого проекта. Разработчикам проекта это по барабану, потому что они всегда используют trunk.
Так что я не согласен с посылом статьи "trunk — вот что главное". Главное не это, а рабочий trunk в каждой ревизии. Но такого не бывает, рано или поздно возникают регрессии.
И не стоит недооценивать готовые пакеты в дистрибутивах.
Мои 5 копеек, конечно.
Я редко когда не согласен с Иваном Сагалаевым. Сейчас как раз такой случай. Я не согласен с оценкой значимости релиза.
Такому проекту, как Django, важно иметь регулярные стабильные версии.
Почему стабильные? Потому что проект Django самым непосредственным образом используется в ряде других проектов. Особенно это становится видно, когда результатом проекта становится продукт, который написан на Django и используется третьими лицами. В этом случае использование транка неприемлемо.
Ну представьте сами, что будет, если такой продукт будет создан на основе транка. Это значит, что разработчикам помимо работы над непосредственно самим продуктом добавляется работа по фиксу уже рабочего кода в случаях изменения API в транке. А ребятам, использующим продукт, совсем не сладко. Обновили систему, обновили код Django из транка (на предмет баг-фиксов), и на тебе! Не работает! Я с этим столкнулся, когда использовал транк и появился autoescape в шаблонах Django. Вот веселуха была.
А если используется стабильная версия, пользователи безболезненно обновляются (автоматически или "нажатием одной кнопки"), разработчики непосредственно заняты функционалом продукта. И даже если разработчики захотят выпустить новую версию продукта, которая основана на новой версии Django, это будет несложно. Потому что это будет прогнозируемо. Понятно, что надо изменить, что бы продукт заработал в новой версии.
Почему регулярные? Потому что нельзя, что бы функционал последней стабильной версии слишком отставал от кода в транке, как было с версией 0.96. Уж слишком мои внутренности протестовали, что бы я отказался от использования функционала транка для нового проекта. Будь версия 0.97 или 0.98, я бы использовал её.
Ну и действительно, весьма примечателен рост активности разработчиков Django. Возможно, это говорит о долгожданности такого шага.
Так что регулярные и стабильные версии Djagno действительно важны. А то, что кто-то кричит про нестабильность Django, действительно важно только для маркетинга. Разумные люди крикунов не слушают.
М-м? Процитирую себя:
И еще:
Они безболезненно обновляются, только если новая версия из той же мажорной цифры (и то это не гарантируется). Но неминуемо придет время, когда Джанго будет уже 2.0, и пользователи не смогут "безболезненно" обновляться.
А где я написал, что не важны? :-). Я написал, что надо понимать, чем именно они важны, а чем нет. При этом я даже не претендую на универсальность своей точки зрения.
Но если в этой ревизии найдется баг, то бэкпорт фикса будете делать вы, а не тот человек, который за это отвечает. Простая перемотка до текущей HEAD поломает продукт, который вообще говоря не обязательно писали вы.
А ведь баг может быть секьюрным, который тихо пофиксили между r45903 и r46030, а вы сидите на r45905. А это значит, что человек, который отвечает за поддержку, должен постоянно читать баг-трек джанги, я так понимаю, что трафик там весьма нехилый.
Какая--то стабильная версия гарантирует, что все критические фиксы будут вноситься и в стабильную ветку тоже и вы сможете просто не думать об этом.
Раз уж мы говорим о Джанго, то тут речь идет только о секьюрных багах, а не "в том числе" секьюрных багах. Остальные фиксы в стабильные версии не бэкпортятся. А для бэкпорта секьюрных багов не нужно следить за всеми ревизиями, нужно быть только подписанным на django-annonunce, где такие вещи объявляются. Их там крайне мало, кстати.
Но в целом да, я повторюсь, что согласен с тем, что это выбор того, кому быть майнтейнером — пользователю или разработчикам. По факту довольно много людей уже выбрали "жизнь в транке", и не жалеют.
А мне и минорная цифра не нужна, для поддержки уже существующего проекта нужны только баг-фиксы. Другое дело, что рано или поздно поддержка версии X.Y будет прекращена. Но если поддержка продлится хотя бы полтора года, этого уже будет достаточно. За полтора года можно перейти на Django X.Z. Или на Django Y.0. Или подписаться на django-annonunce и поддерживать Django X.Y :-)
Отличная новость. Вот как знал - надо почитать фиды на ночь, и вот ОНО. Супер!
В течение августа я пару раз пожалел и разочаровался в стабильности транка, но теперь уже все позади.
За август соглашусь :-). Менялось все много и часто. Мы внутри два раза отменяли релиз как раз чтобы дождаться, когда rush закончится.
Посмотрим, кстати. Если ребята начнут придерживаться планов типа "один релиз в пару месяцев", возможно действительно сидение на транке потеряет свои выгоды. Но я пока не верю :-)
Я всегда, с первого дня знакомства с джангой пользовался транком. И буду продолжать им пользоваться и впредь.
Но сам факт выхода первой.ноль версии меня радует. И в большей степени своей психологической важностью, а не технической. О чем в блоге и написал.
А по поводу использования в продакшен конкретной ревизии, то до недавнего времени я придерживался мнения, что вполне себе это нормально и беспроблемно. Но сейчас, когда ко мне обратился человек, который стал заниматься моим старым проектом и у него не получалось поднять песочницу у себя по простой причине - он не знал номер ревизии. Ситуация ещё усложнялась тем, что помимо конкретной ревизии нужно аплинуть ещё и конкретный патч к нему чтобы всё заработало. Да, в этой ситуации сказать"такой-то релиз" гораздо проще.
Но мысль, что поддерживать ревизию труднее и обновлять как-то проблематично - не разделяю. Контент менеджер обычно приложения не обновляет, а у разработчика или админа навыки применить патч к каталогу должны быть в любом случае. Вот.
А еще, а еще, django_evolution ждали релиза, чтобы совместимость закоммитить. И вот оно снова работает на транке :-)
Слава релизам :-)
Александр Кошелев:
несколько дней подряд думал над этой фразой. так и не понял, что значит "применить патч к каталогу"? патчатся только файлы, по крайней мере стандартной утилитой patch.
Вот скажите, зачем это буквоедство? Вызов
patch -p0 < some.diffвнутри каталога с universal-патчем на входе применяется ко всем файлам внутри него. Чем это не "применить патч к каталогу"? Можно еще пообсуждать, чтоpatchприменяет патчи таки не целиком файлами, а отдельными "ханками"...это еще не буквоедство, не надо наезжать. я пока только уточнить хотел, поскольку скилл "телепатия" не прокачан вовсе.
С таким подходом Django проекты можно будет хостить только на VPS как минимум. Причем свой VPS для каждого проекта. Это приведет к печальным последствиям:
Сам пишу на Django для себя. Во многом благодаря этому форуму. С позицией "Главное - Транк" не согласен. Для Гиков энтузиастов, когда хочется потестить вкусные новые фичи из транка - клевый подход. Для крупного проекта в котором куча программистов ПОСТОЯННО его поддерживает - наверное, тоже хорошо. Для проекта сделал и оно работает - не пройдет.
Поддержка проектов, когда для каждого проекта свой VPS очень усложняется и Бизнес такого не поймет. Я надеюсь, что разработчики Django изначально ориетнировались на упрощение поддержки проектов. Поэтому, будут регулярно выпускать стабильные релизы. И они изначально ориентировались на простоту поддержки со стороны бизнеса (когда важно точно знать, когда выйдет следующий релиз платформы, и какое времы будет поддерживаться вышедший стабильный релиз). Иначе они, наверняка, выбрали бы другую лицензию...
Еще пример.
PHP.
нужен сайт - берем виртуальный хостинг, ставим Drupal, настраиваем, качаем плагины к нужной версии. Работает, пока не поменяют мажорную версию php.
Django.
качаем Cicero, идем на форум, узнаем, какой нужен транк, покупаем VPS, настраиваем VPS, ставим forum, настраиваем... Ничего не трогаем, даже, если не дай бог выйдет какой-то чудо плагин борьбы со спамом или аторизации по отпечатку сетчатки глаза - ничего поставить не получиться - т.к. плагин для другого транка.
Если что - просьба не обижаться. Сам использую Django. По жизни чаще занимаюсь саппортом, а не разработками (сисамдин). А при подходе "главное транк" каждому проекту потребуется vps однозначно, + постоянный программист и сисадмин, если нужно что-то поменять. В такую ситуацию лезть очень не хочется.
Не надо ссориться. Да, наверно,я просто не совсем очевидно выразился. Но Ваня абсолютно прав, я имел ввиду типичный паттерн патчинга джанги.
Что-то причинно-следственная связь не прослеживается
Я ни разу не патчил джангу, поэтому не знал про "типичные паттерны патчинга джанги". Просто сейчас развелось много разных нестандратных инструментов, сразу не угадаешь.
А я имел в виду практически любой open source проект. Тут нет ничего джанго-специфичного, и именно поэтому я искренне удивлен вопросом "как это". А как еще-то? :-)
написали прокт - зафиксировали API (транк).
паписали другой прокт - зафиксировали другой транк. На виртуальном хостинге такое не получиться. Вариант, когда на рельсовом проекте делают Freeze рельсов+gem'ов для конкретного проекта, по сути тот же VPS (по отжиранию кешем памяти, т.к. кроме своего кода у тебя для каждого проекта еще свой код фреймворка) и преимущества виртуального хостинга исчезают. "Дешевая памать" не спасет.
В случае регулярных стабильных релизов все сайты используют несколько поддерживаемых хостером стабильных версий.
Еще раз повторю, для гиков и крупных проектов все по другому.
Почему? По-моему, хостер будет поддерживать одну — последнюю — версию. Если хостер "любит" Джангу, то максимум две. Поэтому, официальные релизы или нет, а вариант "написали и забыли" на шаренном хостинге будет работать только для сред, не обновляющихся годами. Что и видно на примере PHP, где мажорные версии заменяют друг друга очень медленно.
Потому что у хостера много проектов, которые написали и перестали менять. Т.е. написали и забыли, а оно работает.
При регулярных релизах раз в 4-6 месяцев не вопрос поддерживать несколько стабильных версий.
Да ладно! А зачем мне джанга хостера вообще? Я могу её с собой таскать. Было бы желание. Это же не версию всей среди включая интерпретатор сменить, как в php.
Аналог рельсовых фризов для джемов и самих рельсов (уже писал про это). Довольно быстро попадешь в VPS, т.к. приложение будет ооочень нагружать дисковую систему, подгружая свой фреймворк для каждого проекта и заполняя этим файловый кеш. Потому хостер тебя спровадит на VPS, где приложение и будет тормозить (т.к. на vps машине таких много и все мыслят похоже).
Так процесс может месяцами висеть в памяти, а загружает модули он в момент старта. В общем не беда ни разу.
Ну что ж, продолжаем занудничать.
Иван, в англоязычных форумах и почтовых рассылках мне никогда не попадался термин "патчить каталог". Чаще говорят о patching source tree. А как еще-то?
К счастью мы имеем возможность писать комментарии в русскоязычный блог, да ещё и на русском же языке, поэтому почему бы не иметь свой собственный глоссарий предметной области?:)
Гм. А какая религия не позволяет сделать чекаунт необходимой ревизии в домашнюю директорию на хостинге и прописать необходимое в PYTHONPATH?
Не надо придумывать проблемы там, где их нет.
Иван а можно немного раскрыть тему "заворачивания новой версии django в пакет" ???
насколько я понимаю это Debian?
вы используете какой то СВОЙ пакет и свои debian/rules и соответсвенно сами осуществляете сборку и сами прописываете все build depends?
или взяли за основу debian пакет из официальных репозиториев?
а как тогда быть с тем, что apt-get install python-django до 1.0.1 тянет на etch за собой ~200 метров левых библиотек? ну понятно что локальный репозиторий и трафик никто уже не считает... но вот у меня это вызывает дискомфорт
У нас свой пакет, написанный с нуля. Ничего сложнее
python setup.py installпри установке он не делает. Зависимостей мы ему написали две: python (точнее python-support) и python-imaging.А новичкам плохо. Django book всё ещё написан для 0.95, и бегать от DB до http://docs.djangoproject.com/en/dev/releases/1.0-porting-guide/ уже достало. Кроме того, плавно начинаешь запутываться.
А так, в принципе, радуюсь :)
Вы неправы. Я - хостер python приложений. Мы только обоими руками за то, что бы разработчики ставили свою версию джанго (даже в инструкциях рекомендуем). Потому что когда центральная версия обновится, саппорт завалят письмами.
Иван спасибо за ценный совет
сделали свой пакет для django
а можно еще вопрос?
как вы мониторите производительность в продакшене??
ну вот допустим для PHP у меня есть модуль который время выполнения и важные параметры из $_REQUEST и $_SERVER формирует в UDP пакет и отсылает на демон статистики
который высчитывает всякие там группировки по скритам, хостам и держит это в памяти (SQLite) за какой то промежуток времени
к нему цепляется Cacti и снимает показатели типа top5
есть ли какие либо подобные решения для Django??
т.е. меня интересует возможность подцепиться к django fastcgi и снять какоую нибудь status_page через cacti
Про это, к сожалению, подробно рассказать не могу... Насколько я знаю, у flup (сервера FastCGI в Django) такого интерфейса нет. Админы наши мониторят "здоровье" серверов в целом по куче глобальных параметров. И пока что подробности о состоянии отдельного процесса нам наверное мало что дадут, потому что на нашем кластере крутятся что-то типа 9 джанговских проектов, от мелких до крупных. Но мысль все равно хорошая, я постараюсь устранить собственное невежество в этом вопросе...