Pipenv: Как pipenv узнает виртуальную среду для текущего проекта?

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

Чтобы установить определенную версию пакета, используйте тот же синтаксис, что и для pip и requirements.txt, например, pipenv install django==1.11.0 .

@uranusjr Это означает, что если я переименую каталог, virtualenv моего проекта будет утерян. Плохо. Обычным вариантом использования может быть переименование каталога, и пользователи могут попасть в это и задаться вопросом, как перестала работать их среда.

Я бы посоветовал исправить это и сделать запись в Pipfile, если это возможно. Или создайте другой файл .pipenv для хранения таких метаданных в каждом каталоге проекта.

Что ты посоветуешь ?

Спасибо, что ответили на оба вопроса!

Привет, @ sachinjain024 , у нас было несколько дискуссий по поводу локального файла метаданных, но сопровождающие пришли к единому мнению, что pipenv не будет поддерживать это в настоящее время.

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

На практике мы обнаружили, что гораздо меньше людей сталкивались с проблемами, связанными с тем, что местоположение является частью среды, чем с тихой перезаписью их работы. В конце концов, Pipenv - это инструмент управления развертыванием, поэтому перемещение каталога должно быть исправлением одной команды.

Спасибо @nateprewitt. Имеет смысл сразу перейти к простой реализации. Предположим, я переименовал проект на более позднем этапе, тогда это означает, что моей среды не существует.

Итак, что мне делать в этой ситуации?

1. Перезагрузите среду, потому что у меня уже есть Pipfile, в котором есть информация о пакетах, поэтому будет легко сбросить env.
2. Как-нибудь тоже переименуйте каталог virtualenv
3. ???

Что вы предлагаете в этом случае? Просто любопытно, не попаду ли я в такую ​​ситуацию в будущем.

Вы можете использовать pew cp чтобы легко скопировать существующий virtualenv, но я думаю, что 1. будет более «каноническим» способом сделать это.

@ sachinjain024 , всякий раз, когда вам нужно переместить каталог проекта, вам нужно всего лишь запустить pipenv install чтобы вернуться в рабочее состояние. Это создаст для вас среду с новым хешем и переустановит все из файла блокировки точно так же, как и при предыдущей установке, с которой оно было создано.

Если вы обнаружите, что делаете это часто, вы можете использовать pew rm old_project-a3de90 для очистки.

Я бы не рекомендовал использовать pew cp если вы не изменяете виртуальную среду вне pipenv. В этом случае, я думаю, нам следует рассмотреть сценарий «аннулирования гарантии», потому что есть всевозможные изменения, которые мы не можем надежно учесть.

Спасибо @nateprewitt @uranusjr. Закрытие этой заявки.

Это одна из худших идей, которые пока что вышли из pipenv . Вот почему:

Я работаю в компании, где Python используется для автоматизации тестирования множества внутренних проектов. Один тестер обычно работает с десятком таких. По соглашению весь тестовый код для проекта находится в каталоге с именем tests . Это означает, что у каждого тестировщика теперь есть набор виртуальных сред, которые называются примерно так: ~/.local/share/virtualenvs/tests-hKjFddnZ - круто! Человеку свойственно забывать переключать виртуальную среду, поэтому каждые несколько дней меня вызывают на другую рабочую станцию, потому что человек на этой рабочей станции думает, что он установил нужный пакет, он запустил pipenv install , но импорт в коде не работает. Кроме того, со временем бесхозные виртуальные среды накапливаются, но поскольку все они имеют невнятные имена, невозможно определить, удаляю ли я среду, которая не используется, или ту, которая действительно использовалась. Это означает, что в CI мы ежедневно создаем десятки, если не сотни виртуальных сред. Никто не может отслеживать среды, которые имеют по существу случайные имена, а их слишком много, поэтому мы должны удалять их все, по крайней мере, один раз в день. Мы платим огромные деньги за время ожидания только из-за этого супер-умного решения, принятого pipenv и кем-то в нашей компании, который решил его использовать ...

Установите export PIPENV_VENV_IN_PROJECT=1 в конфигурации bashrc / shell.
(Или измените сценарии оболочки, чтобы создать venv в $ PROJECT / .venv, а затем
pipenv будет иметь это)
В понедельник, 19 марта 2018 г., в 6:28, wvxvw [email protected] написал:

Это одна из худших идей, которые до сих пор исходили от pipenv. Вот почему:

Я работаю в компании, где Python используется для автоматизации тестирования многих
внутренние проекты. Один тестер обычно работает с десятком таких. От
По соглашению, весь тестовый код для проекта находится в каталоге, называемом tests.
Это означает, что у каждого тестировщика теперь есть несколько виртуальных сред, все
называется что-то вроде ~ / .local / share / virtualenvs / tests-hKjFddnZ -
классно! Человеку свойственно забывать переключать виртуальную среду, поэтому
каждые несколько дней меня вызывают на другую рабочую станцию, потому что человек
на этой рабочей станции думают, что установили нужный им пакет, они
запустил pipenv install, но импорт в коде не работает. Не только
что бесхозные виртуальные среды накапливаются со временем, но поскольку все
из них с невзрачными именами, нет никакого способа узнать, удаляю ли я
среда, которая не используется, или та, которая действительно использовалась. Этот
означает, что в CI мы создаем десятки, если не сотни виртуальных сред
ежедневно. Никто не может отслеживать среды, в которых
по сути случайные имена, а их слишком много, поэтому мы должны
удаляйте их все не реже одного раза в день. Мы платим огромные деньги за время ожидания
только из-за этого супер-умного решения, принятого pipenv и кем-то в
наша компания, решившая его использовать ...

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

@jtratner Тогда зачем мне pipenv если я собираюсь создать виртуальную среду вручную?

Виртуальная среда - это самостоятельная работа. Он везде хромает и не работает в Windows (предполагается, что в MS Windows домашний каталог по умолчанию называется "~"). Я надеялся, что если кто-то переделает PIP и виртуальную среду, они, как вы понимаете, исправят очевидные ошибки своих предшественников ... вместо этого есть этот беспорядок, помноженный на слой несовместимости.

Вы делаете неправильные предположения. Pipenv не переделывает ни virtualenv, ни pip. Он строится на них.

@uranusjr это проблема понимания прочитанного. Я очень хорошо знаю, что делает pipenv , так как трачу на отладку его кода гораздо больше времени, чем хотелось бы. Переделать виртуальную среду и PIP - заявленная цель проекта. То, что вместо того, чтобы исправлять их, было решено использовать их «как есть» - это еще одна огромная ошибка со стороны pipenv , за которой следует использование библиотеки click , и этот список можно продолжить.

Переделать виртуальную среду и PIP - заявленная цель проекта.

Где это было сказано?

Я также нашел это поведение странным, я ожидал, что pipenv выберет стандартное имя для каталога virtualenv и поместит каталог в текущий каталог, аналогично тому, как npm использует node_modules .

@Flimm export PIPENV_VENV_IN_PROJECT=1 . Прочтите документацию.

@uranusjr Я прочитал все https://docs.pipenv.org и https://docs.pipenv.org/basics/ , и, если я не пропустил его, никогда не упоминается, где установлены каталоги virtualenv , и не предупреждает никого о том, что переименование или перемещение каталога проекта приведет к воссозданию каталога virtualenv .

PIPENV_VENV_IN_PROJECT сбивает с толку, поскольку pipenv не использует venv из стандартной библиотеки, он использует virtualenv , который является другим проектом.

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

@Flimm суть в том, чтобы абстрагироваться от этой информации. Если вы знаете, как работают другие инструменты, которые управляют virtualenvs, вы уже должны знать, что перемещение папки virtualenvs делает их недоступными для поиска. Если вы не знакомы, вы, вероятно, не будете копать это в первую очередь.

Что касается того, какую серверную библиотеку мы используем для генерации виртуальных переменных и именования переменных среды, первое не так важно, а второе является широко распространенным сокращением. Хотя детали важны, это не похоже на то, что оно вызывает у кого-либо какие-либо проблемы, и ваше основное возражение, похоже, основано на том, что вы не уверены, какой бэкэнд мы используем для помещения исполняемого файла python в папку. Если вы столкнетесь с ошибками, сообщите о них. Мы действительно не собираемся менять переменные окружения _ просто потому_.

Переменная среды легко доступна в документации: http://pipenv.readthedocs.io/en/latest/advanced/#configuration -with-environment-variables, поэтому вы, вероятно, не читали их все, если не видели Это

@techalchemy Под другими инструментами, я полагаю, вы имеете в виду что-то вроде virtualenvwrapper . Я годами не использовал virtualenvwrapper . Я предполагаю, что количество разработчиков Python, знакомых с шаблоном node_modules для Node / NPM, больше, чем количество разработчиков Python, знакомых с virtualenvwrapper или pipenv шаблон скрытия каталога окружения. Но это предположение. Для тех, кто не знаком ни с одним из этих инструментов, я думаю, было бы странно не знать, где в конечном итоге находятся установленные файлы. Вы указываете, что это объясняется только в расширенном разделе документации в подразделе переменных среды, я думаю, что это следует объяснить в документации намного раньше. Может, я отправлю пул-реквест.

Я прокомментировал сбивающую с толку ссылку на venv вместо virtualenv в названии PIPENV_VENV_IN_PROJECT в другом выпуске №1919. Достаточно сказать, что я не совсем придерживаюсь той позиции, которую, как вы думаете, придерживаюсь.

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

Я понимаю, что это неправильная аудитория, но поскольку это обсуждение продолжается ... ну, я не думаю, что node_modules были источником вдохновения для pipenv , а не для virtualenv тоже. Мое предположение может быть исторически неверным, но, работая с rbenv и virtualenv , я могу сказать вам, что virtualenv выглядит либо как плохая копия без понимания, либо возможно, ранний прототип, который был улучшен на rbenv . В любом случае virtualenv - посмешище по сравнению с rbenv , и вот почему:

Он копирует пакеты для каждой среды. Это глупо, медленно и сбивает с толку. Это просто плохое дизайнерское решение, но, скорее всего, просто отсутствие решения: это просто произошло так, потому что кто-то написал код для помещения этих пакетов в произвольный каталог. Кроме того, это действительно не работает в Windows. До такой степени, что он никогда не тестировался на Windows ... Одна смешная вещь в том, что он тестирует для ОС, и как только он обнаруживает, что он работает в Windows, он устанавливает домашний каталог в ~ , это значение по умолчанию может быть позже переопределен некоторыми переменными среды, но если вы на самом деле пытаетесь запустить автоматизацию в контролируемой и чистой среде ... virtualenv просто никогда не установит пакеты в тот же каталог.

Итак ... pipenv утверждает, что это инструмент для людей, что-то вроде requests ... Полагаю? Таким образом, он должен улучшить незрелые усилия, предпринятые его предшественниками ... ну, похоже, это был бы путь, если вы хотите создать программу, которая делает то же самое, что и предыдущие, но лучше, верно ? И все же вместо того, чтобы выбросить мусор virtualenv , он использует его как есть. Оболочка отличается от обернутой программы только тем, что не позволяет / затрудняет использование некоторых функций из обернутой программы ...

В своей жизни я видел много попыток сделать автоматизацию, и это отстой, но вы, ребята, стремитесь к звездам, вы размещаете все эти незаслуженные оценки на своем сайте, даже до того, как разместите какую-либо полезную информацию. Но вы не выполняете обещание. На самом деле вы просто манипулируете общественным мнением, не выполняя никакой реальной работы. И теперь программисты, которым приходится заниматься автоматизацией, должны столкнуться с еще одним злом только потому, что кто-то хотел получить больше лайков на GitHub ...

@wvxvw Действительно, вы не пять (четыре, см. ниже) лет, и поэтому никогда не может быть вдохновлен им. К тому же это принципиально разные вещи, только достигающие в итоге схожей цели. То, что вы ищете (инструмент управления средой выполнения, вдохновленный rbenv), - это pyenv.

Также относительно того, что virtualenv не находится на одном уровне с другими инструментами - знаете ли вы, что он существует уже десять (10) лет? Требования к разработке программного обеспечения сильно меняются, и сделанные в нем предположения постепенно устаревают, и никто не позаботился о том, чтобы его заменить. Достаточно ли вы заботитесь, чтобы подойти?

Я понимаю, что каждый заслуживает возможности выступить, но присоединиться к обсуждению без минимального понимания темы и сразу начать указывать пальцем - это довольно грубо по отношению к разработчикам систем упаковки Pipenv, virtualenv и Python в целом. Пожалуйста, не делайте этого.

Изменить: я немного покопался. Первоначальный выпуск virtualenv, 0.8, был выпущен в 2007 году, а rbenv (0.1) был в 2011 году, так что разница между ними составляет четыре года, а не пять.

@wvxvw Я только видел, как ты оскорбляешь. Такое отношение здесь не приветствуется. Пожалуйста, ознакомьтесь с нашим кодексом поведения, прежде чем продолжить публикацию.

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

1. Документ действительно должен указывать на механизм сопоставления между путем проекта и env, по крайней мере, предупреждать пользователей, что changing project path would cause unmapping the original env .

2. Будет ли лучше, если можно будет вручную указать путь к env в Pipfile? Я имею в виду, что у людей могут быть особые требования к использованию одного и того же env вручную.

Просто хочу поделиться с вами своим мнением, ребята.

Совершенно непонятно, как пользоваться pipenv. Должен ли я иметь много виртуальных сред для одного проекта? Должен ли я разделять виртуальные среды между проектами? Как установить другую версию Python для конкретного проекта с помощью pipenv, если версия Python требуется только для этого проекта? В этой беседе все настолько заняты собой, предполагают много разных вещей о других людях, никогда не пытаются понять, откуда они взялись. Когда я читал похвалы pipenv на домашней странице, я верил, что это мне поможет. Вместо этого я потратил 5 дней на борьбу с этим, и теперь я думаю, что возвращаюсь к pyenv, потому что это было, по крайней мере, в некоторой степени детерминированным.

если вы хотите использовать несколько сред для одного проекта, используйте tox. Используйте pipenv для своей основной среды разработки и tox для тестирования на нескольких версиях Python.

@ashnur, тебе явно нужно чем-то заняться. Вместо того, чтобы распространять негатив среди проектов с открытым исходным кодом, которыми руководят волонтеры, почему бы вам не попробовать внести что-нибудь полезное?

@uranusjr
это где происходит хеширование?

Я работаю над проектом, и мне нужно вычислить хэш пути.

@devxpy Ага , именно так.

Я думаю, вы, ребята, должны поместить базовый учебник о том, как настроить virtualenv с помощью pipenv, что-то очень простое, потому что чем проще это для людей, тем больше людей будут его использовать, но если это вызовет путаницу, тогда больше людей могут не использовать его и могут искать другие языки или методы для создания там проектов

@uranusjr по какой причине Pipenv не создает virtualenv по умолчанию в каталоге проекта? На мой взгляд, это решит проблему с потерянными средами, когда проект будет переименован / перемещен / удален. Кроме того, это будет меньше сбивать с толку людей, которые (в некоторой степени справедливо) ожидают, что он будет работать как npm.

Есть ли какая-то польза от такого подхода, помимо, может быть, традиций?

Просто создайте каталог .venv перед командой установки pipenv. На самом деле, вариант -venv или -dot-venv для установки pipenv будет приветствоваться :)

Начиная с версии 2018.10.9, это можно сделать по-другому. Вы можете добавить файл .venv содержащий путь к вашей виртуальной среде. (Подлая новая функция!)

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

ps Хотели бы вы (или кто-то еще) написать об этом в часто задаваемых вопросах? Скорее всего, это займет несколько абзацев, но я был бы более чем счастлив объяснить, если кто-то пообещает уделить время доработке текста и представить PR.

@uranusjr Мне очень любопытно, почему это лучший

PS: Я мог бы написать запись в FAQ, если вы объясните, почему все так, как есть. ;)

Начиная с версии 2018.10.9, это можно сделать по-другому. Вы можете добавить .venv _file_, содержащий путь к вашей виртуальной среде. (Подлая новая функция!)

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

ps Хотели бы вы (или кто-то еще) написать об этом в часто задаваемых вопросах? Скорее всего, это займет несколько абзацев, но я был бы более чем счастлив объяснить, если кто-то пообещает уделить время доработке текста и представить PR.

Извините, что наткнулся на ... У меня такая же потребность переместить папки проектов, в которых есть виртуальная среда, созданная с помощью pipenv.

В настоящее время я делаю следующее, и у меня нет никаких проблем:

• Перемещаю папку проекта куда хочу
• в C: \ Users \ user \ .virtualenvs я удаляю папку venv, связанную с проектом, который я только что переместил
• Я перехожу к новому местоположению папки проекта через cmd и запускаю pipenv install (или оболочку pipenv, а затем синхронизацию pipenv)

Все работает нормально. Это плохая практика?

Что касается комментария
Если это так, то не было бы лучше, если бы такой файл автоматически создавался в папке проекта при первоначальном создании виртуальной среды?

PS: Я тоже готов написать FAQ

На самом деле, я думаю, что идея @ gioxc88 хороша, недавно созданный virtualenv может автоматически генерировать файл .env в корне проекта и содержит конфигурации env, такие как PATH . Это сделает среду более прозрачной для разработчиков и более удобным способом перенастройки.

Постараюсь вместе ответить на ваши вопросы. Подход неплох (IMO; я сам тоже использую ту же настройку). Однако неосведомленному пользователю проще споткнуться.

Один из способов подумать об этом - рассмотреть возможность помещения проекта в систему контроля версий (скажем, Git). Если среда создается в корне проекта, она, естественно, находится в корне репозитория. Такие люди, как вы и я, которые привыкли к этой настройке, очевидно, знают, что мы должны добавить правило в .gitignore (или глобальную конфигурацию игнорирования), чтобы предотвратить регистрацию каталога .venv , но ничего не подозревающий пользователь этого не сделает, и может очень легко случайно проверить окружающую среду. Это не только плохо для управления проектами, но (что более важно) обеспечивает вектор потенциальных атак, раскрывая локальную информацию. Поэтому для инструментов управления проектами является общим правилом избегать помещения сгенерированных файлов в каталог проекта . Это могло бы быть нормально (все еще не оптимально ИМО), если вы проектируете экосистему с нуля (например, node_modules NPM), но определенно не лучшая идея для инструментов, созданных для экосистемы с установленными общими практиками, как в случае с Pipenv.

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

Функция .venv file все еще довольно нова (выпущена всего несколько дней назад), и мы все еще изучаем способы ее наилучшего использования. У него по-прежнему та же проблема с каталогом .venv , но, надеюсь, не так остро. Мне лично очень нравится эта функция, и я определенно надеюсь, что мы сможем использовать ее для улучшения пользовательского опыта, но здесь еще есть что учесть.

Привет. Для меня каталог .venv (старая функция) и файл .venv (новая функция) подойдут, но я был бы очень благодарен за наличие опции в команде установки pipenv.

Что-то типа:

pipenv install

Будет установлен в ~/.local/

pipenv install --venv

Будет установлен в каталоге $PWD/.venv

pipenv install --venv-dir /my/custom-path

Установил бы в /my/custom-path .

Если вам нужна новая функция, предложите ее правильно, сделав предложение по улучшению в ~/.peeps . Пожалуйста, не делайте предложения по улучшению, разбросанные случайным образом по различным вопросам, это не отслеживается.

@uranusjr спасибо за развернутый ответ! Просто чтобы удовлетворить мое любопытство, какая локальная (потенциально конфиденциальная) информация может быть раскрыта проверенным в python venv? Я согласен, что это раздражает, если node_modules регистрируется, но обычно это не содержит никакой локальной информации.

Виртуальные среды Python содержат несколько сценариев оболочки (например, activate ). Многие люди изменяют их, добавляя переменные среды, чтобы указать пароли базы данных, путь к другому файлу конфигурации и т.д. -личный опыт).

Кроме того, вы правы, вероятно, node_modules не содержит конфиденциальной информации. Это еще одно преимущество, когда вы строите экосистему с нуля. К сожалению, виртуальные среды Python были изобретены задолго до того, как это стало распространенной проблемой (в то время вы уже были гуру, если вообще используете VCS).

Я прибыл сюда, когда пытался понять, откуда pipenv знает правильный virtualenv :)

Спасибо, ребята, за обсуждение. Вероятно, было бы неплохо указать на главной странице (например, здесь ), что переименование пути к проекту нарушает стандартный механизм привязки virtualenv.

Все страницы документации открыты для участия. Ничего не проси, делай :)

Я буду!

@uranusjr Это означает, что если я переименую каталог, virtualenv моего проекта будет утерян. Плохо. Обычным вариантом использования может быть переименование каталога, и пользователи могут попасть в это и задаться вопросом, как перестала работать их среда.

Я бы посоветовал исправить это и сделать запись в Pipfile, если это возможно. Или создайте другой файл .pipenv для хранения таких метаданных в каждом каталоге проекта.

Что ты посоветуешь ?

Спасибо, что ответили на оба вопроса!

спасибо, что задали оба вопроса. я тоже сталкиваюсь с той же проблемой,

Если вы инициализировали pipenv в неправильном каталоге и вам нужно использовать каталог virtualenv из правильного каталога, вы можете получить путь virtualenv, выполнив pipenv --venv и переместив PIpfile и Pipfile.lock в правильный каталог.

echo ${PATH_OBTAINED_FROM_PREVIOUS_COMMAND} > .venv в правильном каталоге, и он должен работать правильно.

Сегодня я заметил, что если в родительском каталоге есть pipfile, pipenv игнорирует переменную окружения export PIPENV_VENV_IN_PROJECT=1 и вместо этого устанавливает venv в родительский каталог. Это в выпуске 2018.11.26 . Если вы удалите pipfile из родительского каталога, pipenv будет работать, как описано в документации.