Автономные приложения Python в Linux

Неа.

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

Обновление 2019: я поддерживаю это. Virtualenv - это способ объединения библиотек и интерпретаторов вместе. Tox - это инструмент тестирования для проверки этой матрицы интерпретатора / зависимостей. Docker - это широко используемый способ развертывания пакета.

Вы не можете легко сделать это в формате, нейтральном к распространению. Единственные надежные механизмы отслеживания зависимостей встроены в системы управления пакетами в дистрибутивах и будут отличаться от дистрибутива к дистрибутиву. Фактически вам нужно будет сделать rpm для Fedora, debs для ubuntu и debian и т. д.

Py2exe отлично работает в Windows. Он создает дистрибутив со всеми необходимыми DLL и оболочкой для интерпретатора python, запускающего вашу программу. Его довольно просто установить - просто поместите его в каталог, поэтому создать для него msi-файл несложно.

Вы можете посмотреть объявления зависимостей в setuptools. Это может обеспечить способ гарантировать, что нужные пакеты либо доступны в среде, либо могут быть установлены кем-то с соответствующими привилегиями.

Создайте deb (для всего, что происходит от Debian) и rpm (для Fedora / SuSE). Добавьте правильные зависимости в упаковку, и вы можете быть уверены, что она будет работать.

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

Я собираю «сторонний» каталог, который включает все необходимые компоненты, и использую site.addsitedir, поэтому их не нужно устанавливать глобально.

# program startup code
import os
import sys
import site
path = os.path.abspath(os.path.dirname(__file__))
ver = 'python%d.%d' % sys.version_info[:2]
thirdparty = os.path.join(path, 'third-party', 'lib', ver, 'site-packages')
site.addsitedir(thirdparty)

У большинства моих предварительных требований есть установщики setup.py. Каждый связанный модуль получает свой собственный процесс «установки», поэтому любые настраиваемые компоненты (например, ./configure) могут запускаться автоматически. Мой сценарий установки запускает этот make-файл как часть процесса установки.

# sample third-party/Makefile
PYTHON_VER = `python -c "import sys; \
        print 'python%d.%d' % sys.version_info[:2]"`
PYTHON_PATH = lib/$(PYTHON_VER)/site-packages
MODS = egenix-mx-base-3.0.0 # etc

.PHONY: all init clean realclean $(MODS)
all: $(MODS)
$(MODS): init
init:
    mkdir -p bin
    mkdir -p $(PYTHON_PATH)
clean:
    rm -rf $(MODS)
realclean: clean
    rm -rf bin
    rm -rf lib

egenix-mx-base-3.0.0:
    tar xzf [email protected]
    cd $@ && python setup.py install --prefix=..
    rm -rf $@

Стандартный способ питона - создать питон «Яйцо».

Вы можете взглянуть на этот учебник или эта страница об инструментах настройки.

Для этого вы можете использовать cx_Freeze. Это похоже на py2exe (объединяет интерпретатор и сценарий запуска, а также все необходимые библиотеки и модули), но работает как в Linux, так и в Windows.

Он собирает зависимости из среды, в которой он запущен, а это означает, что они также должны подходить для места назначения. Если вы делаете что-то вроде создания на 32-битном Debian и развертывания на другом 32-битном Debian, то это нормально. Вы можете справиться с 32- и 64-битными различиями, создав несколько версий в соответствующих средах (например, 32-битные и 64-битные chroot-файлы) и распространив соответствующую. Если вам нужно что-то более общее (например, сборка на Debian, развертывание в любом дистрибутиве), это становится немного неясным, в зависимости от того, какие именно ваши зависимости.

Если вы делаете довольно простое распространение (то есть знаете, что ваша среда сборки и среда развертывания похожи), тогда это позволяет избежать довольно сложного шага rpm / deb / egg / etc (использовать cx_Freeze очень просто, особенно если вы знаком с py2exe). Если нет, то все, от развертывания вашего собственного установщика зависимостей до сборки deb / rpm / egg / etc, будет работать, в зависимости от того, сколько работы вы хотите выполнить, насколько гибкости с требуемыми версиями вы хотите предложить, и каковы зависимости.

Я думаю, что вы можете с уверенностью принять как должное поддержку Python в большинстве современных дистрибутивов Linux - для тех, у кого она отсутствует, пока выдается нормальное сообщение об ошибке, пользователи, вероятно, должны иметь возможность работать, как получить ее самостоятельно (вы можете использовать простой сценарий запуска bash для этого):

#!/bin/bash
if [ -e /usr/bin/python ]
then
    echo "Python found!"
else
    echo "Python missing!"
fi