Как распространять программное обеспечение python на ОС Linux - PullRequest
Новая
       22

Как распространять программное обеспечение python на ОС Linux

0 голосов
/ 03 февраля 2020

сжатая версия того, чего я хочу достичь : создайте пакеты .rpm и .deb из моего исходного кода source.py и убедитесь, что все зависимости разрешены при их установке на основе deb / rpm linux дистрибуция.

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

---MyProgram          Folder
   ---MyProgram       Folder
       ---img         Folder
          ---logo.ico File
       ---media       Folder
          ---head.txt File
       ---__init__.py File
       ---source.py   File
       ---a.py        File
   ---LICENSE         File
   ---README.md       File
   ---setup.py        File

Настройка файла. py содержит следующее: 

import setuptools

with open("README.md", "r") as fh:
    long_description = fh.read()

setuptools.setup(
    name="MyProgram",
    version="0.0.1",
    author="First Last",
    author_email="email@memore.com",
    description="A tool to create nice things",
    long_description=long_description,
    long_description_content_type="text/markdown",
    url="https://google.com",
    packages=setuptools.find_packages(),
    classifiers=[
        "Programming Language :: Python :: 3",
        "License :: OSI Approved :: MIT License",
        "Operating System :: OS Independent",
    ],
    python_requires='>=3.7',
    data_files=[
    ('.../MyProgram/img/logo.ico'),
    ('.../MyProgram/media/head.txt'),
],
)

Теперь я запускаю 

python setup.py sdist bdist_rpm

из строки cmd в «... / MyProgram». Создаются две папки 'dist' и 'build', а также 'MyProgram.tar.gz' и 'MyProgram-noarch.rpm' в двух rpm и 'MyProgram-sr c .rpm'. Когда я пытаюсь установить 'noarch.rpm' в fedora 31, процесс успешно завершается, но «ярлык» не создается, и когда я набираю MyProgram в строке cmd, он не обнаруживается. 

rpm -ql MyFilter

находит он выводит несколько путей: 

/usr/lib/python3.7/site-packages/MyProgram/...
/usr/lib/python3.7/site-packages/MyProgram/source.py
/usr/lib/python3.7/site-packages/MyProgram/a.py
....

Что говорит мне о том, что моя установка по крайней мере скопировала файловую систему basi c. Но я также вижу, что все исходные файлы .py по-прежнему являются файлами .py.

Мои вопросы:

  • Как я могу «сделать» об / мин так что все зависимости содержатся в rpm или, по крайней мере, разрешаются с помощью dnf / apt / yum при установке rpm? В другой формулировке: возможно ли объединить все зависимости в rpm / deb, как, например, в .exe?
  • Как я могу указать путь, например, '/ usr / bin' или 'usr / share' как цель установки dir?
  • Как я могу добавить приложение запуска, включенное в rpm / deb?
  • Является ли все вышесказанное хорошим способом сделать это вообще?

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

https://docs.python.org/2.0/dist/creating-rpms.html

https://github.com/AppImage/AppImageKit/wiki/Bundling-Python-apps

Python 3.5 создать .rpm с помощью сгенерированного Pyinstaller исполняемого файла

https://github.com/junaruga/rpm-py-installer

https://www.pyinstaller.org/

https://packaging.python.org/overview/#python -источники-распределения

https://packaging.python.org/overview/

https://pyinstaller.readthedocs.io/en/stable/usage.html

https://pyinstaller.readthedocs.io/en/stable/installation.html

https://python-packaging-tutorial.readthedocs.io/en/latest/setup_py.html

1 Ответ

0 голосов
/ 04 февраля 2020

Только мои два цента, а не полный ответ. Будет касаться в основном RPM-упаковки.

Опция bdist_rpm кажется простой, но вы мало контролируете logi c файла .spec, который он генерирует / использует, и не можете выполнять такие фантастические вещи, как скрипты, et c.

То есть, если вы не воспользуетесь тем, что он сгенерирует файл .spec и выйдет (вместо построения конечного RPM). Из документов :

Если вы sh, вы можете отделить эти три шага. Вы можете использовать опцию --spe c -only, чтобы bdist_rpm просто создал файл .spe c и завершился; в этом случае файл .spe c будет записан в «каталог распространения» - обычно это dist /, но настраивается с помощью параметра --dist-dir. (Обычно файл .spe c оказывается глубоко в «дереве компоновки», во временном каталоге, созданном bdist_rpm.)

Но в качестве предпочтения и последовательности я бы посоветовал следуя указаниям дистрибутива c для упаковки Python приложений.

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

Это не Самый простой способ, хотя. Вам придется перебирать некоторые документы . По сути, если вы собираете что-то для CentOS / RHEL, следует соблюдать рекомендации Fedora по упаковке.

Дополнительную ссылку можно найти здесь , с примером файла .spec для сборки Python 2 и 3 версии одного и того же приложения.

Для всей этой «сборки как дистрибутива» вы определенно захотите использовать mock для работы, для сборки вашего пакета в a ch root.

Что касается проблемы с «ярлыком», вам нужно, чтобы ваш setup.py объявил несколько консольных сценариев, чтобы он создавался при установке вашего пакета. Например, lastversion's setup.py : 

entry_points={"console_scripts": ["lastversion = lastversion:main"]},

Эта запись приведет к созданию / установке двоичного файла lastversion (который запускает определенную функцию) при установке Python package.

Впоследствии в файлах spe c макрос %py2_install будет использовать setup.py для создания той же программы запуска.

И тогда вы сможете чтобы убедиться, что модуль запуска упакован, поместите его в раздел файлов файла spe c: 

%files -n python3-myapp
%license COPYING
%doc README.rst
%{python3_sitelib}/%{srcname}/
%{python3_sitelib}/%{srcname}-*.egg-info/
%{_bindir}/myapp
...