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

При использовании WorkManager вы должны использовать LiveData для обновления пользовательского интерфейса. Я настоятельно рекомендую вам взглянуть на принятый ответ здесь . Я думаю, что он значительно поможет вам.

5
задан AaronS 24 April 2009 в 18:22
поделиться

5 ответов

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

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

4
ответ дан 13 December 2019 в 19:35
поделиться

We do it like this.

Most stuff we download is in site-packages. They come from pypi or Source Forge or some other external source; they are easy to rebuild; they're highly reused; they don't change much.

Must stuff we write is in other locations (usually under /opt, or c:\opt) AND is included in the PYTHONPATH.

There's no great reason for keeping our stuff out of site-packages. However, our feeble excuse is that our stuff changes a lot. Pretty much constantly. To reinstall in site-packages every time we think we have something better is a bit of a pain.

Since we're testing out of our working directories or SVN checkout directories, our test environments make heavy use of PYTHONPATH.

The development use of PYTHONPATH bled over into production. We use a setup.py for production installs, but install to an alternate home under /opt and set the PYTHONPATH to include /opt/ourapp-1.1.

4
ответ дан 13 December 2019 в 19:35
поделиться

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

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

0
ответ дан 13 December 2019 в 19:35
поделиться

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

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

3
ответ дан 13 December 2019 в 19:35
поделиться

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

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

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

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

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

Так

  • Разрешить упаковку для дистрибутивов.
  • Разрешить выбор python для использования.
  • Разрешить использование python, установленного дистрибутивом, где у вас нет прав на пакеты сайта.
  • Разрешить использование python, установленного вне дистрибутива, где вы можете использовать site-пакеты.
]
0
ответ дан 13 December 2019 в 19:35
поделиться
Другие вопросы по тегам:

Похожие вопросы: