Python 3.3 включає в свою стандартну бібліотеку новий пакет venv. Що це робить, і чим він відрізняється від усіх інших пакетів, які, схоже, відповідають регексу (py)?(v|virtual|pip)?env?

Пакети PyPI не в стандартній бібліотеці:

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

  Він працює, встановивши купу файлів у каталозі (наприклад:) env/, а потім змінивши PATHзмінну середовища для префіксації її у користувацькому binкаталозі (наприклад:) env/bin/. Точна копія бінарної pythonабо python3бінарної файлів розміщується в цьому каталозі, але Python запрограмований спочатку шукати бібліотеки щодо його шляху в каталозі оточення. Він не є частиною стандартної бібліотеки Python, але офіційно благословенний PyPA (Python Packaging Authority). Після активації ви можете встановити пакунки у віртуальному середовищі за допомогою pip.

• pyenvвикористовується для ізоляції версій Python. Наприклад, ви можете перевірити свій код на Python 2.7, 3.6, 3.7 та 3.8, тому вам знадобиться спосіб перемикання між ними. Після активації він префіксує PATHзмінну середовища ~/.pyenv/shims, де є спеціальні файли, що відповідають командам Python ( python, pip). Це не копії команди, що постачаються Python; це спеціальні сценарії, які вирішують на льоту, яку версію Python запускати на основі PYENV_VERSIONзмінної середовища, або .python-versionфайлу, або ~/.pyenv/versionфайлу. pyenvтакож полегшує процес завантаження та встановлення декількох версій Python, використовуючи команду pyenv install.

• pyenv-virtualenvє плагіном pyenvтого самого автора pyenv, що дозволяє вам зручно користуватися pyenvі virtualenvв той же час. Однак якщо ви використовуєте Python 3.3 або пізнішої версії, pyenv-virtualenvви намагатиметеся запустити, python -m venvякщо він доступний, а не virtualenv. Ви можете користуватися virtualenvі pyenvразом без них pyenv-virtualenv, якщо не хочете зручності.

• virtualenvwrapper- це набір розширень до virtualenv(див. документи ). Він дає вам команди, як mkvirtualenv, lssitepackagesі особливо workonдля перемикання між різними virtualenvкаталогами. Цей інструмент особливо корисний, якщо потрібно кілька virtualenvкаталогів.

• pyenv-virtualenvwrapperце плагін для pyenvтого ж автора , як pyenv, зручно інтегрувати virtualenvwrapperв pyenv.

• pipenvЦілі об'єднати Pipfile, pipі virtualenvв одну команду в командному рядку. virtualenvКаталог , як правило , отримує поміщається в ~/.local/share/virtualenvs/XXXс XXXбудучи хеш шлях директорії проекту. Це відрізняється від того virtualenv, де каталог зазвичай знаходиться в поточному робочому каталозі. pipenvпризначений для використання при розробці програм Python (на відміну від бібліотек). Є альтернативи pipenv, такі як poetry, які я тут не перелічу, оскільки це питання стосується лише пакетів, названих аналогічно.

Стандартна бібліотека:

• pyvenvце сценарій, що постачається з Python 3, але застарілий у Python 3.6, оскільки у нього виникли проблеми (не кажучи вже про заплутане ім'я). У Python 3.6+ точніший еквівалент python3 -m venv.

• venvце пакет, що постачається з Python 3, який ви можете запустити, використовуючи python3 -m venv(хоча чомусь деякі дистрибутиви відокремлюють його в окремий пакет дистрибутивів, наприклад, python3-venvна Ubuntu / Debian). Він служить тій самій цілі, що і virtualenv, але має лише підмножину своїх особливостей ( див. Порівняння тут ). virtualenvпродовжує користуватися популярністю venv, тим більше, що колишній підтримує і Python 2, і 3.

Рекомендація для початківців:

Це моя особиста рекомендація для початківців: почніть з навчання virtualenvта pip, інструментів, які працюють як з Python 2, так і з 3 та в різних ситуаціях, і підберіть інші інструменти, як тільки ви почнете потребувати в них.

Я б просто уникав використання virtualenvпісля Python3.3 + і замість цього використовував стандартну бібліотеку, що постачається venv. Щоб створити нове віртуальне середовище, ви введете:

$ python3 -m venv <MYVENV>  

virtualenvнамагається скопіювати бінарний файл Python у каталог бін віртуального середовища. Однак він не оновлює посилання на файли бібліотеки, вбудовані в цей двійковий файл, тому якщо ви будуєте Python з джерела в несистемний каталог з відносними іменами шляху, бінарний Python розривається. Оскільки саме так ви робите копіювальний Python, який роздається, це великий недолік. BTW для перевірки вбудованих посилань на файли бібліотеки на OS X, використовуйте otool. Наприклад, з вашого віртуального середовища введіть:

$ otool -L bin/python
python:
    @executable_path/../Python (compatibility version 3.4.0, current version 3.4.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0)

Отже, я б уникнув virtualenvwrapperі pipenv. pyvenvзастаріло. pyenvЗдається, він часто використовується там, де virtualenvйого використовують, але я б утримався від нього також, оскільки, думаю, venvтакож робить те pyenv, для чого створений.

venvстворює віртуальне середовище в оболонці, яке є свіжим та пісочним , із встановленими користувачем бібліотеками , і це багатопітонна безпека . Свіже, оскільки віртуальне середовище починається лише зі стандартних бібліотек, які постачаються з python, вам доведеться знову встановлювати будь-які інші бібліотеки, pip installпоки віртуальне середовище активне. Пісочниця, оскільки жодна з цих нових установок бібліотеки не видно за межами віртуального середовища, тому ви можете видалити все середовище та почати заново, не переживаючи про вплив на встановлення базового пітона. Бібліотеки, які встановлюються користувачем, оскільки цільова папка віртуальної середовища створена безsudoв деякому каталозі, який ви вже маєте, тому вам не знадобляться sudoдозволи на встановлення в нього бібліотек. Нарешті, це багатопітонна безпека , оскільки при активації віртуальних середовищ оболонка бачить лише версію python (3.4, 3.5 тощо), яка була використана для створення цього віртуального середовища.

pyenvподібний тим, venvщо дозволяє керувати кількома середовищами python. Однак, якщо pyenvви не можете зручно встановити бібліотеку відката до певного стартового стану, і вам, швидше за все, потрібні adminпривілеї в якийсь момент для оновлення бібліотек. Тому я думаю, що це також найкраще використовувати venv.

За останні кілька років я виявив багато проблем у системах збирання (пакети emacs, окремі розробники додатків python, інсталятори ...), які врешті-решт стикаються з проблемами virtualenv. Я думаю, що python стане кращою платформою, коли ми усунемо цю додаткову опцію та використовуватимемо лише venv.

Я спустився в pipenvкролячу нору ( це справді глибока і темна діра ... ), і оскільки остання відповідь минула 2 роки тому , вважаю, що корисно оновити дискусію останніми розробками на тему віртуальних конвертів Python I знайшли.

ВІДМОВА:

Ця відповідь НЕ про продовження бурхливої ​​дискусії щодо достоїнств pipenv проти venv як конвертних рішень - я не схвалюю жодного . Йдеться про те, що PyPA підтримує суперечливі стандарти та те, як майбутня розробка virtualenv обіцяє відмовитись взагалі зробити / або вибір між ними. Я зосередився на цих двох інструментах саме тому, що вони є помазаними PyPA .

Венв

Як зазначає ОП, venv - це інструмент для віртуалізації середовищ. НЕ стороннє рішення, а рідний інструмент. PyPA схвалює venv для створення ВІРТУАЛЬНОГО РОЗВИТКУ : " Змінено у версії 3.5: Використання venv тепер рекомендується для створення віртуальних середовищ ".

пипенв

pipenv - як venv - може використовуватися для створення віртуальних конвертів, але додатково керованим пакетом управління тафункцією перевірки вразливості . Замість використанняrequirements.txt,pipenvзабезпечує управління пакетамидопомогою Pipfile . Оскільки PyPA схвалює pipenv для УПРАВЛІННЯ ПАКЕТИМИ , це, мабуть, означає,pipfileце замінитиrequirements.txt.

ОДНАК : pipenv використовує virtualenv в якості інструменту для створення віртуальних конвертів, НЕ venv , який схвалений PyPA як йти до інструменту для створення віртуальних конвертів.

Конфліктні стандарти:

Тож якщо рішення про віртуальну конверт не було достатньо складним, тепер у нас є PyPA, який підтримує два різних інструменти, які використовують різні рішення віртуальних конвертів. Бурхливі дебати Гітуба про венв проти віртуален, які висвітлюють цей конфлікт, можна знайти тут .

Вирішення конфліктів:

Дискусія про Github, на яку посилається вище посилання, спрямовувала розвиток virtualenv у напрямку розміщення venv у майбутніх випусках :

віддайте перевагу вбудованому venv: якщо цільовий пітон має venv, ми створимо середовище за допомогою цього (а потім виконаємо наступні операції над цим, щоб полегшити інші гарантії, які ми пропонуємо)

Висновок:

Таким чином, схоже, відбудеться деяке майбутнє зближення двох конкуруючих рішень для віртуальних конвертів, але на сьогоднішній день pipenv - який використовується virtualenv- істотно відрізняється від venv.

Зважаючи на проблеми, які вирішує pipenv, і той факт, що PyPA дав своє благословення, схоже , це світле майбутнє. І якщо virtualenv поставляє на запропонованих цілях в області розвитку, вибір віртуального рішення конверта більше не повинно бути випадково або pipenv АБО venv .

Оновлення квітня 2020 року

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

Хоча цей підручник охоплює проект pipenv як інструмент, який зосереджується в першу чергу на потребах розробки додатків Python, а не на розробці бібліотеки Python, сам проект наразі працює над декількома проблемами процесу та технічного обслуговування, які запобігають опублікуванню виправлень помилок та нових функцій ( з усього 2019 року проходить без нового випуску). Це означає, що в найближчій перспективі піпенв все ще страждає від декількох химерностей та проблем із виконанням роботи, не маючи чітких термінів вирішення цих питань.

Хоча так і залишається, керівники проектів, ймовірно, захочуть дослідити Інші інструменти управління залежностями додатків для використання замість pipenv або разом з ним.

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