Как развернуть приложение Python с библиотеками в качестве источника без каких-либо дополнительных зависимостей?

Question

Справочная информация : У меня есть небольшое приложение на Python, которое немного облегчает жизнь разработчикам, выпускающим программное обеспечение в нашей компании. Я строю исполняемый файл для Windows, используя py2exe. Приложение и бинарный файл проверяются в Subversion. Распространение происходит людьми, просто проверяющими каталог из SVN. Программа имеет около 6 различных зависимостей библиотеки Python (например, ElementTree, Mako)

Ситуация : разработчики хотят взломать источник этого инструмента, а затем запустить его, не создавая двоичный файл. В настоящее время это означает, что им нужен интерпретатор Python 2.6 (что хорошо), а также 6 локально установленных библиотек с использованием easy_install.

Проблема

• Это не общедоступная классическая среда с открытым исходным кодом: я нахожусь в корпоративной сети, инструмент никогда не покинет «огороженный сад», и у нас есть серьезные неудобства для выхода во внешний интернет (NTLM-аутентификаторы и или машины без прямого доступа в интернет).
• Я хочу, чтобы препятствия на пути к взлому этого инструмента были минимальными: никто не должен искать правильную зависимость в правильной версии, он должен выполнять как можно меньше настроек. Оптимальным условием было бы установить Python и просто проверить программу из Subversion.

Анекдот : Чем более замкнутый процесс, тем легче его повторить. Я поменял свою машину на новую и прошел через неприятный процесс необходимости перепроектировать зависимости, переустановить distutils, отыскать библиотеки в Интернете и заставить их установить (см. Корпоративные ограничения интернета выше).

Answer 1

Просто используйте virtualenv - это инструмент для создания изолированных сред Python. Вы можете создать установочный скрипт и распространять всю связку, если хотите.

Answer 2

Я иногда использую подход, который я описываю ниже, по той же причине, по которой @Boris заявляет: я бы предпочел, чтобы использование некоторого кода было так же просто, как a) svn checkout / update - b) go.

Но для записи:

• Большую часть времени я использую virtualenv / easy_install.
• Я в определенной степени согласен с критикой @Ali A и @ S.Lott

В любом случае, подход, который я использую, зависит от модификации sys.path и работает следующим образом:

• Требуется python и setuptools (чтобы разрешить загрузку кода из яиц) на всех компьютерах, которые будут использовать ваше программное обеспечение.
• Организуйте свою структуру каталогов следующим образом:

project/
    *.py
    scriptcustomize.py
    file.pth

    thirdparty/
        eggs/
            mako-vNNN.egg
            ... .egg
        code/
            elementtree\
                *.py
            ...

• В ваши скрипты верхнего уровня включите следующий код вверху:

from scriptcustomize import apply_pth_files
apply_pth_files(__file__)

• Добавьте scriptcustomize.py в папку вашего проекта:

import os
from glob import glob
import fileinput
import sys

def apply_pth_files(scriptfilename, at_beginning=False):
    """At the top of your script:
    from scriptcustomize import apply_pth_files
    apply_pth_files(__file__)

    """
    directory = os.path.dirname(scriptfilename)
    files = glob(os.path.join(directory, '*.pth'))
    if not files:
        return
    for line in fileinput.input(files):
        line = line.strip()
        if line and line[0] != '#':
            path = os.path.join(directory, line)
            if at_beginning:
                sys.path.insert(0, path)
            else:
                sys.path.append(path)

• Добавьте один или несколько * .pth файлов в папку вашего проекта. В каждой строке поместите ссылку на каталог с пакетами. Например:

# contents of *.pth file
thirdparty/code
thirdparty/eggs/mako-vNNN.egg

• Мне "отчасти" нравится такой подход. Что мне нравится: это похоже на работу файлов * .pth, но для отдельных программ, а не для всего вашего сайта-пакета. Что мне не нравится: необходимость добавлять две строки в начале скриптов верхнего уровня.
• Опять же: я использую virtualenv большую часть времени. Но я склонен использовать virtualenv для проектов, где у меня есть жесткий контроль над сценарием развертывания. В случаях, когда у меня нет жесткого контроля, я склонен использовать подход, который я описал выше. Это позволяет легко упаковать проект в zip-архив и заставить конечного пользователя «установить» его (разархивировав).

Answer 3

«Мне не нравится тот факт, что разработчики (или я начинаю на чистой новой машине) вынуждены перепрыгивать через обходы distutils необходимости устанавливать библиотеки локально, прежде чем они смогут начать работу»

Почему?

Что конкретно - с этим не так?

Вы сделали это, чтобы создать проект. Ваш проект настолько популярен, что другие хотят сделать то же самое.

Я не вижу проблемы. Пожалуйста, обновите ваш вопрос с конкретными проблемами, которые вам нужно решить. Не нравится то, как распределяется открытый исходный код, это не проблема - это то, как работает открытый исходный код.

Редактировать . «Обнесенный стеной сад» не имеет большого значения.

Вариант 1. Кстати, вы можете создать «установщик», который запускает easy_install для них 6 раз.

Вариант 2. Вы можете сохранить все установочные наборы, которые использовал бы easy_install. Затем вы можете предоставить скрипт, который выполняет распаковку и python setup.py install для всех шести.

Вариант 3. Вы можете предоставить версию site-packages в архиве. После установки Python они разархивируют каталог вашего сайта-пакета в `C: \ Python2.5 \ lib \ site-packages``.

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

Вариант 5. Вы можете разместить свой собственный pypi-подобный сервер и предоставить easy_install, который сначала проверит ваш сервер.

Answer 4

Я не утверждаю, что это отличная идея, но обычно в подобных ситуациях я делаю так, чтобы у меня был Makefile, проверенный на subversion, который содержит правила make для извлечения всех зависимых библиотек и их установки. Makefile может быть достаточно умным, чтобы применять зависимые библиотеки, только если они отсутствуют, поэтому это может быть относительно быстро.

Новый разработчик проекта просто извлекает данные из Subversion и затем набирает «make».

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

Answer 5

Я согласен с ответами Носкло и С. Лотта. (+1 к обоим)

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

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

Затем возникают конкретные проблемы, такие как «что, если один пользователь захочет установить другую версию или реализацию библиотеки?», Яркий пример здесь - ElementTree, поскольку он имеет ряд реализаций.