Как поддержать долговечные проекты Python w.r.t. версии Python и зависимости?
короткая версия: как я могу избавиться от multiple-versions-of-python кошмара?
долгая версия: за эти годы я использовал несколько версий Python, и что хуже, несколько расширений Python (например, pygame, pylab, wxPython...). Каждый раз это было на различной установке, с различными Ose, иногда различная архитектура (как мой старый 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 битами, и он не имеет numpy... что путаница!
Очевидно, я делаю вещи неправильный путь. Как Вы usally справляетесь со всем тем хаосом?
8 ответов
Некоторые советы:
- в Mac OS X используйте только установку python в
/ Library / Frameworks /Python.framework. - всякий раз, когда вы используете numpy / scipy / matplotlib, устанавливайте продуманный дистрибутив python
- , используйте virtualenv и virtualenvwrapper, чтобы эти "системные" установки оставались нетронутыми; в идеале используйте одну виртуальную среду для каждого проекта, чтобы выполнялись зависимости каждого проекта. И да, это означает, что потенциально большой объем кода будет реплицирован в различных виртуальных средах.
Это действительно кажется большим беспорядком, но, по крайней мере, все так работает. По сути, если один из проектов работает в virtualenv, он будет продолжать работать независимо от того, какие обновления вы выполняете, поскольку вы никогда не меняете «системные» установки.
Я решаю эту проблему с помощью virtualenv . Я сочувствую желанию избежать дальнейших слоев кошмарной абстракции, но virtualenv на самом деле удивительно чист и прост в использовании. Вы буквально делаете это (командная строка, Linux):
virtualenv my_env
Это создает новое расположение двоичного файла и библиотеки python и по умолчанию создает символические ссылки на существующие системные библиотеки. Затем, чтобы переключить пути для использования новой среды, сделайте следующее:
source my_env/bin/activate
Вот и все. Теперь, если вы устанавливаете модули (например, с помощью easy_install ), они устанавливаются в каталог lib каталога my_env . Они не мешают существующим библиотекам, у вас не возникает странных конфликтов, все не перестает работать в вашей старой среде. Они полностью изолированы.
Чтобы выйти из среды, просто выполните
deactivate
Если вы решите, что допустили ошибку при установке или вам больше не нужна эта среда, просто удалите каталог:
rm -rf my_env
И все готово. Это действительно так просто.
virtualenv великолепен. ;)
Я использую версию MacPorts для всего, но, как вы заметили, многие версии по умолчанию очень старые. Например, vim omnicomplete в Snow Leopard имеет python25 в качестве зависимости. Многие связанные с python порты имеют старые зависимости, но обычно вы можете пометить более новую версию во время сборки, например port install vim + python26 вместо port install vim + python . Выполните пробный запуск перед установкой чего-либо, чтобы увидеть, загружаете ли вы, например, весь python24, когда в этом нет необходимости. Проверяйте файлы портов часто, потому что соглашение об именах портов Дарвина только начинало оставлять желать лучшего. На практике я просто оставляю все в папках MacPorts по умолчанию / opt ... , включая копию всего фреймворка с дубликатами PyObjC и т. Д., И просто придерживаюсь одной версии за раз, сохраняя возможность вернуться к системным значениям по умолчанию, если что-то неожиданно сломается. Возможно, это слишком большая работа, чтобы избежать использования virtualenv , который я собирался использовать.
Обычно я стараюсь (постепенно) поддерживать версии Python по мере их появления (и как только все внешние зависимости имеют корректные версии).
В большинстве случаев сам код Python может быть перенесен как есть, с небольшими необходимыми изменениями.
Мой самый большой проект Python на работе (15.000+ LOC) уже несколько месяцев работает на Python 2.6 (обновление всего с Python 2.5 заняло почти целый день из-за установки/проверки 10+ зависимостей...)
В целом, я думаю, это лучшая стратегия для большинства взаимозависимых компонентов в стеке свободных программ (вспомните зависимости в репозиториях программ linux): поддерживайте свои версии (полу-)актуальными (или, по крайней мере, прогрессирующими в том же темпе).
- установите нужные вам версии Python, лучше из источников
- , когда вы пишете скрипт, включите в него полную версию Python (например,
#! / Usr / local / bin / python2.6)
Я не понимаю, что может пойти не так.
Если что-то и произошло, то это, скорее всего, ошибка macports, а не ваша (одна из причин, по которой я больше не использую macports).
Я знаю, что, вероятно, что-то упустил, и это будет отклонено, но, пожалуйста, оставьте хотя бы небольшой комментарий в этом случае, спасибо :)
Мне повезло с использованием Buildout. Вы задаете список того, какие яйца и какие версии вам нужны. Затем Buildout загружает и устанавливает частные версии каждого из них для вас. Он создает приватный двоичный файл "python" со всеми уже установленными яйцами. Локальный "nosetests" облегчает отладку. Вы можете расширить сборку своими собственными функциями.
С другой стороны, Buildout может быть довольно загадочным. Выполните "buildout -vvvvv" на некоторое время, чтобы понять, что именно он делает и почему.
По крайней мере, в Linux несколько питонов могут довольно успешно сосуществовать. Я использую Python 2.6 в системе CentOS, которой требуется Python 2.4 по умолчанию для различных системных вещей. Я просто скомпилировал и установил python 2.6 в отдельное дерево каталогов (и добавил соответствующий каталог bin в свой путь), что было довольно безболезненно. Затем он вызывается путем ввода «python2.6».
После того, как у вас есть отдельные питоны, установка библиотек для конкретной версии становится простой задачей. Если вы вызываете скрипт setup.py с нужным питоном, он будет установлен в каталогах, соответствующих этому питону, а скрипты будут установлены в том же каталоге, что и сам исполняемый файл python, и будут автоматически использовать правильный питон при вызове.
Я также стараюсь избегать использования слишком большого количества библиотек. Когда мне нужна только одна или две функции из библиотеки (например, scipy), я часто смотрю, могу ли я просто скопировать их в свой собственный проект.