Как поддерживать долгоживущие проекты python w.r.t. зависимостей и версий python?

Ответ 1

Некоторые советы:

• в Mac OS X используйте только установку python в /Library/Frameworks/Python.framework.
• всякий раз, когда вы используете numpy/scipy/matplotlib, установите дистрибутив python с enthought.
• используйте virtualenv и virtualenvwrapper, чтобы сохранить эти "системные" установки нетронутыми; в идеале использовать одну виртуальную среду для каждого проекта, поэтому выполняются все зависимости проекта. И, да, это означает, что потенциально много кода будет реплицироваться в различных виртуальных envs.

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

Ответ 2

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

virtualenv my_env

Это создает новое бинарное и библиотечное расположение python и символические ссылки на существующие системные библиотеки по умолчанию. Затем, чтобы переключить пути для использования новой среды, вы делаете это:

source my_env/bin/activate

Что это. Теперь, если вы устанавливаете модули (например, с помощью easy_install), они устанавливаются в каталог lib каталога my_env. Они не мешают существующим библиотекам, вы не получаете странных конфликтов, вещи не перестают работать в вашей старой среде. Они полностью изолированы.

Чтобы выйти из среды, просто сделайте

deactivate

Если вы решите, что сделали ошибку с установкой или больше не хотите эту среду, просто удалите каталог:

rm -rf my_env

И все готово. Это действительно так просто.

virtualenv отлично.;)

Ответ 3

Взгляните на virtualenv.

Ответ 4

Обычно я пытаюсь (постепенно) идти в ногу с версиями Python по мере их появления (и как только все внешние зависимости имеют правильные версии).

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

Моя самая большая работа проекта @python (15.000+ LOC) теперь находится на Python 2.6 через несколько месяцев (обновление всего из Python 2.5 заняло большую часть дня из-за установки/проверки 10+ зависимостей...)

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

Ответ 5

• установите версии python, которые вам нужны, лучше, если из источников
• когда вы пишете script, включите в него полную версию python (например, #!/usr/local/bin/python2.6)

Я не вижу, что может пойти не так.

Если что-то делает, это, вероятно, все равно приведет к отказу в копировании, а не к вашей (одна из причин, по которой я больше не использую macports).

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

Ответ 6

Я использую версию MacPorts для всего, но, как вы заметили, многие версии по умолчанию необычно стары. Например, vim omnicomplete в Snow Leopard имеет python25 как зависимость. Многие порты, связанные с python, имеют старые зависимости, но обычно вы можете указывать новую версию во время сборки, например port install vim +python26 вместо port install vim +python. Сделайте сухой прогон перед установкой чего-либо, чтобы увидеть, если вы тянете, например, весь python24, когда это не является необходимым. Регулярно проверяйте portfiles, потому что соглашение об именах как порты Дарвина выходит из-под земли, оставляя желать лучшего. На практике я просто оставляю все в папках по умолчанию /opt... MacPorts, включая копию всей структуры с дубликатами PyObjC и т.д., И просто придерживаюсь одной версии за раз, сохраняя возможность возврата к системному умолчанию если что-то неожиданно ломается. Это, возможно, слишком много работы, чтобы избежать использования virtualenv, о котором я хотел бы поговорить.

Ответ 7

Мне повезло с помощью Buildout. Вы создали список яиц и какие версии вы хотите. Buildout затем загружает и устанавливает для вас частные версии. Он создает частный двоичный код "python" со всеми уже установленными яйцами. Локальные "nosetests" упрощают отладку. Вы можете расширить сборку своими собственными функциями.

С другой стороны, Buildout может быть довольно загадочным. Сделайте "buildout -vvvv" какое-то время, чтобы увидеть, что именно он делает и почему.

http://www.buildout.org/docs/tutorial.html

Ответ 8

Как минимум в Linux, несколько питонов могут сосуществовать довольно счастливо. Я использую Python 2.6 в системе CentOS, для которой Python 2.4 требуется по умолчанию для различных системных вещей. Я просто скомпилировал и установил python 2.6 в отдельное дерево каталогов (и добавил соответствующий каталог bin на мой путь), который был довольно безболезненным. Затем он вызывается путем ввода "python2.6".

Как только вы запускаете и запускаете отдельные питоны, установка библиотек для конкретной версии проста. Если вы вызываете setup.py script с помощью python, который вы хотите, он будет установлен в каталогах, соответствующих этому питону, и скрипты будут установлены в том же каталоге, что и сам исполняемый файл python, и будут автоматически использовать правильный питон при вызове.

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