Подходит ли сайт-пакеты для приложений или только для библиотек?

Question

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

Answer 1

Как только вы дойдете до того момента, когда ваше приложение будет готово к распространению, упакуйте его для своих любимых дистрибутивов / ОС таким образом, чтобы код вашей библиотеки в пакетах сайта и исполняемых скриптах находился в системном пути.

До тех пор (т.е. для всех разработок) не делайте ничего из вышеперечисленного: избавьтесь от серьезных головных болей и используйте zc.buildout или virtualenv для сохранения кода разработки (и, если хотите, его зависимости) также изолированы от остальной системы.

Answer 2

Мы делаем это так.

Большинство материалов, которые мы загружаем, находятся в пакетах сайта. Они приходят из pypi или Source Forge или другого внешнего источника; их легко восстановить; они очень многократно используются; они не сильно меняются.

Должные вещи, которые мы пишем, находятся в других местах (обычно под /opt или c:\opt) И включены в PYTHONPATH.

Нет великой причины не пускать наши вещи в site-packages. Однако наше слабое оправдание в том, что наши вещи сильно меняются. Почти постоянно. Переустанавливать в пакетах сайта каждый раз, когда мы думаем, что у нас есть что-то лучшее, немного больно.

Поскольку мы тестируем наши рабочие каталоги или каталоги извлечения SVN, в наших средах тестирования интенсивно используется PYTHONPATH.

Использование в разработке PYTHONPATH перетекло в производство. Мы используем setup.py для производственных установок, но устанавливаем в альтернативный дом под /opt и устанавливаем PYTHONPATH для включения /opt/ourapp-1.1.

Answer 3

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

Многие программы на python имеют небольшой скрипт, расположенный в пути, который импортирует модуль и вызывает «основной» метод для запуска программы. Это позволяет программисту выполнить некоторые предварительные проверки и, при необходимости, изменить sys.path, чтобы найти нужный модуль. Это также может ускорить время загрузки в более крупных программах, поскольку только байт-код будет запускать только импортированные файлы.

Answer 4

Если вы можете превратить часть приложения в библиотеку и предоставить API, то сайт-пакеты - хорошее место для этого. Это на самом деле сколько Python приложений делают это.

Но с точки зрения пользователя или администратора это на самом деле не проблема. Проблема в том, как мы можем управлять установленным материалом. Как я могу установить и удалить его после его установки?

Я использую Fedora. Если я использую Python, который поставляется с ним, мне не нравится устанавливать вещи в пакеты сайтов за пределами системы RPM. В некоторых случаях я сам собирал rpm для его установки.

Если я собираю свой собственный python вне RPM, то, естественно, я хочу использовать механизмы python для управления им.

Третий способ - использовать что-то вроде easy_install для установки такой вещи, например, как домашний каталог пользователя.

So

• Разрешить упаковку для распространения.
• Разрешить выбор используемого питона.
• Разрешить использование Python, установленного дистрибутивом, если у вас нет прав доступа к пакетам сайта.
• Разрешить использование Python, установленного вне дистрибутива, где вы можете использовать site-пакеты.

Answer 5

Site-пакеты для библиотек, безусловно.

Может сработать гибридный подход: вы можете установить библиотеки, необходимые для вашего приложения, в пакеты сайтов, а затем установить основной модуль в другом месте.