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

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

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

Проблема

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

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

13
bootstrapping deployment layout python

5 ответов

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

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

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

во всяком случае, подход, который я использую, зависит от изменения sys.путь, и работает как это:

  • Require 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
  • мне "вроде как" нравится такой подход. Что мне нравится: это похоже на то, как *.ПТГ файлы работают, но для отдельных программ, а не весь сайт-пакеты. Что мне не нравится: нужно добавить две строки в начале скриптов верхнего уровня.
  • снова: я использую virtualenv большую часть времени. Но я склонен использовать virtualenv для проектов, где у меня есть жесткий контроль сценария развертывания. В тех случаях, когда у меня нет жесткого контроля, я склонен использовать описанный выше подход. Это позволяет очень легко упаковать проект в виде zip и "установить" его конечным пользователем (путем распаковки).
8

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

9

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

почему?

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

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

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

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

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

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

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

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

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

8

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

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

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

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

0

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

новый разработчик проекта просто проверяет из subversion, а затем вводит "make".

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

0