- Pyenv — установка нескольких версий Python для разных проектов
- Что такое Pyenv?
- Как работает pyenv?
- Установка Pyenv в Linux
- Установка нескольких версий Python в Linux
- Несколько версий Python на Linux-машине
- Использование нескольких версий Python на unix-подобных операционных системах.
- Что и зачем?
- Установка Python из репозиториев пакетов операционной системы.
- Сборка из исходного кода.
- pyenv
- Установка системным пакетным менеджером из сторонних источников.
- Псевдонимы python , python2 , python3 .
- Установка poetry на системы с разными версиями Python
- Установка в выделенное виртуальное окружение
- Установка нескольких версий Python параллельно при помощи pyenv
- pyenv
- Установка
- Как это работает
- Использование
- Установка новой версии Python
- Локальная версия
- Установим IPython
- Заключение
Pyenv — установка нескольких версий Python для разных проектов
Оригинал: Pyenv – Install Multiple Python Versions for Specific Project
Автор: Aaron Kili
Дата публикации: 29 июня 2018 года
Перевод: А. Кривошей
Дата перевода: июль 2018 г.
Управление несколькими версиями Python в системе Linux — непростая задача, особенно для начинающих. Иногда даже становится все хуже, Если вы хотите разрабатывать и запускать несколько проектов с разными версиями Python на одном сервере, это может привести к серьезным проблемам. Однако этих проблем можно избежать, если вы используете pyenv.
Что такое Pyenv?
Pyenv — это простой, мощный и кроссплатформенный инструмент для управления несколькими версиями Python в Linux-системах, он используется для:
— переключения глобальной версии Python для каждого пользователя;
— установки локальной версии Python для каждого проекта;
— управления виртуальными средами, созданными anaconda или virtualenv;
— переопределения версии Python с переменной окружения;
— поиска команд из нескольких версий Python и для многого другого.
Как работает pyenv?
Как правило, версия Python по умолчанию используется для запуска всех ваших приложений, если вы явно не укажете версию, которую хотите использовать в приложении. Но pyenv реализует простую концепцию использования прокладок (легкие исполняемые файлы), чтобы передать вашу команду правильной версии Python, которую вы хотите использовать, когда у вас установлено несколько версий.
Эти прокладки вставлены pyenv в каталоги перед вашим PATH. Поэтому, когда вы запускаете команду Python, она перехватывается соответствующей прокладкой и передается в pyenv, который затем задает версию Python, указанную вашим приложением, и передает ваши команды правильной версии Python.
В этой статье мы покажем, как установить последнюю версию pyenv в Linux. Мы также продемонстрируем первые три случая использования, из перечисленных выше.
Установка Pyenv в Linux
1. Сначала установите все необходимые пакеты для установки разных версий Python из исходного кода, используя приведенные ниже команды для вашего дистрибутива Linux.
В Debian/Ubuntu/Linux Mint
2. Затем возьмите последнее дерево исходного кода pyenv из репозитория Github и установите его в $HOME/.pyenv, используя следующую команду.
3. Теперь вам нужно установить переменную среды PYENV_ROOT, чтобы указать путь, по которому вы установили pyenv и экспортировать его. Затем добавьте $PYENV_ROOT/bin в PATH для запуска утилиты командной строки pyenv.
Вам также необходимо включить прокладки, а также автодополнение, добавив pyenv init в свою оболочку. Сделайте все это в своем стартовом файле $HOME /.bashrc bash, как показано ниже.
Скопируйте и вставьте следующие строки в конце этого файла.
4. После того, как вы внесли вышеуказанные изменения, вы можете либо перезагрузить файл $HOME/.bashrc, либо перезапустить оболочку, как показано ниже.
Установка нескольких версий Python в Linux
5. На этом этапе вы должны быть готовы начать использовать pyenv. Перед установкой любой версии Python вы можете просмотреть все доступные версии с помощью этой команды:
6. Теперь вы можете установить несколько версий Python с помощью pyenv.
7. Чтобы вывести список всех версий Python, доступных для pyenv, выполните приведенную ниже команду. Она будет показывать только версии, установленные через pyenv.
8. Вы можете проверить глобальную версию Python с помощью приведенной ниже команды, к этому моменту версия по умолчанию должна быть единственной, что установлена системой, а не pyenv.
Вы можете установить глобальную версию python с помощью команды pyenv:
9. Теперь вы можете установить локальную версию Python для каждого проекта, например, если у вас есть проект, расположенный в $HOME/python_projects/test, вы можете установить для него версию Python с помощью следующей команды:
10. Pyenv управляет виртуальными средами через плагин pyenv-virtualenv, который автоматизирует управление виртуальными и консольными средами для Python в Linux и других UNIX-подобных системах.
Вы можете начать с установки этого плагина с попомщью следующих команд:
11. Теперь мы создадим тестовую виртуальную среду, называемую venv_project1, в проекте под названием project1:
12. Теперь, когда вы выводите все версии Python, также должны быть указаны ваши виртуальные среды, а также их локальные версии python, как показано на скриншоте.
13. Чтобы активировать virtualenv, например для venv_project1, введите следующую команду:
Примечание. При использовании последней версии плагина pyenv-virtualenv в первый раз, вы можете получить приведенное ниже сообщение:
в ваш файл $HOME/.bashrc и перезагрузите его.
14. Чтобы отключить активированный virtualenv, запустите следующую команду:
Для получения дополнительной информации вы можете вывести все команды pyenv:
Подробнее о использовании языка Python и программировании на нем вы можете узнать из следующих статей на нашем сайте:
Источник
Несколько версий Python на Linux-машине
Использование нескольких версий Python на unix-подобных операционных системах.
Что и зачем?
Python как язык постоянно развивается. Ветка Py2 скоро будет объявлена неподдерживаемой. Однако до сих пор существуют окружения, где приходится использовать Py2 и даже не свежий 2.7.x, а что-то по-старее. Да и Python 3.x нынче — это большое семейство версий, кое-где несовместимых между собой, в т.ч. и синтаксически! Поэтому практикующий питонист широкого профиля должен понимать, как на одной машине иметь несколько версий среды исполнения. Даже если “в продакшне” и используется какой-нибудь Docker!
Установка Python из репозиториев пакетов операционной системы.
Если вам повезло, то в репозитории пакетов ОС будет нужная версия Python и вы сможете её установить с помощью команды вроде sudo apt-get install python3.5 . Однако достаточно старые дистрибутивы ОС могут не содержать новых версий Python, а достаточно новые дистрибутивы — старых версий Python. В особых случаях репозиторий вообще может содержать только одну версию среды исполнения.
Сборка из исходного кода.
CPython — проект с исходным кодом. Доступ к исходному коду всех версий CPython позволяет собрать нужную версию самостоятельно. Однако это процесс, пусть и достаточно хорошо документирован, но всё же требует понимания того, что вам может потребоваться для компиляции кода под вашу операционную систему.
А ещё сборка из исходного кода — это единственный вариант для тех, кто хочет что-то в этом самом коде изменить или скомпилировать интерпретатор для какой-то экзотической платформы (встраиваемые системы, ретро-железо).
pyenv
Ещё одним из способов получения разных версий среды исполнения на одной машине является pyenv. Это “менеджер версий”, выполненный в стиле rbenv для Ruby, nvm для NodeJS и т.п.
Миссия pyenv — управлять установленными версиями Python и делать некую версию “активной”. Активная версия вызывается, если мы выполняем команду python (а также pip ), при этом разные проекты могут использовать разные активные версии и даже более чем одну одновременно. Последнее свойство полезно авторам библиотек, рассчитанных на широкий круг пользователей — таковые всегда нужно тестировать на разных версиях Python.
Установить pyenv достаточно просто, ведь инструмент представляет собой набор shell scripts. Именно поэтому получился pyenv максимально кроссплатформенным. Но за эту кроссплатформенность приходится платить тем, что каждую версию среды исполнения нужно компилировать из исходного кода! Для компиляции того же CPython потребуется компилятор Си ( gcc на Linux и clang на MacOS), и заголовочные файлы для библиотек, которые использует интерпретатор. Полный список пререквизитов для сборки приходится гуглить.
Установка системным пакетным менеджером из сторонних источников.
Для большинства Unix-like ОС, помимо официальных репозиториев, существуют и неофициальные источники пакетов.
Для Debian-like систем, таких как Ubuntu и её производные, сторонние источники пакетов называются PPA, Personal Package Archives. Подключить любой PPA достаточно просто, но нужно понимать, что вы таким образом соглашаетесь на установку пакетов из стороннего источника, никак не подчиняющегося авторам дистрибутива ОС! Подключайте только хорошо зарекомендовавшие себя PPA, например — от самих авторов ПО, которое вы хотите установить!
Для Ubuntu-based систем существует PPA от команды “deadsnakes”. Это проверенный источник пакетов с самыми разными версиями Python как для свежих релизов ОС, так и для релизов “второй свежести”.
Главное преимущество установки пакетов из проверенных PPA состоит в том, что пакеты обычно содержат оптимизированные под конкретный дистрибутив сборки с должным количеством обновлений и исправлений. Такие сборки более безопасны и производительны, чем те, что собраны вручную из исходников.
К тому же в популярных PPA пакеты обновляются своевременно, чего нельзя сказать про пакеты для устаревших релизов ОС, для которых срок поддержки закончился. Конечно, такие релизы лучше вообще не использовать (небезопасно!), но иногда может не быть выбора, а с PPA вы хотя бы будете иметь свежие версии среды исполнения.
Псевдонимы python , python2 , python3 .
Исторически сложилось так, что интерпретатор Python запускается командой python . Но в какой-то момент случились Python3, обратная несовместимость, “разброд и шатания”. Чтобы внести некоторую определённость, был представлен PEP-394: The “python” Command on Unix-Like Systems. Однако даже этот PEP разрешает разным системам самим выбирать, использовать ли Py2 и Py3 вместе или выбрать что-то одно. Системы должны лишь обеспечить, чтобы
- команда python2 вызывала некую версию Python 2.x, если таковая вообще предоставляется;
- команда python3 вызывала некую версию Python 3.x, если таковая предоставляется;
- команда python соответствовала либо python2 , либо python3 (но не ссылалась на какую-то “третью” версию рантайма).
При этом не гарантируется, что все эти команды будут присутствовать в конкретном случае: где-то будет доступна только команда python3 , где-то — python2 . Псевдоним python вообще обязан присутствовать лишь в виртуальном окружении и всегда соответствовать той версии интерпретатора, которая была выбрана при создании окружения.
Такое “разнообразие” сильно усложняет жизнь разработчикам ПО, особенно — авторам инструментов разработки! Разработчик может написать скрипт для Py2 и указать в shebang #!/usr/bin/env python . Но на одних ОС команда python вообще не будет доступна и скрипт просто не запустится, а на других python будет означать какой-нибудь Python 3.8 и скрипт может даже запуститься, но сломается в процессе выполнения.
И даже если автор использует техники, позволяющие писать портируемый код (six, 3to2), умеющий выполняться и на Py2, и на Py3, всё равно непонятно что же указать в shebang!
Вышеупомянутый PEP советует
- либо фиксировать версию явно (только Py2 или только Py3),
- либо требовать использования виртуальных окружений (в ВО всегда будет доступна команда python )
- либо не писать shebang руками, а вместо этого использовать средства setuptools или другой системы пакетирования, создающие точки входа в зависимости при установке пакета (у точек входа shebang будет правильный).
Установка poetry на системы с разными версиями Python
На момент написания статьи poetry (это такой менеджер виртуальных окружений, сборщик пакетов и проч — “швейцарский нож” разработчика на Python) страдал от проблем с версиями рантайма: при установке рекомендованными способом скрипт-установщик завершался с ошибкой, либо установка проходила успешно, но затем не работала сама программа.
Дело (было?) в том, что и в скрипте-установщике и в точках входа в программу в shebang прописан python ! Сама программа работает и на Py2, и на Py3, но авторы исходили из предположения, что на целевой системе в любом случае будет присутствовать псевдоним python , вызывающий тот или иной интерпретатор. На некоторых системах такой команды нет…
Если использовать pyenv, оный всегда предоставляет команду python и poetry “просто работает”. Нет проблем и на старых дистрибутивах, где ещё не отказались окончательно от Py2 . И конечно всё работает в виртуальном окружении. Рассмотрим этот вариант поподробнее.
Установка в выделенное виртуальное окружение
Для начала нам понадобится само окружение. Предположим, что Python3 вы уже так или иначе поставили. Делаем раз
Источник
Установка нескольких версий 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 , даже если ОС уже содержит точно такую же версию — пусть ОС использует свою копию для служебных целей, а я для разработки буду использовать свою собственную копию, где смогу проводить любые кровавые эксперименты, не боясь поломать ОС.
Обязательно подпишитесь на уведомления о новых постах в блоге, чтобы ничего не пропустить!
Источник