Как да управлявате множество версии на 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е инструмент за разглеждане.

venv

От 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, тогава това е всичко, което трябва да създадете изолирана, специфична за проекти, виртуална среда.

pyenv

Ако искате да използвате множество версии на 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командите е едно за маркиране.

pyenv и venv

Когато работим с 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 . Ако ние вярваме, че всеки съм rsion гр reater от 3.4 е приемливо, тогава ние също да изберете да използвате python3над 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?