Pipenv: Если возможно, используйте venv вместо virtualenv

я так не думаю, я предпочитаю использовать команду virtualenv лично

Может быть, возможно сосуществование обоих вариантов? Случайно просматривая исходный код, я не вижу ничего, связанного с Virtualenv, кроме команды, используемой для создания env. Virtualenv всегда может быть значением по умолчанию, но пользователь может (например) передать --venv для создания .venv с python3 -m venv вместо virtualenv .

Честно говоря, я полагался бы исключительно на pipenv, и мне было бы все равно, будут ли использоваться virtualenv или venv, но я решил, что мы можем использовать встроенные функции, когда они будут доступны.

Я призываю @kennethreitz пересмотреть свой комментарий здесь. Стандартная документация рекомендует использовать python3 -m venv вместо virtualenv. Лично я откладываю использование pipenv, потому что он использует virtualenv. Я использую только Python 3, а сейчас использую только venv .

@bulletmark Теперь, когда Pipenv делегирует почти все управление Virtualenv Pew, переключиться еще труднее, но есть план, что Pew будет поддерживать venv (berdario / pew # 67), так что шанс еще есть. Если бы Pew смог заставить его работать, было бы намного проще (и, по крайней мере, для меня было бы больше смысла) реализовать поддержку venv в Pipenv.

@uranusjr - это здорово!

Я лично никогда не использовал venv , отсюда и мои опасения по поводу этого. Я уверен, что это хорошо.

Сейчас дела идут хорошо. Не нужно менять то, что не сломано.

В конце концов я нашел эту тему , потому что моя система сломана.

Если вы создаете среду с virtualenv в Python 3.X, а затем обновляете до Python 3.Y, virtualenv не работает, потому что вы знаете, что у Python больше общих библиотек, которые нужны. Используя venv вы можете просто запустить python3 -m venv --upgrade .

Это было бы неплохо.

Это определенно было бы хорошо и соответствовало направлению Python.

Отказ от venv (а вместо этого с использованием virtualenv) для меня полная остановка - я не могу использовать Pipenv. Я не могу использовать virtualenv из-за его разочаровывающего поведения при копировании двоичного файла python и все же зависимости от общих библиотек - как dhouck обнаружил выше, к своему неудовольствию выше. Это постоянно нарушает virtualenvs (всякий раз, когда системный питон обновляется, оставляя двоичный файл висящим), и копирует двоичный файл python без необходимости без всякой пользы.

Если pipenv - это будущее Python, он должен по умолчанию использовать venv на Python 3 (и предупреждать, если он не используется). Он встроен в Python 3 и является рекомендуемым инструментом. Очень странно, что Pipenv теперь тоже рекомендуемый инструмент, но он не использует venv.

Venv по своей природе является частью самого Python, имеет доступ к внутренним компонентам Python, что означает, что он может делать все правильно с гораздо меньшим количеством взломов. Например, virtualenv должен скопировать двоичный файл интерпретатора Python в виртуальную среду, чтобы заставить его думать, что он изолирован, тогда как venv может просто использовать файл конфигурации, который читается двоичным файлом Python в его обычном месте, чтобы он знал, что должен действовать. как будто это в виртуальной среде. Итак, venv можно считать, что virtualenv сделан правильно, с благословения и поддержки разработчиков Python.

Источник: https://www.reddit.com/r/learnpython/comments/4hsudz/pyvenv_vs_virtualenv/

Я начал berdario / pew # 173, но у меня не было времени на успех. Как упоминалось выше, Pipenv автоматически поддержит это, как только это сделает Pew. Мне нужна помощь, если кто-то хочет принести Venv в Pipenv. Сейчас главный вопрос - пройти тесты.

Быстрое обновление поддержки venv: этого не произойдет, по крайней мере, в ближайшем будущем. venv просто недостаточно, чтобы это произошло. Если вас это действительно беспокоит, зайдите в трекер ошибок Python и протяните руку помощи. В противном случае придерживайтесь virtualenv .

Venv - рекомендуемый инструмент для Python, и он не сломан, как virtualenv (re: копирование двоичного файла python затем ломается при обновлении библиотек python). Ошибка, с которой вы связались, связана с объединением venv и virtualenv, чего мы не просим?

К сожалению, очень часто инструменты используют virtualenv. Трэвис, например, использует virtualenv для создания среды сборки для вас, как упоминал исходный репортер. Это также основа Pipsi, которая является одним из рекомендуемых способов установки Pipenv. Если Venv не может нормально работать внутри него. Он есть во многих местах без вашего ведома. Поддержка Venv будет наполовину сломана и укусит вас неожиданным образом, если она не будет хорошо работать с virtualenv.

Я понимаю это, но на данный момент рекомендуется Pipenv и venv, и они вроде как конфликтуют. Это очень странное состояние.

Я полностью согласен, что это странное состояние, поэтому я пытаюсь это исправить :) Я не говорю, что это не будет исправлено, но сначала нужно внести изменения в исходный код, и я ничего не могу сделать, пока они случаться. Я публикую ссылку не как предлог, чтобы прекратить работу над ней, а чтобы люди знали, где в первую очередь приложить усилия, чтобы помочь улучшить эту ситуацию.

Может быть, тогда было бы не слишком безумно оставить этот вопрос открытым?

Это проблема pew, а не pipenv.

Venv просто недостаточно хорош, чтобы это произошло. Если вас это действительно беспокоит, зайдите в трекер ошибок Python и протяните руку помощи.

Это проблема не venv, а virtualenv. Я опубликовал объяснение в системе отслеживания проблем.
cc @uranusjr

Есть слово вокруг ->
Сначала используйте venv, чтобы создать virtualenv, а затем запустите pipenv install . Например:

mkdir -p /tmp/try
cd /tmp/try
python3 -m venv .venv
pipenv --venv  # /tmp/try/.venv
pipenv install xxx

🙈

Просто примечание:

Приведенный выше обходной путь в основном работает, но pipenv run ... для меня не работает, потому что activate_this.py под .venv/bin . Если верить проблеме 21496 , то нет никаких планов по добавлению этого файла в venv. Так что даже если pew исправит это, проблема с pipenv, скорее всего, все равно останется.

Используя virtualenv, использование модуля system tk в macOS невозможно. Но с использованием venv это возможно.
Я очень хочу использовать venv с pipenv (может быть, по желанию).

См. Также: # 1416

Чтобы не прозвучать цинично, но я очень хочу, чтобы кто-то действительно написал код для поддержки этого, если им действительно так важно. Я встречал множество людей, которые говорили, что они «сильно» по этому поводу, но насколько я знаю, я единственный, кто действительно что-то делает. И я потерпел неудачу. Это не так просто, как вы думаете. Если вы думаете, что можете добиться большего, сделайте что-нибудь. Если не хочешь, возьми то, что можешь.

(Кеннет и я и, вероятно, Эрин и Нейт также пытались сделать это с Venv намного раньше в проекте, но также потерпели неудачу из-за соображений совместимости)

Было бы неплохо, все согласны. Мне бы хотелось, чтобы он работал на разных платформах и версиях Python.

Я хотел бы указать еще на одну причину, по которой venv, вероятно, будет лучшим выбором, чем virtualenv:

Один из самых уродливых аспектов реализации virtualenv заключается в том, что у него должна быть собственная копия модуля сайта, которая используется для всех virtualenv, независимо от того, с какой версией Python они созданы.
- с https://github.com/pypa/virtualenv/issues/228#issuecomment -4165148

Это означает, например, что rlcompleter отключен по умолчанию, и, на мой взгляд, это огромная потеря удобства использования.

Более того, поскольку это проблема, которая затрагивает нескольких ваших пользователей, я бы посоветовал оставить ее открытой до тех пор, пока проблема не будет исправлена, даже если вы ждете, когда произойдут некоторые изменения в восходящем направлении.

Снова. Мы знаем, что так будет лучше. На самом деле это невозможно. Как вы думаете, что оказывает более негативное влияние, полностью нарушая функциональность для большого сегмента пользователей или заставляя некоторых пользователей включать функции чтения строки?

Я уверен, что это неудобно, также неудобно, что есть только люди, требующие этого, но никто не предложит работающую реализацию. Мы пробовали. Пока что-то кардинально не изменится, мы не планируем поддерживать venv и, следовательно, не планируем открывать этот выпуск.

@techalchemy Если я правильно понимаю, pypa / virtualenv # 1095 - правильное место для обсуждения этого?

Кажется, правильно, я видел, что у tox есть обходной путь, так что, возможно, это сработает, если кто-то его перенесет

скамья! Какая дискуссия ... если эта pew не так важна, можно ли вообще отказаться от них вместе с virtualenv и позволить pipenv, venv и python идти рука об руку, поскольку все они рекомендуют друг друга?

Решения для управления зависимостями / виртуальной среды для python сейчас слишком дикая местность, и нужно принести некоторые жертвы, imho.

Это может напугать многих людей, которые еще не готовы отказаться от использования virtualenv, но это может быть запланировано на один из предстоящих крупных выпусков (если это технически осуществимо). Изменения неизбежны, это всего лишь вопрос времени.

@doganmeh Мы можем полностью отказаться от virtualenv,

Просто примечание:

Приведенный выше обходной путь в основном работает, но pipenv run ... для меня не работает, потому что activate_this.py под .venv/bin . Если верить проблеме 21496 , то нет никаких планов по добавлению этого файла в venv. Так что даже если pew исправит это, проблема с pipenv, скорее всего, все равно останется.

Это действительно необходимо? После того, как вы создали виртуальную среду с venv, вам не нужно активировать ее, чтобы использовать. Вы просто запускаете двоичный файл python из каталога venv / bin.

FWIW, это связано (и что привело меня сюда): http://matplotlib.org/faq/osx_framework.html

В virtualenv сборка без фреймворка используется, даже если среда создается из сборки фреймворка ( ошибка virtualenv № 54 , ошибка virtualenv № 609 ).

Решение состоит в том, чтобы не использовать virtualenv, а вместо него stdlib venv , который предоставляет аналогичные функции, но не проявляет эту проблему.

Отказ от поддержки Python 2.7 / virtualenv для меня не кажется особенно ужасной идеей, если он позволяет pipenv полагаться на stdlib версии Python, поддержка которой не скоро истечет. Если это не повредит любую другую часть цепочки инструментов pipenv которую нелегко исправить для сопровождающих. Может вообще поддержку 2.7 перенести в отдельную ветку / пакет?

Я хотел бы иметь возможность внести свой собственный код, но не думаю, что у меня есть необходимый для этого опыт или время: frown: Лучшее, что я могу сделать, это добавить к обсуждению на данный момент.

добавляю сюда свой голос; я просто ударил это из-за той же проблемы, что и @dmtucker .

В настоящее время я прибегаю к тому, чтобы полностью игнорировать pipenv для этого проекта на моем Mac, и пока создаю среду вручную с помощью venv.

+1, чтобы использовать venv.
virtualenv имеет много ошибок wontfix .
pipenv полностью полезен в Windows 10 с Python 3.7 из Магазина Windows ( ошибка virtualenv

virtualenv переходит на модель venv - см. https://github.com/pypa/virtualenv/issues/1366 , которая сгенерирует pyvenv.cfg и все полезные вещи, поэтому эту проблему следует решить с помощью этого.

---------- Пересланное сообщение ---------
От: Дэн Райан [email protected]
Дата: пн, 26 ноября 2018 г., 14:39
Тема: Re: [pypa / pipenv] Используйте venv вместо virtualenv, если это возможно (# 15)
Кому: pypa / pipenv [email protected]
Копия: с подпиской [email protected]

Кажется правильным, я видел, что у tox есть обходной путь, так что, возможно, это сработает, если
кто-то портировал это

-
Вы получаете это, потому что подписаны на эту беседу.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/pypa/pipenv/issues/15#issuecomment-441533872 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AqyQvrs-RNNTb1YhxaDCWDLpRxrZLKoxks5uy4ydgaJpZM4Lqk2f
.