Амбициозное предложение!

поддержка конфигурации ini (глобальная конфигурация ini присутствует в доме пользователя)

Рассмотрите возможность использования appdirs (или аналогичных) для обнаружения конфигурации в предпочтительных для платформы местах.

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

Почему поставщик, а не просто зависит от него? (Не то чтобы продавать это сложно, это всего лишь один файл). ИМО, нам действительно нужно признать, что (за заметным исключением pip) инструменты упаковки действительно должны быть созданы так же, как и любое другое приложение. Если наличие зависимостей настолько сложно, что приложения PyPA их избегают, что это говорит о том, насколько хорошо мы делаем, чтобы нашим пользователям было легко разрабатывать приложения?

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

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

PYTHONPATH = / t / путь / к / virtualenv.whl python -m virtualenv

Это означало бы, что мы не можем зависеть от каких-либо дополнительных пакетов от virtualenv. Поскольку мы будем предоставлять zipapp, какие варианты использования это позволяет?

@gaborbernat Вы имеете в виду вариант -p ? Полагаю, что так. Кажется, это именно та ситуация, в которой zipapps должны были помочь, но никто никогда особо не делал ничего, чтобы продумать детали, чтобы заставить их работать хорошо.

Из @pradyunsg :

Ух, это будет означать, что мы не можем зависеть от каких-либо дополнительных пакетов от virtualenv

На самом деле, как сказал @gaborbernat , вариант -p вероятно, подразумевает, что :-( Но мне интересно, зачем нам нужен параметр «колесо на PYTHONPATH », а также zipapp - особенно с учетом этого колеса на PYTHONPATH в целом не поддерживаются (мы используем их внутри virtualenv из-за обычных причин начальной загрузки pip - pip в значительной степени исключение из всего ;-))

двухлетний льготный период поддержки

Хм...

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

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

(надеясь, что в какой-то момент появятся IronPython и Jython - какие-нибудь еще мы должны поддерживать?)

Определенно. @gaborbernat, вероятно, знает, что я бы сказал это - было бы хорошо, если бы они были, но я почти уверен, что люди, более знакомые с реализацией, будут лучше всего подготовлены для этого. По крайней мере, с точки зрения поддержки в долгосрочной перспективе, а в идеале - также работа по обеспечению его хорошей поддержки в первую очередь (CI, тесты и т. Д.).

во-первых, поддержка конфигурации ini (глобальная конфигурация ini присутствует в доме пользователя),

Я пристрастен - мне бы очень хотелось, чтобы вместо этого был TOML. :)

(Я еще не полностью обработал это, так как мне нужно куда-то идти - но это действительно отличная общая цель!)

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

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

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

@pganssle другой объем и проблемное пространство тоже. virtualenv Проблема в том, что часто системы накладывают дополнительные ограничения на системные пакеты, поэтому они обезьяны исправляют встроенный venv, чтобы соблюдать их. Воспроизвести все это будет сложно, см., Например, # 1362.

FWIW Я думаю, что использование встроенного пакета venv для изоляции - правильная идея, он встроен в фактический интерпретатор (а не distutils, который является просто модулем stdlib), поэтому он может делать вещи намного чище, чем virtualenv может.

Virtualenv также не нужно ничего обновлять, он просто будет использовать общедоступный API, что должно быть в порядке.

FWIW Я бы порекомендовал проверить свою старую ветку rewrite virtualenv, она уже сделала много из этих вещей.

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

ТАКЖЕ, вы все еще можете полагаться на вещи «естественно» и по-прежнему использовать zipapps, вам просто нужно продавать внутри самого zipapp. Я бы порекомендовал отказаться от повторного выполнения под целевым вариантом python, это плохо, и его можно сделать намного чище.

697 - старый пиар @dstufft

PYTHONPATH = / t / путь / к / virtualenv.whl python -m virtualenv

OTOH, нам, вероятно, все равно не стоит этого делать - https://www.python.org/dev/peps/pep-0427/#is -it-possible-to-import-python-code-direct-from- напильник

@pradyunsg, так что какие-либо другие методы для начальной загрузки pip, не

Bootstrapping pip, вероятно, в порядке - это то, что сейчас использует virtualenv ¹ . Но я настоятельно рекомендую использовать его только для pip, а не как средство запуска самого virtualenv.

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

Есть ли причина, по которой мы не отправляем pip как zipapp ? Насколько я понимаю, это позволило бы избежать этой необходимости, а zipapp поддерживается в python 2.7 🤔

@gaborbernat ты пробовал? это работает? Если описанный вами подход работает в Windows, у меня нет никаких первоначальных опасений, но @uranusjr, скорее всего, получит обратную связь. Мои единственные комментарии соответствуют @dstuff, что означает: чем проще, тем лучше

Есть ли причина, по которой мы не отправляем pip как zipapp?

Потому что в некоторых случаях pip не запускается напрямую из zip-файла (или колеса, это то же самое), как я сказал выше. В 99% случаев (количество предупреждений) это работает, но иногда имеет значение тот факт, что пакет сертификатов должен быть настоящим файлом.

Вероятно, было бы неплохо связать pip как shiv , поскольку shiv распаковывает zipapp перед его запуском, именно для того, чтобы избежать угловых случаев, когда запуск из zip ломается. Однако, насколько мне известно, никто не пробовал.

Как обычно, основные причины, по которым этого не произошло:

1. Никто об этом не подумал.
2. Ни у кого не было времени / мотивации для этого.
3. Текущий подход работает нормально, и есть рыба побольше, которую нужно зажарить.

так что какие-либо другие методы для начальной загрузки pip, не ставя колесо на путь?

Я не думаю, что нам это нужно здесь - virtualenv использует pip wheel для установки из себя IIRC, что должно работать нормально. Как сказал @pfmoore , единственная «лишняя» вещь, которую делает get-pip.py, - это распаковка сертификатов и предоставление к ним пути. Поскольку вариант использования virtualenv не попадет в сеть, нам не нужно делать здесь ничего нового.

Текущий подход работает нормально, и есть рыба побольше, которую нужно зажарить.

Это намного больше, чем другие ИМО. Мы могли бы, но есть более серьезные проблемы, которые нужно решить. :)

В какой-то момент у меня был PR, который построил pip как zip-приложение, это сработало, но IIRC мне пришлось внести изменения в pip, чтобы сделать его полностью функциональным.

Теперь это может быть немного сложно, поскольку pip действительно вызывает себя как подпроцесс для PEP 517. Я не уверен, но это определенно стоит изучить.

На этом этапе shiv (или другой самораспаковывающийся вариант) будет более подходящим для pip, чем попытка превратить pip в zip-runnable. Но я не думаю, что сейчас это особенно важно. surepip уже идет по маршруту колеса-на-пути, почему бы просто не сделать то же самое. После того, как мы зажарим всех более крупных рыбок, можно будет изучить альтернативную загрузку пипа и, возможно, вернуть ее в stdlib.

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

Похоже на план [тот, которому мы уже следуем. ;)]

Спасибо за ссылки, основанные на отзывах, над которыми я начал некоторую первоначальную работу по адресу https://github.com/gaborbernat/virtualenv/tree/rewrite/src/virtualenv. Планируется привести его в форму выпуска в течение следующего месяца (а до этого провести неделю открытого обзора). Учитывая влияние изменения, я планирую выпустить 20.0.0 .

+1 за использование venv, если он существует. Это упростило бы использование PyPy.

Итак, переписывание дошло до состояния, когда я чувствую себя комфортно, когда люди смотрят на него и оставляют отзывы. Пожалуйста, свяжитесь со мной, если у вас есть свободное время, чтобы помочь с этим; план должен выпустить его к концу месяца 🤞 Примечание https://github.com/pypa/virtualenv/milestone/7 все еще необходимо реализовать, однако основная идея есть.

PS. Создал PR с обратной связью под https://github.com/pypa/virtualenv/pull/1481/

Запрос функции: предоставьте механизм для определения пользовательских переменных среды, например, поместив файл env.txt в каталог venv bin в стандартном формате:

VARNAME=value
OTHERVAR=othervalue

Я не думаю, что понимаю ваш вариант использования? Как эти переменные среды будут использоваться, установлены и когда?

Редактировать. НМ. Я вижу, вы подробно остановились на

Небольшое обновление; Мне удалось закрыть большинство проблем с блокировкой, кроме двух, которые все еще нуждаются в некоторой любви: тестирование включает заголовки + кеширование вызовов запросов Python с некоторой блокировкой, примененной к данным приложения, поэтому мы можем создавать виртуальные среды параллельно (в разных местах). При нынешних темпах я мог бы опоздать на несколько дней ... но определенно должен выйти к 7 февраля.

Каков наш план по развертыванию? Будет ли у нас выпущена бета-версия до основного выпуска?

Да, хочу выпустить что-нибудь в понедельник ... А потом оставьте ориентировочно неделю на отзывы, исправления ... А затем замените мастер на перезапись и выпуск.

Я не уверен на 100%, что недели будет достаточно, и мы обязательно должны сообщить по нескольким каналам, что мы хотим, чтобы люди опробовали бета-версию.

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

virtualenv 20.0.0 beta1 доступна .

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