Une proposition ambitieuse !

prise en charge de la configuration ini (une configuration ini globale présente dans la maison des utilisateurs)

Pensez à utiliser appdirs (ou similaire) pour découvrir la configuration dans les emplacements préférés de la plate-forme.

appdirs pourrait bien être une option, bien que nous devions alors commencer à vendre des éléments dans notre package. Pour être juste, 70 % de cela est déjà fait, il faudrait juste une meilleure réorganisation.

Pourquoi fournisseur plutôt que simplement dépendre de lui ? (Ce n'est pas difficile à vendre, ce n'est qu'un seul fichier). OMI, nous devons vraiment accepter que (à l'exception notable de pip) les outils de packaging doivent vraiment être construits comme n'importe quelle autre application. S'il est suffisamment difficile d'avoir des dépendances pour que les applications PyPA les évitent, qu'est-ce que cela dit sur la façon dont nous facilitons le développement d'applications pour nos utilisateurs ?

(Désolé, je ne parle pas de virtualenv ici, je vois juste tellement de gens dire "ajouter une dépendance PyPI n'est pas un gros problème", alors les outils PyPA sur lesquels je travaille me font me demander ...) .

Sans fournisseur, la fonction d'interpréteur croisé sera difficile, je pense. Par exemple, créer un environnement virtuel pour un interpréteur n'ayant pas virtualenv installé.

PYTHONPATH=/t/chemin/vers/virtualenv.whl python -m virtualenv

Euh, cela signifierait que nous ne pouvons dépendre d'aucun paquet supplémentaire de virtualenv. Puisque nous fournirons une zipapp, quels cas d'utilisation cela permet-il ?

@gaborbernat Vous voulez dire l'option -p ? Je suppose. Cela semble être exactement le genre de situation que zipapps était censée aider, mais personne n'a jamais vraiment fait grand-chose pour régler les détails de son bon fonctionnement.

De @pradyunsg :

Euh, cela signifierait que nous ne pouvons dépendre d'aucun paquet supplémentaire de virtualenv

En fait, comme l' a dit -p implique probablement que :-( Mais je me demande pourquoi nous avons besoin de l'option "wheel on PYTHONPATH " ainsi que de la zipapp - d'autant plus que les roues sur PYTHONPATH sont pas pris en charge en général (nous les utilisons en interne dans virtualenv pour des raisons habituelles d'amorçage pip - pip est à peu près une exception à tout ;-))

période de

Hmm...

Mon inquiétude ici est que les effets sur le réseau de cela pourraient entraîner un ralentissement de l'adoption des nouvelles versions de Python et l'explosion combinatoire du nombre de Pythons pris en charge. CPython discute d'une cadence de publication différente pour la 3.9, donc 2 ans pourraient même être plus longs que ce que certaines versions pourraient avoir des développeurs principaux.

Cela dit, je ne veux pas bloquer cela, mais surtout m'assurer de dire que je n'ai pas envie de le faire.

(en espérant IronPython et Jython à un moment donné - d'autres que nous devrions prendre en charge ?)

Définitivement. @gaborbernat sait probablement que je dirais ceci - ce serait bien d'avoir, mais je suis presque sûr que les gens qui sont plus familiers avec la mise en œuvre seraient les mieux placés pour le faire. A tout le moins en termes d'accompagnement sur le long terme, et idéalement aussi le travail de bien l'accompagner en premier lieu (CI, tests, etc.).

tout d'abord, la prise en charge de la configuration ini (une configuration ini globale présente dans la maison des utilisateurs),

Je suis partial - j'aimerais vraiment que ce soit TOML à la place. :)

(Je n'ai pas encore complètement traité cela car je dois aller quelque part - mais cela ressemble à un excellent objectif global !)

nous ne pouvons déjà pas vraiment dépendre de packages supplémentaires à cause de la fonctionnalité d'interpréteur croisé, donc je ne considère pas cela comme un inconvénient majeur, et j'aimerais avoir un moyen simple sans installation/dépendance d'exécuter des environnements virtuels (nécessaire lorsque les gens invoquez-nous à partir des packages de nœuds). Étant donné que cela ne nous coûte pas cher, l'offre de zipapp semble bon marché.

préférez venv intégré : si le python cible a venv, nous créerons l'environnement en l'utilisant (et effectuerons ensuite les opérations suivantes sur celui-ci pour faciliter les autres garanties que nous offrons)

Je ne suis pas sûr de comprendre la raison de cela. Il semble que cela rendra la maintenance de virtualenv plus difficile et rendra les comportements plus difficiles à comprendre pour les utilisateurs finaux. setuptools va déjà dans l'autre sens en essayant d'absorber distutils plutôt que de continuer à le patcher.

@pganssle la portée est différente et l'espace du problème aussi. virtualenv problème

FWIW Je pense qu'utiliser le package venv intégré pour l'isolation est la bonne idée, il est intégré à l'interpréteur réel (plutôt que distutils qui n'est qu'un module stdlib) afin qu'il puisse faire des choses beaucoup plus propres que virtualenv peut.

Virtualenv n'aurait pas non plus besoin de patcher quoi que ce soit, il utiliserait simplement l'API publique, ce qui devrait convenir.

FWIW Je recommanderais de vérifier mon ancienne branche de réécriture virtualenv, elle a déjà fait beaucoup de ces choses.

Je suggérerais probablement qu'un système de plugins n'est pas très utile pour virtualenv, au plus il n'y aura probablement qu'un seul crochet, une étape de création de post et même alors, vous pouvez probablement vous en sortir simplement en ayant une liste de choses à installer.

AUSSI, vous pouvez toujours dépendre de choses "naturellement" et toujours utiliser des zipapps, il vous suffit de les vendre à l'intérieur du zipapp lui-même. Je recommanderais de s'éloigner de l'option de réexécution sous cible python, c'est une mauvaise chose et peut être fait beaucoup plus proprement.

697 -- RP plus ancien de

PYTHONPATH=/t/chemin/vers/virtualenv.whl python -m virtualenv

OTOH, nous ne devrions probablement pas le faire de toute façon -- https://www.python.org/dev/peps/pep-0427/#is -it-possible-to-import-python-code-directly-from- un-roue-lime

@pradyunsg donc d'autres méthodes pour amorcer le pip sans mettre la roue sur le chemin?

L'amorçage du pip est probablement OK - c'est ce que virtualenv utilise maintenant ¹ . Mais je recommanderais fortement de ne l' utiliser que pour pip, et non comme moyen d'exécuter virtualenv lui-même.

¹ Mais j'éviterais toute fonctionnalité compliquée - l'utilisation d'une roue sur PATH pour installer le pip à partir de cette roue est à peu près garantie d'être OK. Mais vous pourriez avoir des problèmes si, par exemple, vous accédez à Internet à l'aide d'une telle roue, car je pense que certifi a besoin de son ensemble de certificats intégré en tant que fichier réel (mais je me trompe peut-être, cela ne m'a jamais posé de problème, mais je sais que get-pip.py extrait les certificats de la roue explicitement pour traiter ce point.

Une raison pour laquelle nous ne livrons pas de pip sous forme de zipapp ? Cela éviterait ce besoin si je comprends bien, et zipapp est pris en charge avec python 2.7 🤔

@gaborbernat tu l'as essayé ? est-ce que ça marche? si l'approche que vous avez décrite fonctionne sur Windows, je n'ai aucune préoccupation initiale, mais @uranusjr aurait probablement des commentaires. Mes seuls commentaires sont en ligne avec @dstuff c'est-à-dire -- plus simple c'est mieux

Une raison pour laquelle nous n'expédions pas le pip en tant que zipapp ?

Car dans certains cas, pip ne s'exécutera pas directement depuis un fichier zip (ou une molette, c'est la même chose), comme je l'ai dit plus haut. 99% (alerte - numéro composé) du temps, cela fonctionne, mais parfois le fait que le bundle de certificats doit être un vrai fichier est important.

Cela fonctionnerait probablement bien de regrouper pip en tant que shiv , car shiv décompresse l'application zip avant de l'exécuter, précisément pour éviter les cas extrêmes où l'exécution à partir d'un zip s'interrompt. Personne à ma connaissance ne l'a essayé, cependant.

Comme d'habitude, les principales raisons pour lesquelles cela ne s'est pas produit sont :

1. Personne n'y a pensé.
2. Personne n'a eu le temps/la motivation pour le faire.
3. L'approche actuelle fonctionne bien et il y a de plus gros poissons à fouetter.

donc d'autres méthodes pour amorcer le pip sans mettre la roue sur le chemin?

Je ne pense pas que nous ayons besoin de cela ici - virtualenv utilise la roue pip pour installer à partir de lui-même IIRC, ce qui devrait fonctionner correctement. Comme @pfmoore l'a dit, la seule chose "supplémentaire" que fait get-pip.py est de décompresser les certificats et de leur fournir un chemin d'accès. Étant donné que le cas d'utilisation de virtualenv n'atteindra pas le réseau, nous n'avons pas besoin de faire quoi que ce soit de nouveau ici.

L'approche actuelle fonctionne bien et il y a de plus gros poissons à fouetter.

Ceci, bien plus que les autres OMI. Nous pourrions, mais il y a des problèmes plus importants à résoudre. :)

J'ai eu un PR à un moment donné qui construisait pip en tant qu'application zip, cela fonctionnait mais IIRC j'ai dû apporter des modifications à pip pour le rendre pleinement fonctionnel.

Cela pourrait être un peu compliqué maintenant, car pip s'appelle lui-même comme un sous-processus de lui-même pour PEP 517. Je ne suis pas sûr, mais cela vaut vraiment la peine d'être exploré.

À ce stade, shiv (ou une autre option auto-extractible) serait plus approprié pour pip que d'essayer de travailler pip dans zip-runnable. Mais je ne pense pas que ce soit une chose particulièrement importante à ce stade. Assurezpip suit déjà la route de la roue sur le chemin, pourquoi ne pas faire de même. L'amorçage pip alternatif peut être exploré après avoir fait frire tous les plus gros poissons, et potentiellement être réinvesti dans stdlib.

L'amorçage alternatif des pépins peut être exploré après avoir fait frire tous les plus gros poissons

Cela ressemble à un plan [celui que nous suivons déjà. ;)]

Merci pour les liens, sur la base des commentaires, j'ai commencé un travail initial sur https://github.com/gaborbernat/virtualenv/tree/rewrite/src/virtualenv. Le plan est de le mettre sous forme de version d'ici le mois prochain (et d'avoir une semaine d'examen ouvert avant cela). En fonction de l'impact du changement, je prévois de le publier 20.0.0 .

+1 pour l'utilisation de venv s'il existe. Cela simplifierait le cas d'utilisation de PyPy.

Donc, la réécriture est arrivée à un état où je me sens à l'aise pour que les gens y jettent un coup d'œil et donnent leur avis. N'hésitez pas à me contacter si vous avez du temps libre pour m'aider ; le plan est de le publier d'ici la fin du mois 🤞 Remarque https://github.com/pypa/virtualenv/milestone/7 doit encore être mis en œuvre, cependant, l'idée de base est là.

PS. Création d'un PR de rétroaction sous https://github.com/pypa/virtualenv/pull/1481/

Demande de fonctionnalité : fournir un mécanisme pour définir des variables d'environnement personnalisées, par exemple en plaçant un fichier env.txt dans le répertoire venv bin au format standard :

VARNAME=value
OTHERVAR=othervalue

Je ne pense pas comprendre votre cas d'utilisation? Comment ces variables d'environnement seraient-elles utilisées, définies, quand ?

Éditer. NM. Je vois que vous avez développé sur https://github.com/pypa/virtualenv/issues/1124.

Une petite mise à jour; J'ai réussi à résoudre la plupart des problèmes de blocage, à l'exception de deux qui ont encore besoin d'amour : les tests incluent les en-têtes + la mise en cache des appels d'interrogation python avec un verrou appliqué sur les données de l'application, afin que nous puissions créer des environnements virtuels en parallèle (vers différents emplacements). Au rythme actuel, j'ai peut-être quelques jours de retard... mais je devrais certainement sortir d'ici le 7 février.

Quel est notre plan en termes de déploiement ? Aurait-on une version bêta avant la version principale ?

Ouais, je veux sortir quelque chose lundi... Et puis laissez provisoirement une semaine pour les retours, les correctifs... Et puis remplacez master par rewrite et release.

Je ne suis pas sûr à 100 % qu'une semaine suffirait et nous devons absolument communiquer sur plusieurs canaux pour que les gens essaient la version bêta.

Le mot-clé était provisoirement . Je suis optimiste ici, étant donné les efforts que j'ai fournis, je ne m'attends pas à des problèmes majeurs, mais

virtualenv 20.0.0 beta1 est disponible .

Comme la version bêta est sortie, je pense que cette question est servie est le but. Je vais clore et nous pourrons discuter de manière plus ciblée sur des sujets dédiés.