При использовании WorkManager вы должны использовать LiveData для обновления пользовательского интерфейса. Я настоятельно рекомендую вам взглянуть на принятый ответ здесь . Я думаю, что он значительно поможет вам.
Как только вы дойдете до того момента, когда ваше приложение будет готово к распространению, упакуйте его для своих любимых дистрибутивов / ОС таким образом, чтобы код вашей библиотеки помещался в пакеты сайтов и исполняемые скрипты на системный путь.
До тех пор (т. е. для всех разработок) не делайте ничего из вышеперечисленного: избавьтесь от серьезных головных болей и используйте zc.buildout или virtualenv , чтобы сохранить ваш код разработки (и, если хотите, его зависимости) изолирован от остальной системы.
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
.
Сайт-пакеты, безусловно, предназначены для библиотек.
Гибридный подход может сработать: вы можете установить библиотеки, необходимые для вашего приложения, в пакеты сайтов, а затем установить основной модуль в другом месте.
Программа, запускаемая конечным пользователем, обычно находится где-то на их пути, причем большая часть кода находится в каталоге модуля, который часто находится в пакетах сайта.
Многие программы на Python будут иметь небольшой скрипт, расположенный в пути, который импортирует модуль и вызывает «основной» метод для запуска программы. Это позволяет программисту выполнить некоторые предварительные проверки и, при необходимости, изменить sys.path, чтобы найти нужный модуль.
Если вы можете превратить часть приложения в библиотеку и предоставить API, то сайт-пакеты - хорошее место для этого. На самом деле это именно то, что делают многие приложения Python.
Но с точки зрения пользователя или администратора это не является проблемой. Проблема в том, как мы можем управлять установленным материалом. Как я могу установить и удалить его после его установки?
Я использую Fedora. Если я использую Python, который поставляется с ним, мне не нравится устанавливать вещи в пакеты сайтов за пределами системы RPM. В некоторых случаях я сам собирал rpm для его установки.
Если я собираю свой собственный python вне RPM, то я, естественно, хочу использовать механизмы python для управления им.
Третий способ - использовать что-то вроде easy_install для установки такого. например, как домашний каталог пользователя.
Так