Последнее время мне всё более и более странным (я бы даже сказал “недальновидным”) кажется решение авторов оригинального туториала по Джанге показывать именно такой формат расположения файлов в джанге (и уж тем более то, какой sys.path они там используют): в туториале все файлики, созданные с помощью startproject, лежат в одной директории вместе с приложениями. Соответственно, все импорты выглядят как from someproject.someapp import views.

Мне понятно, откуда ноги растут — на деле у них все приложения лежат в sys.path, и потому импортируют они оттуда как from someapp import views, а проект — это лишь настройки да корневой конфиг урлов. Тогда можно родительскую для всех проектов директорию положить в sys.path, и менять только DJANGO_SETTINGS_MODULE. Но в любом случае одним интерпретатором питона для двух джанговских проектов не обойдёшься (спасибо этому самому DJANGO_SETTINGS_MODULE), а способность к лёгкому созданию дистрибутива и его распространению страдает порядочно (что особенно важно для опенсорсовых проектов).

Поэтому мне значительно больше нравится другой подход к делу, который я применяю во всех своих проектах, в том числе и в Byteflow:

project/
  apps/        # собственно приложения
  template/    # шаблоны
  static/      # статические файлы — картинки оформления, стили, JS
  media/       # файлики, загруженные пользователями, не версионируется
  locale/      # переводы
  compat/      # тут библиотеки типа django-atom
  manage.py    # файлы, относящиеся к описанию проекта
  settings.py
  urls.py
  ...

При этом в sys.path добавляется сама директория проекта, DJANGO_SETTINGS_MODULE становится равен settings, а в settings.py двумя строками кода в sys.path добавляется и apps/ с compat/¹. В результате все импорты простые и не содержат имени проекта (что тупо хотя бы потому, что я не могу склонировать проект рядом и поэкспериментировать в нём из-за того, что будут проблемы с импортами), а проект становится достаточно независимой вещью, которая для разворачивания на каком-то сервере требует только Джангу и библиотеки, которые достаточно распространённые и/или большие для того, чтобы не включать их в проект.

Заметил одну интересную особенность статей о Гите — каждая из них рассказывает о формате его репозитория, в который раз талдыча про его простоту и понятность, в то время как статьи про Меркуриал и Базар содержат более близкую пользователю информацию.

Похоже, всё потому, что с интерфейсом Гита просто невозможно справиться, не понимания в точности, что же происходит. В то время как в Меркуриале эта информация избыточна — всё достаточно просто и без того. :)

Какое-то время назад Бурчик перевёл свой блог на Byteflow, и благодаря его стараниям в движке появилась возможность получать новые комментарии по почте. “Возможность” — это, конечно, сильно сказано, потому как получали их все прокомментировавшие без особых разбирательств. ;)

Однако, несмотря на всё несовершенство этой штуки, она сделала своё дело — заставила меня перестать бездельничать и написать функциональность, которая бы позволяла подписаться и отписаться от комментариев к определённому посту. За сегодня родилось небольшое приложение, которое следит за вашими подписками, позволяет подписаться на избранные посты, посмотреть список подписок (ух, каламбурище ;) и отписаться от желаемого.

По-моему, получилось всё довольно неплохо и даже немного обобщённо для того, чтобы можно было это приложение использовать в других проектах. :)

P.S.А ещё я починил рекаптчу сегодня, сто лет долгой жизни разработчикам jQuery, её поломавшим.

Enjoy!

В транке меркуриала появилась одна очень клёвая штука — дерево чейнджсетов в hgweb’е. Раньше его можно было посмотреть только локально, а сейчас — и онлайн. Например, вот byteflow.

Кстати, последние изменения в crew¹ говорят о том, что возможно в скором времени можно будет коммитить без рабочей копии (т.е. прямо из памяти, используя API). :-)