Потому что надо апдейтить django в отдельной рабочей копии и из под другого пользователя. Какого-нибудь svn-updater.

Да понятно, но это же и не проблема вовсе. Я churn этот раза три в жизни запускал. Вспомнилось просто.

В принципе нормальный такой лэйаут.. Только как ты static media делишь то? Или я туплю или ты дэвид блэйн.. MEDIA_ROOT ведь вроде один и все линки с get_something_url аппендятся к нему.. Как ты смог разделить их?

Я конечно гляну что там у тебя в коде.. но думаю про это тебе пост надо написать, всё-таки проблема с которой сталкиваются все, а решение спрятано как ты говоришь аж в конекстном процессоре..

Эх, надо будет у себя все переколбасить. Но это после отпуска. Сейчас уже ни о чем не хочется думать :)

Кстати, когда уже для django будет нормальный инсталятор? Я имею ввиду такой, чтобы, скажем, имея на сервере django определенной версии в python пути, достаточно было распаковать где-то исходники движка, открыть определенный URL и настроить все через веб.

Хм.. дефолтовый джанговский лэйаут явно для не очень крупных проектов придуман. А тем кому надо — сами и меняют.

Вообще ваш подход сразу противоречит большинству других. То есть если взять byteflow и поставить его грамотно system-wide, то будет небольшая попа в виде “черт возьми, всё в pythonpath?!”. Темплейты — пофик, их хоть через pkg_resources грамотно вытаскивать можно. Но вот статику.. =)

src/
  bin/
    manage.py
    retranslate.py
  pylib/
    my-super-project/
      toolset/
      another-non-web-library/
      locale/        # << whole project (for executable scripts, etc.) locale files
      web/
        templates/   # << base templates
        locale/      # << base translations
        django_app1/
          templates/ # << django_app1 templates
          locale/    # << django_app1 locales
        django_app2/
        ...
        settings.py
    django/
    override-library-1/
    override-library-2
    ...
  share/
    media/
      js/
      css/
      blabla/
    docs/
  setup.py

Вот мой вариант. Соответственно, в pythonpath у нас самое естественное — pylib (при system-wide установке — станет site-packages).

Но это — минижопа для сторонних приложений. Во-первых, многие:

1. там где settings.py — там project dir — значит там все папки - приложения
2. os.path.dirname(app_mod.__file__) — там project dir (грешат всякие тулзы типа deseb, evolvedb)
3. ещё у многих сносит крышу от полного питоновского пути к приложению: my-super-project.web.app1 — многие отрезают начало, и пытаются импортить найденное напрямую (т.е. вместо полного пути — импортят web.app1, что неверно, конечно).

Ну и ещё так, по мелочи… Но это всё чинится на раз-два =).

p.s. я специально пытался не колдовать с sys.path p.p.s. а проблема импорта с именем… ээээ… from .. import ? p.p.p.s а проблема “склонировать”… мм. Поменять 1 PYTHONPATH в консоли — и будет клон. Или я не понял в чем проблема?

ура! я думал сейчас как наорёшь и снова я обижусь =)

Вообще было бы неплохо придумать какой-то универсальный лейаут, который бы все использовали. У тебя он слегонца развесистый выходит, на самом-то деле. :)

ну.. я его показал для своего текущего весьма увесистого, но к сожалению закрытого (показать не могу), проекта. =) А так — если например не использовать локали внутри приложений — у меня автоматом это из общих локалей браться будет. Если не использовать тонну своих библиотек — то и лишнего в /pylib/ не будет. По крайней мере цель у меня была следующего характера: надо было чтобы билд не сильно отличался от исходников.. ведь все же питон язык интерпретируемый и перемешивать все файлы после изменения каждой строчки — бее.. А билдить в реалтайме все равно нужно — ибо у меня тут и си и ситон с пурексом.. Главное делать так чтобы сам по себе проект от лейаута не сильно зависил =)) Т.е. если вдруг будет идея что-то сделать по-другому — чтобы это не было мегасложно. Посему и абсолютные импорты с именем проекта в начале — нафик нафик. Хотя grep и сколько-то часов (но не дней) для довольно крупного проекта, при налиичии регрессивных тестов — ничтожная цена.

Ещё один момент — не люблю файлы темплейтов рядом с питоновскими, правда сейчас задумался — как-то это иррационально, ведь поиск по файлам можно ограничивать типом файла… Но пока всё ещё не люблю. :)

я вот кстати тоже с этим долго дрался. Все мне хотелось темплейты куда-нибудь выкинуть подальше. А дрался с setuptools и distutils. Я уже не помню все грабли на которые пришлось наступить, но точно знаю что теперь я темплейты не считаю таким уж “статическим” дерьмом без которого всё работать может =)))). На самом деле если пытаться делать приложения “detachable” как плагины — то при большом их количестве или старте нового проекта становится комфортнее (:

Так или иначе дело не только в темплейтах — ибо джанговские приложения ведь не только их использовать могут.. логично что то, к чему больше никто не захочет получать доступ (в отличие от графики, скажем, куда неплохо бы статик-сервер отправить) держать в самом ”сердце”.

Почему бы не добавлять имя приложения как директорию, если шаблоны лежат в приложении? Очень бы удобно было, имхо. И логично.

потому что например я пока не придумал способ в темплейт лоадере определять в каком приложении темплейт вызывается. Думал я, правда, не долго и немного над другой задачей — я хотел чтобы если запрашивается в приложении blabla темплейт index.html — то он чтобы сначала искал именно в темплейтах текущего приложения, а потом пропускал через другие темплейт-лоадеры. Но чтобы даже не пытался искать темплейты у других приложений.

Собственно, реализовывать это я буду 100%, ибо нам очень надо. Потом поделюсь (: