Як керувати декількома версіями Python та віртуальними середовищами

Додаток у січні 2019 року: Якщо ви повертаєтесь до цього блогу після оновлення до macOS Mojave, будь ласка, ознайомтесь із цим випуском github, щоб знайти рішення загальної проблеми pyenv 'zlib not available'.

Перш ніж розпочати, коротко переглянемо терміни, використані в назві:

  • Кілька версій Python : різні інсталяції Python на одній машині, наприклад 2.7 та 3.4.
  • Віртуальне середовище : ізольоване незалежне середовище, яке може мати як певну версію Python, так і будь-які спеціальні пакети, встановлені в них, не впливаючи на будь-які інші проекти.

Тут ми розглянемо три різні інструменти для роботи з ними, і коли кожен з них може вам знадобитися. Давайте вивчимо варіанти використання для:

  • venv / pyvenv
  • pyenv
  • pyenv-virtualenv

Якщо ви використовуєте одну версію Python, скажімо, версія 3.3+ , і хочете керувати різними віртуальними середовищами, то venvце все, що вам потрібно.

Якщо ви хочете використовувати кілька версій Python на рівні 3.3+ , з віртуальними середовищами чи без них , продовжуйте читати pyenv.

Якщо ви також хочете працювати з Python 2 , pyenv-virtualenvце інструмент для розгляду.

венв

З Python 3.3+ venvпакет включений. Він ідеально підходить для створення легких віртуальних середовищ.

Аж до Python 3.6 скрипт, що називається, pyvenvтакож був включений як обгортка venv, але це було застарілим. Він буде повністю видалений в Python 3.8. Точно така ж функціональність доступна під час використання venv, і будь-яка існуюча документація повинна бути оновлена. Для всіх, хто зацікавлений, ви можете ознайомитися з причинами знецінення pyvenv.

venv використовується для створення нового середовища за допомогою команди терміналу:

$ python3 -m venv directory-name-to-create

активовано за допомогою:

$ source name-given/bin/activate

і деактивується просто:

$ deactivate

Якщо вам потрібно повністю видалити середовище після його деактивації, ви можете запустити:

$ rm -r name-given

За замовчуванням середовищем, яке воно створює, буде поточна версія Python, яку ви використовуєте. Якщо ви пишете документацію і хочете отримати додаткову безпеку від того, що читач використовує правильну версію Python, ви можете вказати в команді номер основної та другорядної версій, наприклад:

$ python3.6 -m venv example-three-six

Якщо зчитувач використовує версію, відмінну від 3.6, команда не буде успішною і вкаже в повідомленні про помилку. Однак будь-яка версія виправлення (наприклад, 3.6.4) буде працювати.

Коли середовище активне, до нього можна встановити будь-які пакунки, pipяк зазвичай. За замовчуванням новостворене середовище не включатиме вже встановлених на машині пакетів. Як pipсам він не обов'язково встановлюється на машині. Спочатку рекомендується оновити pipдо останньої версії, використовуючи pip install --upgrade pip.

У проектах зазвичай буде requirements.txtфайл із зазначенням його залежностей. Це дозволяє команді ярлика pip install -r requirements.txtшвидко встановити всі пакети у щойно створене віртуальне середовище. Вони існуватимуть лише у віртуальному середовищі. Він буде недоступний, коли його буде деактивовано, але збережеться, коли буде відновлений.

Якщо вам не потрібно використовувати додаткові версії самого Python, то це все, що вам потрібно для створення ізольованих віртуальних середовищ, специфічних для проекту.

пиєнв

Якщо ви хочете використовувати кілька версій Python на одній машині, то pyenvце часто використовуваний інструмент для встановлення та переключення між версіями. Цього не слід плутати з раніше згаданим знеціненим pyvenvсценарієм. Він не постачається в комплекті з Python і повинен бути встановлений окремо.

pyenvДокументація включає в себе велику опис того , як це працює, так що тут ми будемо просто дивитися на те, як використовувати його.

По-перше, нам потрібно буде його встановити. Якщо ви використовуєте Mac OS X, ми можемо зробити це за допомогою Homebrew, в іншому випадку розглянемо інші варіанти встановлення.

$ brew update $ brew install pyenv

Потім додайте наступне внизу скриптів оболонки, щоб дозволити pyenvвам автоматично змінювати версії:

eval "$(pyenv init -)"

Для цього відкрийте скрипт оболонки, що використовується, через $ ~/.zshrc, $ ~/.bashrcабо $ ~/.bash_profileскопіюйте та вставте наведений вище рядок.

Запуск pyenv versionsпокаже, які версії Python встановлені на даний момент, *поряд із тією, що використовується зараз. pyenv versionпоказує це безпосередньо, і python --versionможе бути використаний для перевірки цього.

Скажімо 3.4.0, щоб встановити додаткову версію , просто використовуйте pyenv install 3.4.0.

pyenv шукає в чотирьох місцях, щоб вирішити, яку версію Python використовувати, в пріоритетному порядку:

  1. PYENV_VERSIONМінлива оточення (якщо він вказаний). Ви можете використовувати pyenv shellкоманду для встановлення цієї змінної середовища у поточному сеансі оболонки.
  2. Файл, що стосується програми, .python-versionу поточному каталозі (якщо він присутній). Ви можете змінити .python-versionфайл поточного каталогу за допомогою pyenv localкоманди.
  3. Перший .python-versionзнайдений файл (якщо такий є) за допомогою пошуку у кожному батьківському каталозі, поки не з’явиться корінь вашої файлової системи.
  4. Файл глобальної версії. Ви можете змінити цей файл за допомогою pyenv globalкоманди. Якщо файлу глобальної версії немає, pyenv припускає, що ви хочете використовувати "системний" Python. (Іншими словами, будь-яка версія працювала б, якби pyenv не був у вашому PATH.)

При налаштуванні нового проекту, який повинен використовувати Python 3.6.4, він запускатиметься pyenv local 3.6.4у кореневій директорії. Це одночасно встановить версію та створить .python-versionфайл, щоб машини інших авторів могли його взяти.

Повний опис pyenvкоманд належить до закладки.

пиєнв і венв

Під час роботи з Python 3.3+ ми тепер знаємо як встановити та переключатися між різними версіями Python, так і створювати нові віртуальні середовища.

Як приклад, скажімо, ми створювали проект, який мав використовувати Python 3.4.

Спочатку ми могли встановити локальну версію за допомогою pyenv local 3.4.0.

Якби ми тоді запустили python3 -m venv example-projectнове віртуальне середовище було б створено під example-project, використовуючи наш локально ввімкнений Python 3.4.0.

Ми активуємо використання source example-project/bin/activateі можемо почати працювати.

Далі ми могли б за бажанням задокументувати, що повинен використовувати співавтор python3.4 -m venv . Це означає, що навіть якщо співавтор не використовував pyenv, python3.4команда буде помилятися, якщо їхня версія Python не буде такою самою основною та другорядною версіями (3 та 4), як ми задумали.

Крім того, ми могли б просто вказати, що потрібно використовувати 3.4.0, і проінструктувати python3 -m venv . Якщо ми вважаємо, що будь-який реактор версії g, ніж 3.4, є прийнятним, тоді ми також можемо вибрати використання python3over python3.4, як якщо б співавтор використовував 3.6, тоді в іншому випадку вони також отримають помилку. Це рішення, яке стосується конкретного проекту.

pyenv-virtualenv

pyenvможе використовуватися для встановлення версій Python 2 і 3. Однак, як ми вже бачили, venvобмежується версіями Python більше 3.3.

pyenv-virtualenv- це інструмент для створення віртуальних середовищ, інтегрованих з pyenv, і працює для всіх версій Python. Як і раніше рекомендується використовувати офіційний Python, venvде це можливо. Але якщо, наприклад, ви створюєте віртуальне середовище на основі 2.7.13, то це компліменти pyenv.

Він також добре працює з condaсередовищами Anaconda та Miniconda, якщо ви вже використовуєте їх. Інструмент під назвою virtualenvтакож існує. Тут це не висвітлено, але пов’язано в кінці.

Після встановлення pyenvйого можна наступним чином встановити за допомогою Homebrew (або альтернативних варіантів) так:

$ brew install pyenv-virtualenv

Далі у вашому .zshrc,, .bashrcабо .bash_profile(залежно від того, яку оболонку ви використовуєте) додайте внизу наступне:

eval "$(pyenv init -)" eval "$(pyenv virtualenv-init -)"

Це дозволяє pyenvавтоматично активувати та деактивувати середовища під час переміщення каталогів.

Щоб створити нове віртуальне середовище, використовуйте:

$ pyenv virtualenv   // for example $ pyenv virtualenv 2.7.10 my-virtual-env-2.7.10

Існуючі середовища можна перерахувати за допомогою:

$ pyenv virtualenvs

Активується / деактивується за допомогою:

$ pyenv activate  $ pyenv deactivate

На момент написання статті, під час використання буде відображено activateпопередження prompt changing will be removed from future release. Це очікувано і стосується лише того, (env-name)що відображається у вашій оболонці, а не використання самої activateкоманди.

Встановлення вимог працює, як описано в venv. В відміну venvв rm -rкоманді не потрібно , щоб видалити середу, uninstallкоманда існує.

Заключні думки

Між цими трьома інструментами ми маємо можливість співпрацювати над будь-яким проектом, незалежно від версії Python або необхідних залежностей. Ми також знаємо, як задокументувати інструкції, якими інші користуються для будь-якого проекту, над яким ми працюємо.

Ми також можемо бачити міркування, за якими наборами використовувати, оскільки не всі розробники потребуватимуть усіх трьох.

Сподіваємось, це було корисним і є корисним посиланням у поєднанні з документацією, наведеною нижче.

Дякуємо за читання! ?

Інші речі, які я досліджував:

  • Знущання над модулями ES та CommonJS за допомогою jest.mock ()
  • Посібник для початківців щодо служби еластичних контейнерів Amazon

Ресурси

  • Віртуальне середовище Python: Посібник
  • Знецінюється pyvenv
  • venvДокументація на Python
  • venv проти virtualenv
  • У чому різниця між venv, pyvenv, pyenv, virtualenv, virtualenvwrapper, pipenv тощо?
  • Чи потрібно встановлювати pip?