





Может, PEP8 и easy_install вам помогут?
В дополнение к PEP8 и easy_install вам следует проверить virtualenv. Virtualenv позволяет иметь несколько разных деревьев библиотек Python. На работе мы используем virtualenv со средой начальной загрузки, чтобы быстро настроить среду разработки / производства, в которой все мы синхронизируемся с версиями библиотек и т. д. Обычно мы координируем обновления библиотек.
Страница документации Python "Модули" - полезное руководство по организации кода, в частности разделов "пакеты".
Я храню все исходные коды своих пакетов в ~ / Packages /, а затем выполняю стандартную установку с "python2.5 setup.py install" на них. Это попадает в (для меня) /Library/Frameworks/Python/Versions/current/lib/python2.5/site-packages/. Для разработки моего собственного программного обеспечения у меня есть псевдонимы, настроенные для переключения между соединительной линией / ветвями / 1.0 и т. д. Путем предварительного добавления в PYTHONPATH. (Мне нужно запустить setup.py build_ext --inplace в каждом из этих каталогов, прежде чем они будут правильно импортированы.)
Стоит отметить, что Python2.6 имеет каталог пакетов сайта для каждого пользователя, что может показаться вам более удобным.
Мой совет - попытаться поместить все в каталог (-ы) вашего сайта-пакетов, если у вас нет веской причины не делать этого. И я стараюсь избегать easy_install, потому что я считаю, что он имеет тенденцию засорять мой sys.path местоположением яиц, но это только я. Некоторые люди находят это полезным.
Если у вас много программ, использующих разные библиотеки, которые могут конфликтовать друг с другом, вы также можете проверить virtualenv.
Есть несколько семейств компонентов Python.
Материал, поставляемый с Python. Это само о себе позаботится.
То, что у вас есть с помощью easy_install. Это тоже само о себе позаботится.
Пакеты, которые вы должны были получить другим способом, в виде TARballs или SVN. Создайте папку Components. Сначала поместите туда загрузки или SVN. Каждый раз. Делайте установки оттуда.
Написанные вами пакеты можно использовать повторно. У меня есть папка Projects с каждым проектом в этой папке. Если проект является многоразовым, у него есть setup.py, и я фактически запускаю установку, как если бы я его загрузил. У меня их не так много, но несколько. Некоторые из них могут стать проектами с открытым исходным кодом.
Финальные приложения, которые вы пишете. У меня есть папка в Projects с каждым из этих приложений верхнего уровня. Обычно это большие, бессвязные вещи (например, сайты Django), у которых нет setup.py. Почему? Они часто бывают довольно сложными, и требуется управлять всего несколькими установками серверов, и каждая из этих установок сервера уникальна. Обычно они используют PYTHONPATH для идентификации своих частей.
Обратите внимание на общую тему. Либо это Компоненты, которые вы скачали, либо проекты, над которыми вы работаете.
Кроме того, я держу это отдельно (в некоторой степени) от клиента. У меня есть главный каталог клиентских папок, в каждой из которых есть проекты, а в каждом проекте - продажи и доставка. Не у всех проектов есть и продажа, и доставка.
Мой совет:
paster create (см. http://pythonpaste.org) для создания исходного макета каталога.Собственно, я делаю еще один шаг: в моих пакетах сайтов отсутствуют даже инструменты установки, поскольку (а) они мне там не нужны, (б) virtualenv включает в себя копию, связанную с ними, которую можно использовать при создании каждой среды, и ( c) некоторые версии virtualenv вызывают у меня проблемы, если они доступны для всей системы.
Только что наткнулся на этот сайт из другого вопроса StackOverflow: http://infinitemonkeycorps.net/docs/pph/ Это касается не только размещения модуля, но как только вы разместите его, напишите, как вы можете легко справиться с документацией, тестированием и распространением.
Звучит очень интересно, не могли бы вы объяснить это немного подробнее (и, возможно, опубликовать сценарий начальной загрузки virtualenv в качестве примера)?