Менеджер версий python
Иногда полезно держать несколько версий python на одной машине. Допустим для разработки двух проектов нам необходима вторая и третья ветка python. Или вы поддерживаете проект который использует старую версию python.
Обычно для этого мы используем виртуальное окружение virtualenv или же обертку для него virtualenvwrapper. Об этом я рассказывать не буду, так как есть уже много подобных статей, да и в документациях к самим утилитам все очень хорошо объяснено. Достаточно только забить virtualenv или virtualenvwrapper в поисковик.
Но в дополнение к ним я хочу рассказать в этой статье про менеджер версий python. Кому любопытно прошу под кат.
Чтобы использовать несколько версий python, можно установить их вручную или воспользоваться менеджер версий. Таких есть два: pythonbrew(который более не развивается) и pyenv. Оба менеджера не поддерживают windows(pythonbrew, pyenv) так что питонистам пишущим на этой платформе, придется пока разруливать все руками, либо сделать свою утилиту для смены путей до нужных версий. Кто как справляется с данной ситуацией можете оставлять в комментариях.
Так как pythonbrew более не поддерживается в этой статье он рассмотрен не будет.
P.S. В статье приведены примеры проверенные для OS Ubuntu 12.04. При попытке повторить их, делайте поправки относительно своего дистрибутива.
Ручной способ
Для того чтобы работать с несколькими версиями питона, можно установить необходимые версии в указанный префикс. Например чтобы не мудрить с правами, установим дополнительно 2 версии python(2.7.6 и 3.3.2) в директорию пользователю:
2.7.6
для 3.3.2 делаем аналогичные операции:
Теперь можно создать виртуальное окружение чтобы использовать эти версии:
или через virtualenvwrapper:
Собственно на основании такого способа описана статья по созданию мультихостинга.
Далее если вам необходимо использовать какую-то из этих версий как python по умолчанию, то вам необходимо добавить в переменную окружения путь до интерпретатора python.
Соответственно вместо bashrc вы ставите bash_profile, zshrc, kshrc, profile в зависимости от вашей командной оболочки.
И по необходимости можно установить pip, предварительно установив setuptools.
Фух, ну вроде бы все. А теперь о том как можно сделать это проще использую менеджер версий python.
PyEnv
В общем если вы достаточно ленивы, то можно не делать всего того что описано выше а воспользоваться утилитой pyenv, которая упростит вам данное взаимодействие с окружением и путями.
Так в чем же заключается особенность этой утилиты? Вот что она может со слов автора проекта:
- Let you change the global Python version on a per-user basis.
- Provide support for per-project Python versions.
- Allow you to override the Python version with an environment variable.
- Search commands from multiple versions of Python at a time. This may be helpful to test across Python versions with tox.
По умолчанию все версии Python будут доступны в
/.pyenv/versions/ . Изменять версии Python можно как в глобальном контексте так и в локальном(например под конкретный проект).
Как ставить pyenv хорошо описывается в инструкции. Так же у автора есть скрипт который по мимо самой pyenv ставит еще и дополнительные плагины, в том числе и для virtualenv. Есть возможность установить плагин и для virtualenvwrapper.
Прежде чем начать установку, убедитесь, что у вас установлен git:
Далее устанавливаем по инструкции:
Во втором случае установка произойдет с дополнительными плагинами.
Далее, для того чтобы все заработало, дополним наш bashrc и перезагрузим оболочку:
Для обновления утилиты или смены ее версии используем git.
Для управления версиями pyenv необходимо перейти в директорию с утилитой:
Для просмотра доступных версий:
для смены версии
Пример использования
В добавок ко всему все довольно подробно и детально расписано у автора проекта в его репозиториях на github.
Виртуальное окружение
Все, а дальше как хотите. Если вы используете 3 ветку python то для создания виртуального окружения можно воспользоваться утилитой venv которая работает из коробки. Про это есть статья на хабре. Если вы больше привыкли к virtualenv или ее обертке virtualenvwrapper то тут есть два варианта: либо поставить плагин к pyenv, или использовать их к той версии python c которой вы работаете. Соответственно если выбрать первый вариант, то созданные вами окружения будут добавлены к вашим версиям python и доступны через команду:
Добавить плагин легко, просто клонируем его из репозитория pyenv-virtualenv или pyenv-virtualenvwrapper:
Пример использования можно посмотреть в документации для pyenv-virtualenv и pyenv-virtualenvwrapper.
Все, а дальше пользуйтесь, как вам привычнее.
Пример использования
Теперь находясь в директории проекта можно запускать скрипт от нужной версии python не прилагая никаких действий. pyenv создает в директории файл .python-version который содержит в себе информацию о том какую версию python с каким окружение использовать для данного проекта.
Источник
Установка нескольких версий Python параллельно при помощи pyenv
В большинстве операционных систем Python предустановлен (ну, кроме Windows, но даже там теперь есть команда python , которая предложит установить интерпретатор из магазина приложений). В Unix-подобных операционных системах, таких как Linux и MacOS, Python пустил корни очень глубоко. Множество компонентов ОС рассчитывают, что Python установлен и работает стабильно. Это и хорошо, и плохо.
Это хорошо, потому что хотя бы какой-то Python в большинстве систем доступен из коробки — бери и пользуйся. Иногда доступно сразу несколько версий интерпретатора, например, python2 указывает на устаревшую версию 2.7, python3 — на какую-нибудь стабильную версию Python 3, типа 3.6 или 3.7, а просто python указывает либо на одно, либо на другое (в последнее время предпочтение чаще отдаётся третьей версии). Для обучения или для тестирования этого может быть вполне достаточно.
С другой стороны, это плохо, потому что, как правило, предустановленный Python настолько стабилен, что уже успел зарасти мхом. В некоторых системах до сих пор предустановлен только Python 2, но даже если вам повезёт получить Python третьей версии, то наверняка он будет отставать от последней версии на пару минорных релизов. Не факт, что вам это подойдёт.
Иногда нужно иметь сразу несколько версий Python для работы над разными проектами, например, 3.7 и 3.8. В некоторых ОС нужные версии можно установить через пакетный менеджер (например, в Fedora через dnf) — из основных репозиториев или из сторонних. Но зачастую такие репозитории содержат не все релизы интерпретаторов, а лишь выбранное мейнтейнерами репозиториев подмножество.
Решение у всех этих проблем одно — нужно установить недостающие версии интерпретатора, какими бы они ни были. Этому и посвящён пост.
pyenv
pyenv — утилита, которая позволяет легко переключаться между несколькими версиями интерпретатора Python, а также устанавливать новые. Позволяет устанавливать, наверное, вообще все известные науке версии интерпретаторов Python. Работает просто и незаметно.
pyenv — это всего лишь один из последователей аналогичного инструмента из мира Ruby — rbenv . Есть ещё и nodenv для Node.js, который тоже вдохновился rbenv .
Проект написан целиком на bash . Это значит, что он никак не зависит от Python — было бы забавно, если бы для установки Python нужен был бы Python. Также это означает, что на Windows pyenv работать не будет (тред с обсуждением). Следует отметить, что в Windows проблема установки нескольких версий и не возникает — там всегда можно скачать и установить сколько угодно интерпретаторов с официального сайта, а pylauncher поможет выбрать из них нужную версию. Кроме того, пользователи современных версий Windows могут использовать pyenv внутри WSL (Windows Subsystem for Linux). Ещё это означает, что у авторов много отваги — я бы не решился писать на bash что-то настолько сложное. Как же хорошо, что всё уже написано.
Установка
Установка pyenv производится простым клонированием git-репозитория.
У проекта есть умный скрипт, который скачает pyenv и его сотоварищей:
Скрипт не требует прав суперпользователя (без sudo ), потому что всё устанавливается в домашнюю директорию пользователя. Туда же будут устанавливаться и интерпретаторы. Если страшно запускать какие-то скрипты из интернета (так и должно быть), то прочитать код скрипта можно здесь.
Предыдущая команда перед завершением должна была напечатать инструкции по настройке шелла. Допустим, в случае с bash она выводит следующее:
В случае с zsh нужно будет добавить те же самые строки в
В случае с fish в связи с особенностями самого шелла инструкции отличаются:
Кстати, горячо рекомендую попробовать fish , очень удобный шелл.
Установим зависимости для сборки.
При установке новой версии интерпретатора через pyenv под капотом происходит сборка из исходников, поэтому для успешной установки необходимы некоторые зависимости. Полный и актуальный список для своей ОС смотрите здесь или здесь. Лучше установить всё заранее.
Перезапустим шелл и проверим установку.
Как это работает
pyenv работает благодаря манипуляциям над переменной окружения $PATH . Эта переменная содержит в себе список директорий, в которых ОС будет искать исполняемые файлы, вызванные без указания полного пути. Именно благодаря этой переменной мы можем в терминале вместо /bin/cat вызывать просто cat . Когда мы набираем в терминале имя программы ( cat ), ОС перебирает директории из $PATH слева направо, пока в одной из них (в данном примере /bin ) не найдёт программу с именем cat , которую и запустит. Поиск прекращается после первого совпадения.
Команда pyenv init — , которую мы добавили в конфиг шелла ( .bashrc или аналог) добавляет директории pyenv в самое начало переменной $PATH . Зачем это нужно? pyenv создаёт небольшие исполняемые файлы, так называемые файлы-прослойки (shims), для всех команд, которыми он собирается управлять, например, python , pip , ipython и так далее. Эти файлы-прослойки должны попасть в $PATH прежде самих управляемых программ и «затенить» системные python , pip и так далее. Эти файлы-прослойки в конечном счёте просто вызывают сам pyenv с нужными аргументами. Таким образом pyenv перехватывает обращения к некоторым именам, и анализируя поступившую к нему информацию, принимает решение о том, какую именно версию Python нужно запустить. При выборе версии pyenv принимает во внимание следующие факторы в указанном порядке:
Переменная окружения PYENV_VERSION , если указана.
В неё можно указать какую конкретно версию Python нужно использовать в рамках текущего сеанса. Удобно, если вам по какой-то причине понадобится сменить выбранную версию интерпретатора, например, в одном из окон терминала.
Локальная версия Python.
При помощи специального файла .python-version можно настроить версию интерпретатора для определенного проекта. Захо́дите внутрь директории ( cd project/ ), и pyenv внезапно понимает, что нужно сменить Python. Выхо́дите обратно — версия Python меняется на глобальную. Это распространяется и на все поддиректории проекта — pyenv рекурсивно ищет файл .python-version вверх по файловой системе, пока не дойдёт до корня.
Глобальная версия Python.
/.pyenv/version записана глобальная версия Python, которая будет использоваться по умолчанию, если не сконфигурирована локальная версия.
Вам вряд ли придётся вручную трогать эти файлы, потому что у pyenv есть удобные команды ( pyenv local и pyenv global ), чтобы ими управлять, но знать о файлах всё равно полезно.
Использование
Установка новой версии Python
Сначала посмотрим, какие версии Python pyenv может установить:
Список довольно длинный, поэтому я его подсократил. Обычно вас будут интересовать такие версии, как 3.8.2 или 3.7.7 — это версии самой распространённой реализации интерпретатора CPython. Но если вам нужна экзотика, то pyenv умеет устанавливать любые сорта интерпретаторов Python ( pypy3.6-7.3.0 , stackless-3.7.5 , jython-2.7.1 , ironpython-2.7.7 , micropython-1.12 и т.д.). Для вас ведь не стало новостью, что существует много разных реализаций интерпретатора Python?
Установим CPython 3.8.2:
Через пару минут ожидания ваш новоиспечённый Python будет готов.
Можно сразу же назначить эту версию глобальной:
Давайте в целях демонстрации установим ещё парочку интерпретаторов:
Получим список установленных версий интерпретатора:
Кстати, если нужно, то можно делать активными сразу несколько версий одновременно:
Теперь вывод версий покажет следующее:
А работать это будет вот таким образом:
Грубо говоря, та версия, которая указана первой (3.8.2), имеет приоритет и занимает все нужные ей имена. Следующие версии (2.7.18) могут занять любые оставшиеся свободные имена (в данном случае, это только имя python2 ).
А файл глобальной версии
/.pyenv/version на данный момент имеет вот такое содержимое:
Локальная версия
Давайте создадим директорию и войдём в неё:
Представим, что в этой директории мы будем разрабатывать некий проект, на котором мы хотим опробовать фишки нового Python 3.9. Сообщим об этом pyenv :
В директории появился файл .python-version со следующим содержимым:
На данный момент список версий показывает следующее (удобно использовать эту команду, чтобы понять какую версию и почему pyenv активирует):
Изменения немедленно вступили в силу:
Но эта конфигурация никак не влияет на работу pyenv вне директории проекта:
Как и в случае с глобальной конфигурацией, можно локально активировать сразу несколько версий интерпретатора.
Установим IPython
Часто бывает нужно установить какой-нибудь пакет так, чтобы он тоже стал доступен из командной строки. Допустим, что нам нужно установить ipython — более удобную версию REPL Python. Сделаем это:
Программа сразу доступна, благодаря тому, что pyenv очень умный и создал новый файл-прослойку (shim) автоматически:
Вне директории с проектом ipython будет недоступен, ведь он же установлен в локальный интерпретатор 3.9.0a6 , а снаружи активирован другой интерпретатор — можете проверить самостоятельно.
Возникают ситуации, когда по какой-то причине прослойка не создалась или с ней случилось что-то ещё, например, удалилась:
Не беда! Можно попросить pyenv пересоздать их все заново:
И всё работает снова:
Можно вообще добавить команду pyenv rehash в свой
/.bashrc (или аналог), чтобы при запуске шелла гарантированно иметь рабочие файлы-прослойки (shims).
Заключение
pyenv — очень удобный и полезный инструмент в ситуациях, когда нужную вам версию Python нельзя установить средствами операционной системы. Я вообще предпочитаю устанавливать все нужные мне версии интерпретатора самостоятельно через pyenv или asdf , даже если ОС уже содержит точно такую же версию — пусть ОС использует свою копию для служебных целей, а я для разработки буду использовать свою собственную копию, где смогу проводить любые кровавые эксперименты, не боясь поломать ОС.
Обязательно подпишитесь на уведомления о новых постах в блоге, чтобы ничего не пропустить!
Источник
