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

Question

короткая версия: как мне избавиться от кошмара с несколькими версиями python?

длинная версия: на протяжении многих лет я использовал несколько версий python, и, что еще хуже, несколько расширений для python (например, pygame, pylab, wxPython ...). Каждый раз, когда он был на другой установке, с разными операционными системами, иногда разными архитектурами (как мой старый PowerPC mac).

В настоящее время я использую Mac (OSX 10.6 на x86-64), и это кошмар зависимости каждый раз, когда я хочу восстановить сценарий старше нескольких месяцев. Сам Python уже поставляется в трех разных вариантах в /usr/bin (2.5, 2.6, 3.1), но мне пришлось установить 2.4 из macports для pygame, что-то еще (не помню, что) заставило меня установить все три других из macports, так что, в конце концов, я счастливый обладатель семи (!) экземпляров python в моей системе.

Но это не проблема, проблема в том, что ни в одной из них не установлены правильные (то есть, тот же набор) библиотеки, некоторые из них 32-битные, некоторые 64-битные, и теперь я в значительной степени потерян.

Например, прямо сейчас я пытаюсь запустить трехлетний скрипт (не написанный мной), который использовал matplotlib / numpy для рисования графика в реальном времени в прямоугольнике окна wxwidgets. Но я с треском проваливаюсь: py26-wxpython из macports не будет установлен, стандартный python включает wxwidgets, но также имеет некоторый конфликт между 32 битами и 64 битами, и он не имеет клочка ... какой беспорядок!

Очевидно, я делаю вещи неправильно. Как вы обычно справляетесь со всем этим хаосом?

Answer 1

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

virtualenv my_env

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

source my_env/bin/activate

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

Чтобы выйти из окружения, просто наберите

deactivate

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

rm -rf my_env

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

virtualenv отлично. ;)

Answer 2

Несколько советов:

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

Это похоже на еще больший беспорядок, но, по крайней мере, все работает именно так. По сути, если один из проектов работает в virtualenv, он будет работать независимо от того, какие обновления вы выполняете, поскольку вы никогда не меняете «системные» установки.

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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

Answer 6

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

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

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

Answer 7

Мне повезло, используя Buildout. Вы устанавливаете список, какие яйца и какие версии вы хотите. Затем Buildout загружает и устанавливает частные версии каждого для вас. Это делает частный двоичный файл "python" со всеми уже установленными яйцами. Местные «тесты на нос» облегчают отладку. Вы можете расширить сборку своими собственными функциями.

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

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

Answer 8

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