Pip: Erreur avec `import pip` dans pip 9.0.2

Je peux également le confirmer. Je suis sur le point de déposer le même problème.

Ceci est un dupe de # 5079 - l'importation de pip n'est pas un cas d'utilisation pris en charge (et ne l'a jamais été).

Allez .. faire un énorme changement de rupture dans une seule bosse de version x.x.PATCH ? Pour une méthode de niveau supérieur appelée "main" ? Je pense que c'est une forme assez pauvre ..

Cela a également cassé Anaconda et j'ai trouvé la même solution que @Miserlou :

https://github.com/ContinuumIO/anaconda-issues/issues/8911

Des erreurs sont signalées dans de nombreux projets.

Cette erreur m'a également dérangé lorsque j'essayais d'utiliser pip pour mettre à jour mon anaconda-navigator.

Y a-t-il une chance que nous obtenions une version 9.0.3 qui corrige cela - idéalement assez tôt ?

Cela affecte déjà de nombreux projets majeurs (Anaconda, SpaCy, Zappa), et il y a plus de 850 000 utilisations de cela sur GitHub seul qui sont maintenant interrompues par cette supposée mise à jour de version "corrective".

Pouvez-vous au moins annuler ce changement massif dans la version 9.0.3, puis _annoncer_ en aval votre intention de modifier ce comportement pour une future version 10.xx ou au moins 9.xx ?

Nous ne voulons pas non plus utiliser une version plus ancienne, mais c'est exactement ce que nous avons fini par faire. 9.0.2 n'existe pas dans notre environnement CI, du moins pour le moment.

Voir également ce succès dans certains projets OpenStack.

Pip 10 devrait sortir dans environ un mois. Si je comprends bien, le problème concerne le code qui utilise import pip pour accéder aux fonctionnalités internes de pip. Nous n'avons jamais pris en charge officiellement une telle utilisation, et nous avons explicitement documenté ce manque de prise en charge depuis un certain temps maintenant (bien que seulement dans la "dernière" version de la documentation sur https://pip.pypa.io/en/latest/user_guide /#using-pip-from-your-program, car nous n'avons pas eu de nouvelle version stable depuis que cette section doc a été ajoutée). Nous avons également annoncé une réorganisation des internes pour préciser que l'utilisation des API internes n'est pas prise en charge, en octobre dernier (voir https://mail.python.org/pipermail/distutils-sig/2017-October/031642.html). Ce changement, qui se trouve dans pip 10, interrompra toute utilisation de ce type, quel que soit le pip qu'une éventuelle version de pip 9.0.3 ferait. Il est donc difficile de voir cela comme une rupture soudaine et inattendue.

Si @dstufft veut faire une version d'urgence 9.0.3, ça me va. Mais ce ne sera qu'un avantage à très court terme, et je suis un peu déçu que les gens ne se soient pas encore éloignés de import pip . Les personnes touchées par ce problème devront toujours se préparer au pip 10 et doivent comprendre que le simple fait de passer à import pip._internal n'est pas quelque chose que nous soutiendrons ou recommanderons.

Les propositions de réintroduction d'un certain niveau de prise en charge de l'API sont certainement une option (voir # 5080 par exemple) mais à ce stade, il est trop tard pour que de telles modifications soient intégrées au pip 10.

En l'absence d'avertissements générés par le code pour ceux qui utilisent l'ancienne méthode, rien ne dénotant cela comme "interne" en commençant par _, et ceci n'étant qu'une correction de bogue, je pense en fait qu'il est assez facile de voir cela comme une rupture soudaine et inattendue .

Oui, c'est le type de changement que les gens pourraient attendre d'une mise à jour de version MAJOR . Ça serait bien.

Malheureusement, ce changement massif est venu dans une mise à jour PATCH , qui est _censée réparer les choses, pas les casser_. C'est l'exact opposé du versioning sémantique. Et, par conséquent, nous constatons des dommages massifs dans l'écosystème Python.

Vous devriez annuler ce changement dès que possible dans une autre mise à jour PATCH , puis faire en sorte que le changement majeur vienne avec la mise à jour de la version MAJOR . Maintenant que vous avez déjà tout cassé pour tout le monde prématurément, je pense qu'ils seront plus conscients que le changement majeur réel est à venir.

Je pense aussi que c'est un flic de dire que cela a déjà été documenté et annoncé, étant donné que ce n'était _pas_ documenté dans la documentation stable , et que l'annonce indiquait que la pause se produirait _pour la version majeure_, pas pour un patch par mois avant.

S'il vous plaît, sauvez tout le monde d'un énorme mal de tête, renversez ce problème et commencez à adhérer au versioning sémantique.

@Miserlou OK, je comprends votre point de vue - nous avons ciblé le changement de nom interne pour pip 10 car il s'agit d'une version majeure. Je ne connais pas vraiment les pilotes pour la version du correctif - @dstufft m'a envoyé un ping à ce sujet et c'est apparemment pour éviter une casse importante pour les utilisateurs de Mac OS lorsqu'une date limite imminente pour le support TLS nous frappe, c'est-à-dire avant la sortie de pip 10. Nous nous attendions à ce que les problèmes soient suffisamment importants pour justifier une publication de correctif à court terme. Il n'y avait certainement aucune intention de briser l'usage existant.

Je dois laisser la décision d'un suivi 9.0.3 à @dstufft - je n'ai pas les détails de ce qui s'est passé dans 9.0.2 ou je ne sais pas s'il est même possible d'identifier comment résoudre ce problème. Et je ne peux pas juger si le retrait total de 9.0.2 sera un avantage global, car je n'ai aucune idée du nombre de personnes concernées par le problème de Mac OS. Je comprends que (au moins pour certaines personnes) l'épinglage à 9.0.1 est une solution, donc cela peut finir par être la moins mauvaise option.

Le problème macOS TLS affectera tous ceux qui utilisent un système Python sur macOS <10.13

Je dois laisser la décision d'un suivi 9.0.3 à @dstufft

Je suis de la même position que @pfmoore.

La solution de contournement, si vous l'avez à votre disposition, consiste à vérifier l'ordre des importations et à tester le déplacement du pip d'importation au-dessus des autres importations de packages (en particulier, l'importation de requêtes d'importation de pip _before_ semble résoudre certains cas). (Notez que cela implique toujours l'utilisation des composants internes de pip, qui ne sont pas officiellement pris en charge.)

Même problème ici avec pip 9.0.2 dans un gitlab-ci avec docker python 3.4 : KeyError

  File "/usr/local/lib/python3.4/site-packages/pip/__init__.py", line 45, in <module>
    from pip.vcs import git, mercurial, subversion, bazaar  # noqa
  File "/usr/local/lib/python3.4/site-packages/pip/vcs/mercurial.py", line 9, in <module>
    from pip.download import path_to_url
  File "/usr/local/lib/python3.4/site-packages/pip/download.py", line 40, in <module>
    from pip._vendor import requests, six
  File "/usr/local/lib/python3.4/site-packages/pip/_vendor/requests/__init__.py", line 98, in <module>
    from . import packages
  File "/usr/local/lib/python3.4/site-packages/pip/_vendor/requests/packages.py", line 12, in <module>
    sys.modules['pip._vendor.requests.packages.' + mod] = sys.modules["pip._vendor." + mod]
KeyError: 'pip._vendor.urllib3.contrib'

Pour votre information, la version 9.0.2 est sortie avec des builds cassés :

Référence Travis-CI : https://travis-ci.org/pypa/pip/builds/354616774?utm_source=github_status&utm_medium=notification

Certes, les erreurs peuvent être sans rapport, même si cela sent juste une "version précipitée"...

@pfmoore

Si @dstufft veut faire une version d'urgence 9.0.3, ça me va. Mais ce ne sera qu'un avantage à très court terme, et je suis un peu déçu que les gens ne se soient pas encore éloignés du pip d'importation. Les personnes touchées par ce problème devront toujours se préparer au pip 10 et doivent comprendre que le simple fait de passer à l'importation pip._internal n'est pas quelque chose que nous prendrons en charge ou recommanderons.

Je n'arrive pas à croire qu'il s'agisse d'une déclaration du propriétaire de ce référentiel... Vous venez littéralement de dire "putain de version sémantique" et "qui a besoin d'une politique de dépréciation de toute façon".

pip a toujours été documenté comme n'ayant PAS d'api python consommable, je suis déçu par les gens qui, même à ce moment-là, essaient de renverser le karma "je vous l'ai dit depuis quelques années"

@RonnyPfannschmidt C'est comme dire "Nous vous avons dit 100 fois que vous n'êtes pas autorisé à dépasser la limite de vitesse", puis appliquer la limite de vitesse en remplaçant toutes les voitures à moteur par des voitures en silex, afin que les gens ne puissent pas dépasser le limite de vitesse plus.

vous venez de démontrer parfaitement que le détournement de mots si mauvais - le récit était "ne vous y fiez pas, ça va casser" - maintenant ça s'est cassé et tout à coup le projet qui vous a dit avant que ça va casser est en faute

qui ne fait que blâmer parce que vous n'aimez pas être en faute

@RonnyPfannschmidt

qui ne fait que blâmer parce que vous n'aimez pas être en faute

Donc, vous dites que je suis coupable d'avoir utilisé des packages tiers qui reposent sur une fonctionnalité non documentée de pip. Peut-être, je suis... J'aurais dû examiner ces packages tiers pour ces erreurs et soumettre un problème ou mieux encore un PR.

Mais regardons la réalité en face : il existe de nombreux projets utilisés dans la production qui sont maintenant cassés. Ce n'est pas une question de morale, pas une question de qui est la faute. C'est une question de "pouvez-vous s'il vous plaît résoudre ce problème et fournir un avertissement/dépréciation approprié".

Si un package tiers que vous utilisez tombe en panne parce qu'il repose sur des API internes non documentées et non garanties, il me semble que vous devriez signaler un bogue pour ce package.

Il y a une ligne facile à découvrir entre les parties de pip qui sont et ne sont pas destinées à la consommation de tiers, et je ne supporte pas d'essayer de forcer ses développeurs à maintenir des API internes qui n'auraient jamais dû l'être consommés par des packages tiers. Je ne supporte pas de traiter cela comme la faute des développeurs pip et d'envoyer des utilisateurs en colère sur leur chemin. Si vous voulez vous mettre en colère contre quelqu'un, soyez en colère contre tous les packages que vous utilisez et qui s'appuient sur des API internes, et poussez leurs responsables à corriger leur propre code.

@anx-ckreuzberger

Je n'arrive pas à croire qu'il s'agisse d'une déclaration du propriétaire de ce référentiel... Vous venez littéralement de dire "putain de version sémantique" et "qui a besoin d'une politique de dépréciation de toute façon".

Bien que je comprenne la frustration ici, je suis de plus en plus ennuyé par la volonté des gens de blâmer les responsables du pip pour des choses que nous n'avons jamais promises.

Si vous voulez faire de telles accusations, veuillez les appuyer avec

1. Un pointeur vers une déclaration de l'un des responsables de pip que nous prenons en charge l'utilisation de l'API interne de pip dans le code utilisateur.
2. Un pointeur vers une déclaration de l'un des responsables de pip indiquant que pip utilise la gestion sémantique des versions.

Je ne pense pas que tu trouveras cette preuve...

Vous dites donc que je suis coupable d'avoir utilisé des packages tiers qui reposent sur une fonctionnalité non documentée de pip.

Non, mais accuser les responsables du pip plutôt que ces projets n'est pas acceptable. Nous essayons de vous aider, mais nous ne pouvons être tenus responsables de ce que font ces projets. Exprimez vos griefs avec eux.

Mais regardons la réalité en face : il existe de nombreux projets utilisés dans la production qui sont maintenant cassés. Ce n'est pas une question de morale, pas une question de qui est la faute. C'est une question de "pouvez-vous s'il vous plaît résoudre ce problème et fournir un avertissement/dépréciation approprié".

Nous avons essayé de donner un avertissement. Nous avons envoyé des annonces il y a des mois , nous avons ajouté des documents expliquant la situation et nous avons systématiquement répondu aux problèmes sur le tracker indiquant que l'utilisation d'API internes n'est pas prise en charge. L'ajout de dépréciations est loin d'être aussi simple que vous le suggérez, car pip lui-même cracherait ces avertissements (ou il y aurait un moyen pour pip de les désactiver, que d'autres copieraient simplement - nous entendons déjà parler de personnes qui envisagent de simplement importez pip._internal , donc même ce changement ne les arrêtera pas : déçu :).

Quant à "réparer" cela, j'admets volontiers que la version 9.0.2 a été publiée rapidement pour résoudre un problème urgent, et nous n'avions pas anticipé ce problème. Peut-être que publier une version 9.0.3 avec une durée de vie de 2 à 3 semaines est une chose raisonnable à faire, je ne le pense pas moi-même, mais j'ai déclaré que nous y réfléchirions. Je ne peux personnellement pas accepter de le faire, car je ne suis pas celui qui est impliqué dans les versions 9.0.x. Je travaille sur pip 10, ce qui rendra tout ce débat hors de propos, donc c'est probablement mon dernier mot sur cette question - je dois me concentrer sur les choses liées à cette version.

Mon conseil personnel :

1. Épinglez à 9.0.1 si vous êtes concerné par cela et avez besoin d'une solution de contournement maintenant .
2. Soyez prêt pour pip 10, lorsque toutes les dépendances que vous avez actuellement et qui sont brisées parce qu'elles utilisent des API internes pip se briseront à nouveau. Poussez ces dépendances pour agir sur les informations que nous donnons depuis des mois, et soyez heureux d'avoir été averti à l'avance que cela se produirait.
3. Si pip 9.0.3 est publié, retirez la broche.
4. S'il vous plaît , testez la version bêta de pip 10 lorsqu'elle sort et signalez tout problème aux parties concernées (projets tiers s'ils appellent pip en interne, nous si vous appelez pip vous-même).

J'ai rencontré le même problème avec pip 9.0.2 et Python 2.7.14 dans un conteneur docker.
Cependant, je ne peux pas reproduire le problème sur ma machine de développement en dehors d'un conteneur Docker.
J'ai cherché une importation de pip (grep'd pour import.pip , from.pip , \'pip , \"pip ) mais je n'ai rien trouvé.
Chez Plone, nous utilisons un mécanisme pour inclure automatiquement les configurations des packages inclus dans un fichier setuptools setup.py, ce qui semble suspect - mais encore une fois - celui-ci utilise simplement __import__ et rien de pip AFAIcansee.

Voici la partie pertinente du retraçage :

  File "/home/plone/.buildout/shared-eggs/zope.configuration-3.7.4-py2.7.egg/zope/configuration/xmlconfig.py", line 359, in endElementNS
    self.context.end()
  File "/home/plone/.buildout/shared-eggs/zope.configuration-3.7.4-py2.7.egg/zope/configuration/config.py", line 558, in end
    self.stack.pop().finish()
  File "/home/plone/.buildout/shared-eggs/zope.configuration-3.7.4-py2.7.egg/zope/configuration/config.py", line 706, in finish
    actions = self.handler(context, **args)
  File "/home/plone/.buildout/shared-eggs/z3c.autoinclude-0.3.7-py2.7.egg/z3c/autoinclude/zcml.py", line 51, in includeDependenciesDirective
    info = DependencyFinder(dist).includableInfo(['configure.zcml', 'meta.zcml'])
  File "/home/plone/.buildout/shared-eggs/z3c.autoinclude-0.3.7-py2.7.egg/z3c/autoinclude/dependency.py", line 26, in includableInfo
    module = resolve(dotted_name)
  File "/home/plone/.buildout/shared-eggs/zope.dottedname-4.2-py2.7.egg/zope/dottedname/resolve.py", line 39, in resolve
    found = __import__(used)
  File "/plone/buildout/lib/python2.7/site-packages/pip/__init__.py", line 45, in <module>
    from pip.vcs import git, mercurial, subversion, bazaar  # noqa
  File "/plone/buildout/lib/python2.7/site-packages/pip/vcs/mercurial.py", line 9, in <module>
    from pip.download import path_to_url
  File "/plone/buildout/lib/python2.7/site-packages/pip/download.py", line 40, in <module>
    from pip._vendor import requests, six
  File "/plone/buildout/lib/python2.7/site-packages/pip/_vendor/requests/__init__.py", line 98, in <module>
    from . import packages
  File "/plone/buildout/lib/python2.7/site-packages/pip/_vendor/requests/packages.py", line 12, in <module>
    sys.modules['pip._vendor.requests.packages.' + mod] = sys.modules["pip._vendor." + mod]
zope.configuration.xmlconfig.ZopeXMLConfigurationError: File "/plone/buildout/parts/instance/etc/site.zcml", line 15.2-15.55
    ZopeXMLConfigurationError: File "/plone/buildout/parts/instance/etc/package-includes/002-bda.aaf.site-configure.zcml", line 1.0-1.56
    ZopeXMLConfigurationError: File "/plone/buildout/src-aaf/bda.aaf.site/src/bda/aaf/site/configure.zcml", line 11.2-11.48
    ZopeXMLConfigurationError: File "/plone/buildout/src-aaf/bda.aaf.site/src/bda/aaf/site/configure-dependencies.zcml", line 10.2-10.39
    ZopeXMLConfigurationError: File "/plone/buildout/src-addons/plone.app.mosaic/src/plone/app/mosaic/configure.zcml", line 9.2-9.39
    ZopeXMLConfigurationError: File "/home/plone/.buildout/shared-eggs/plone.app.tiles-3.0.3-py2.7.egg/plone/app/tiles/configure.zcml", line 18.2-18.41
    ZopeXMLConfigurationError: File "/plone/buildout/src/plone.app.z3cform/plone/app/z3cform/configure.zcml", line 10.2-10.41
    ZopeXMLConfigurationError: File "/plone/buildout/src/plone.app.widgets/plone/app/widgets/configure.zcml", line 12.2-12.41
    ZopeXMLConfigurationError: File "/home/plone/.buildout/shared-eggs/Products.CMFPlone-5.1.0.1-py2.7.egg/Products/CMFPlone/configure.zcml", line 15.2-15.46
    ZopeXMLConfigurationError: File "/home/plone/.buildout/shared-eggs/plone.app.contenttypes-1.4.9-py2.7.egg/plone/app/contenttypes/configure.zcml", line 10.2-10.37
    KeyError: 'pip._vendor.urllib3.contrib'

Autant que je sache, l'importation de pip - sans l'utiliser - se casse déjà. Ce n'est pas un bon comportement citoyen au pays Python. Ne pas prendre en charge son utilisation/ne pas fournir d'API publique est une chose, se casser lors de l'importation en est une autre. Cela affecte beaucoup de code d'auto-inspection.

Pensez-y de cette façon : pip est un utilitaire de ligne de commande, pas une bibliothèque. Le fait qu'il soit écrit en Python n'est pas pertinent. C'est la réalité de la question.

@pfmoore

Bien que je comprenne la frustration ici, je suis de plus en plus ennuyé par la volonté des gens de blâmer les responsables du pip pour des choses que nous n'avons jamais promises.

Pensez-y de cette façon : pip est un utilitaire de ligne de commande, pas une bibliothèque. Le fait qu'il soit écrit en Python n'est pas pertinent. C'est la réalité de la question.

L'essentiel est que ce que vous avez promis n'a vraiment pas d'importance. Ce qui compte, c'est ce que vous avez fait et quelle est la situation qui en résulte. Peut-être l'avez-vous pensé comme un utilitaire de ligne de commande. Mais vous l'avez publié en tant que bibliothèque. C'est la réalité du sujet :

Vous avez publié une bibliothèque avec la fonctionnalité X. Les gens ont commencé à utiliser la fonctionnalité X. Bien sûr, vous avez dit "les gars, s'il vous plaît, n'utilisez pas la fonctionnalité X". Mais vous avez continué à le publier avec Feature X. Pendant des années. Et donc les gens ont continué à l'utiliser. Des dizaines, voire des centaines, des milliers de projets, petits et grands, l'utilisent maintenant. Soudain, vous le supprimez dans une mise à jour mineure sans avertissement adéquat.

Que pensez-vous qu'il se passe ensuite?

À court terme, les gens épingleront simplement l'ancienne version et ne la détacheront pas à moins qu'il y ait une bonne raison.

À long terme... eh bien, cela dépend du nombre de personnes qui décident qu'il serait plus rentable de vous remplacer que de réparer tout ce que vous avez cassé.

@pfmoore voyez -vous quelque chose de suspect dans le retraçage auquel j'ai fait référence ci-dessus ? AFAIK, aucun pip interne n'est utilisé. Il est intéressant de noter que la plupart des gens ont ce problème dans les conteneurs Docker.

@ tous, accuser les mainteneurs de code cassé n'aide pas à résoudre le problème.

Pensez-y de cette façon : pip est un utilitaire de ligne de commande, pas une bibliothèque. Le fait qu'il soit écrit en Python n'est pas pertinent. C'est la réalité de la question.

Fait : Il ne peut pas être importé, s'il est importé même par le code d'auto-inspection pour une raison quelconque : toutes les pauses. Je suppose que cela se produit dans le cas de @thet .
Conclusion : pip doit s'isoler de l'espace de noms Python virtualenv/venv global ou actuel dans lequel il installe les packages. De cette façon, il ne le pollue pas et même l'importation accidentelle ne se produit jamais.

Tout d'abord, désolé si j'ai accusé les mainteneurs du dépôt de code défectueux. Toute accusation a été faite par frustration et, le cas échéant, souligne le fait qu'à mon humble avis, la version 9.0.2 est par définition de semver une version de correctif (bien que @pfmoore ait clairement indiqué que pip n'utilise pas nécessairement semver - ce qui est un autre problème pour un autre jour, je suppose).

@MikeHart85

À court terme, les gens épingleront simplement l'ancienne version et ne la détacheront pas à moins qu'il y ait une bonne raison.
À long terme... eh bien, cela dépend du nombre de personnes qui décident qu'il serait plus rentable de vous remplacer que de réparer tout ce que vous avez cassé.

Plutôt. Je veux dire, regardez les gestionnaires de packages JavaScript : npm, bower, yarn, tout ce qui sortira la semaine prochaine ~ l'année ~

Non, mais accuser les responsables du pip plutôt que ces projets n'est pas acceptable. Nous essayons de vous aider, mais nous ne pouvons être tenus responsables de ce que font ces projets. Exprimez vos griefs avec eux.

Je comprends que mes (nos ?) griefs concernant cette question pourraient être mal orientés. Bien que vous deviez admettre qu'il est vraiment difficile de convaincre qui que ce soit que c'est la faute des mainteneurs tiers.

Nous avons essayé de donner un avertissement. Nous avons envoyé des annonces il y a des mois, nous avons ajouté des documents expliquant la situation

Était-ce pour pip 9.0.2 ou pour pip 10 ? Si c'était pour pip 9.0.2, je trouverais ça bien s'il y avait une note dans le Changelog . Quoi qu'il en soit, merci d'être très proactif dans le développement de pip 10 et d'envoyer des annonces sur la non-utilisation import pip , c'est bien ! Continue comme ça!

L'ajout de dépréciations est loin d'être aussi simple que vous le suggérez, car pip lui-même cracherait ces avertissements (ou il y aurait un moyen pour pip de les désactiver, que d'autres copieraient simplement - nous entendons déjà parler de personnes qui envisagent de simplement importez pip._internal, donc même ce changement ne les empêchera pas d'être déçus).

Je ne pense pas que ce serait trop difficile... Vous avez déjà ceci dans le __init__.py :

if __name__ == '__main__':
    sys.exit(main())

Que diriez-vous d'ajouter simplement un autre?

if __name__ == '__main__':
    sys.exit(main())
else:
    logger.warning("You are importing PIP as a Python library. This behaviour is deprecated and should no longer be used. We will break the API with version 10.0!!!111eleven Please see https://pip.readthedocs.org/some_link_where_you_explain_this.html")

edit : Vous pouvez même déclencher une exception ici si vous voulez être "strict" à ce sujet et ajouter des instructions similaires aux sous-modules.

Le fait que les gens vont contourner cela, c'est autre chose. Si vous voulez pirater une bibliothèque, vous pouvez toujours la désosser. Vous pouvez toujours trouver un moyen de le contourner. Mais vous ne devriez pas considérer toutes les façons de le contourner dans vos décisions de conception.

À long terme... eh bien, cela dépend du nombre de personnes qui décident qu'il serait plus rentable de vous remplacer que de réparer tout ce que vous avez cassé.

Je trouve toujours cette "menace" amusante. Cela s'accompagne d'un malentendu fondamental sur la quantité d'efforts investis dans quelque chose comme le pip et combien cela coûte vraiment (et combien peu de gens sont prêts à payer pour cela). Si vous sentez que vous êtes capable de faire mieux, alors faites-le par tous les moyens, je (et j'assume les autres) je m'en réjouis. Au cours des dernières années, des efforts non négligeables ont été consacrés à la documentation et à la conception de normes, l'un des objectifs explicites étant de permettre qu'une telle chose se produise.

Il est important de garder un sens de la perspective sur ces choses. Il y en a moins de 15 ? 20 ? les gens commentant comment cela les a brisés (bien qu'il y ait toujours un problème de "pointe de l'iceberg" avec ces métriques), pendant ce temps, pip 9.0.2 est déjà le deuxième programme d'installation le plus utilisé au cours de la semaine dernière (en comptant les jours où il n'a même pas existé for) et a téléchargé 17 millions de fichiers depuis PyPI depuis sa sortie. En regardant juste le dernier jour, c'est 80% du chemin pour dépasser pip 9.0.1 en tant qu'installateur le plus utilisé sur PyPI.

Donc, bien que je reconnaisse que cela a cassé les choses pour certaines personnes, c'est un nombre relativement restreint de personnes qui font soit des choses non prises en charge, soit dans des situations assez marginales.

SI je peux trouver le temps, je peux essayer de couper un 9.0.3, principalement pour résoudre le cas où @thet s'est heurté où il s'agit simplement d'un importateur automatique essayant d'importer des choses, et ils n'essaient pas réellement d'utiliser les API internes de pip de quelque manière que ce soit. Si cela finit également par résoudre le comportement des personnes utilisant les API internes de pip, je ne vais pas faire tout mon possible pour les casser spécifiquement, mais si ce n'est pas le cas, je ne vais pas non plus faire tout mon possible pour réparer eux spécifiquement non plus.

Veuillez noter qu'il faut de nombreuses heures pour publier une version 9.0.x à ce stade (les choses ont suffisamment divergé dans master pour qu'il faille un peu de doigté pour faire une version) et cela ne compte pas le temps nécessaire pour déboguer et résoudre le problème réel. Si vous voulez augmenter les chances que cela se produise, faire ce débogage et corriger et fournir un correctif (ou une branche de la balise 9.0.2 dans votre propre fork) est la meilleure façon de le faire.

Tout d'abord, désolé si j'ai accusé les mainteneurs du dépôt de code défectueux. Toute accusation a été faite par frustration

Merci. La frustration est grande ici, et je le comprends.

Que diriez-vous d'ajouter simplement un autre?

Bonne idée - j'aurais aimé que nous y pensions il y a quelque temps. Bien sûr, cela ne sert à rien maintenant, car l'espace de noms interne sera réorganisé dans pip 10, il est donc trop tard. Je me souviendrai certainement de cette astuce pour l'avenir.

Était-ce pour pip 9.0.2 ou pour pip 10 ?

Pour 10.0. Il n'y avait aucune intention initiale de publier une version 9.0.2, nous l'avons fait uniquement en tant que version d'urgence afin que les utilisateurs de Mac OS ne perdent pas tout accès à PyPI lorsque les modifications TLS entreront en vigueur.

@dstufft a répondu ici beaucoup plus complètement, donc je pense que c'est aussi résolu que possible pour le moment.

Je trouve toujours cette "menace" amusante.

Ce n'est pas du tout une menace, excusez-moi si c'est arrivé de cette façon.

C'est une observation à propos de quelque chose qui arrive trop souvent dans le monde du logiciel. Les gens ne travaillent pas avec vos promesses ou vos intentions. Les gens travaillent avec le produit que vous livrez. Si votre produit possède une fonctionnalité dont beaucoup de gens dépendent, vous ne pouvez plus simplement l'arracher sous leurs pieds. Si vous le faites, ils commenceront à voir votre produit comme cassé. Si la seule explication que vous fournissez est "eh bien, nous n'avons jamais promis cela de toute façon", alors ils commencent à voir votre réticence à reconnaître leurs préoccupations comme une responsabilité.

Plus cela se produit, plus le désir et la demande d'une alternative sont grands. Bien sûr, les gens sous-estiment la quantité de travail que cela demande. Mais cela ne fait que les rendre plus , et non moins, susceptibles de commencer à travailler sur un. Une fois que cette balle roule, elle a sa propre vie.

Les alternatives ne sont pas toujours une bonne chose. Ils ont tendance à rendre les choses désordonnées. Personnellement, je préférerais un seul gestionnaire de paquets. Pour tout. Mais je me contenterai d'un seul gestionnaire de paquets pour Python.

Lorsque les gens signalent que vous avez cassé une fonctionnalité, intentionnellement ou non, pensez à expliquer brièvement pourquoi vous avez dû la casser, ou pourquoi la conserver n'était pas viable, plutôt que de rejeter les préoccupations avec "cela n'a pas été pris en charge depuis le début".

Hey @dstufft , merci d'avoir répondu. Ce fil devient assez chaud !

Tout d'abord, je vous remercie pour votre travail ! Je sais que la maintenance est une tâche interminable et ingrate, et j'imagine que cela ne fait qu'empirer lorsque vous gérez un projet aussi vaste et populaire que pip !

Passons maintenant au problème : bien que vingt _maintainers_ aient signalé ce problème jusqu'à présent, je sais qu'il affecte déjà des milliers de _personnes_ - certains des projets concernés sont énormes en eux-mêmes : Anaconda, OpenStack, SpaCy, Zappa, et ont plusieurs dizaines de milliers d'utilisateurs. Je sais que notre chaîne Slack est inondée de discussions à ce sujet. (Littéralement, alors que je tapais ceci, un nouveau problème est apparu.)

De toute évidence, de nombreux projets Python importants nécessitent la possibilité d'inspecter par programmation leurs environnements. C'est une chose tout à fait raisonnable qu'il faut pouvoir faire. De plus, la documentation n'a jamais mis en garde contre cela - et ne le fait toujours pas ! (Cliquez sur le lien Docs à partir du fichier README de ce référentiel !)

Je pense que la situation jusqu'à présent est:

• Étant donné le format de la chaîne de version, nous pensions tous que les responsables de pip suivaient la version sémantique
• Les mainteneurs de pip ont publié un "correctif" qui a introduit un changement massif
• Ce changement a été non annoncé et non documenté - et je suppose, inattendu et involontaire
• Maintenant, le simple fait d'appeler import pip casse immédiatement un programme, qui est extrêmement hostile aux développeurs
• Cela cause des maux de tête majeurs dans l'écosystème Python
• La documentation ne met pas en garde contre l'utilisation pip par programmation.
• Il n'y a pas eu d'annonce que import pip causerait ces dommages dans une mise à jour PATCH - cette annonce est venue pour une version qui _n'a pas encore été publiée_.
• Ce changement n'a même pas été mentionné dans le Changelog
• Nous ne voulons pas remplacer pip ou les développeurs de pip ! Nous t'aimons!
• ..mais nous ne voulons pas que ce genre de chose se reproduise !
• ..donc on veut que semver soit suivi!
• Nous aimerions vraiment, vraiment un autre PATCH qui annule ce changement majeur !

La nécessité d'un moyen programmatique d'inspecter un environnement dans un monde pip> = 10.0.0 est un sujet pour une autre discussion, mais le fait est qu'on ne nous a jamais dit que nous ne devrions pas utiliser pip par programme dans le pip <=9 monde, et il y a eu un changement massif et non annoncé, et nous aimerions vraiment qu'il soit inversé, car il affecte négativement des milliers de personnes.

Merci encore,
Riche

Tout d'abord : merci aux mainteneurs de pip pour leurs efforts et leurs idées au sein du projet. Je pense que cela aide vraiment les autres à comprendre le problème (bien que cela puisse valoir la peine d'écrire un article de blog récapitulatif à ce sujet).

@dstufft

Il est important de garder un sens de la perspective sur ces choses. Il y en a moins de 15 ? 20 ? les gens commentant comment cela les a brisés (bien qu'il y ait toujours un problème de "pointe de l'iceberg" avec ces métriques), pendant ce temps, pip 9.0.2 est déjà le deuxième programme d'installation le plus utilisé au cours de la semaine dernière (en comptant les jours où il n'a même pas existé for) et a téléchargé 17 millions de fichiers depuis PyPI depuis sa sortie. En regardant juste le dernier jour, c'est 80% du chemin pour dépasser pip 9.0.1 en tant qu'installateur le plus utilisé sur PyPI.

Je suis à peu près sûr que la métrique est fortement biaisée par toutes les commandes automatisées pip install pip --upgrade des systèmes d'intégration/livraison continue (ils doivent utiliser des caches et donc ne pas avoir besoin de réinstaller les packages de pypi tout le temps; mais à en même temps, il ne faut pas non plus faire import pip ... c'est ainsi que fonctionne le monde informatique).

Le fait que (moins de) 15 personnes se soient plaintes à ce sujet devrait montrer deux choses :

1. Je ne pense pas que beaucoup de gens utilisent encore 9.0.2 (en production), certains essaient peut-être encore de déboguer ce problème et le résoudront "temporairement" en utilisant pip 9.0.1 à la place jusqu'à ce qu'il soit résolu (ou pour toujours .. .) - aussi, certaines personnes n'ont peut-être pas remarqué que quelque chose ne fonctionne pas encore...
2. Il y a des gens qui en parlent déjà dans les 2 jours suivant la sortie. Davantage de personnes rencontreront ce problème. Attendez 2 semaines et vous pourriez finir par avoir 100 personnes qui s'en plaignent (par exemple, lorsqu'elles terminent un sprint et se déploient en QA/staging). À ce stade, vous ne savez vraiment pas combien de personnes seront touchées par ce changement.

Quoi qu'il en soit, parler et discuter de ce problème donne aux gens un bon exemple de la raison pour laquelle il ne faut jamais se fier aux API internes, et j'espère que certains responsables de paquets tiers mettront à jour leurs projets à cause de ce qui a été dit ici.

De toute évidence, de nombreux projets Python importants nécessitent la possibilité d'inspecter par programmation leurs environnements. C'est une chose tout à fait raisonnable qu'il faut pouvoir faire. De plus, la documentation n'a jamais mis en garde contre cela - et ne le fait toujours pas ! (Cliquez sur le lien Docs à partir du fichier README de ce référentiel !)

Je ne comprends pas pourquoi vous devriez mettre en garde contre cela. L'utilisation de pip comme autre chose qu'un outil de ligne de commande est totalement non documentée . En cherchant dans la documentation, je ne vois aucune référence à l'importation de pip. C'est comme se plaindre parce que vous vous êtes lié à certains .so utilisés par Chrome et qu'ils ont rompu la compatibilité ABI.

L'interprétation habituelle de SemVer est qu'il s'applique à l'interface publique prise en charge (dans ce cas, la CLI), et non aux éléments internes non documentés. Toute personne utilisant les composants internes devrait de toute façon épingler ses versions pip , car elles sont sujettes à des modifications arbitraires.

Il n'y a vraiment rien à inverser. Le rétroportage des correctifs pour empêcher un nombre important d'utilisateurs sur macOS de ne pas pouvoir accéder à PyPI dans un avenir proche présente un bogue lorsqu'il est appliqué à la base de code 9.0.x qui semble ne s'exprimer que dans des conditions non prises en charge. La seule voie à suivre consiste à effectuer un travail supplémentaire pour résoudre ce bogue dans la série 9.0.x. Comme je l'ai dit, si je peux trouver le temps, j'essaierai de le faire, si vous voulez augmenter les chances que cela se produise, fournissez un correctif.

La documentation ne le met pas en garde car il n'est pas possible de fournir une liste exhaustive des choses que vous pourriez éventuellement faire avec pip mais qui ne sont pas prises en charge. Au lieu de cela, nous nous appuyons sur l'approche assez courante consistant à documenter ce qui est pris en charge et tout ce qui n'est pas documenté doit être considéré comme non pris en charge (et si vous voulez vous fier à quelque chose qui n'est pas documenté, ouvrez un problème le demandant documenté et donc pris en charge ).

À plus long terme, nous allons probablement évoluer vers un système de publication basé sur la date pour (espérons-le) éliminer toute confusion quant à savoir si nous sommes semver ou non.

Envoyé de mon iPhone

Le 20 mars 2018, à 11h02, Rich Jones [email protected] a écrit :

Hey @dstufft , merci d'avoir répondu. Ce fil devient assez chaud !

Tout d'abord, je vous remercie pour votre travail ! Je sais que la maintenance est une tâche interminable et ingrate, et j'imagine que cela ne fait qu'empirer lorsque vous gérez un projet aussi vaste et populaire que pip !

Passons maintenant au problème en question : bien que vingt responsables aient signalé ce problème jusqu'à présent, je sais qu'il affecte déjà des milliers de personnes - certains des projets concernés sont massifs en eux-mêmes : Anaconda, OpenStack, SpaCy, Zappa, et ont plusieurs dizaines de milliers d'utilisateurs. Je sais que notre chaîne Slack est inondée de discussions à ce sujet. (Littéralement, alors que je tapais ceci, un nouveau problème est apparu.)

De toute évidence, de nombreux projets Python importants nécessitent la possibilité d'inspecter par programmation leurs environnements. C'est une chose tout à fait raisonnable qu'il faut pouvoir faire. De plus, la documentation n'a jamais mis en garde contre cela - et ne le fait toujours pas !

Je pense que la situation jusqu'à présent est:

Étant donné le format de la chaîne de version, nous pensions tous que les responsables de pip suivaient la version sémantique
Les mainteneurs de pip ont publié un "correctif" qui a introduit un changement massif
Ce changement a été non annoncé et non documenté - et je suppose, inattendu et involontaire
Maintenant, le simple fait d'appeler import pip casse immédiatement un programme, qui est extrêmement hostile aux développeurs
Cela cause des maux de tête majeurs dans l'écosystème Python
La documentation ne met pas en garde contre l'utilisation de pip par programme (et ne le fait toujours pas - cliquez sur le lien Docs dans le fichier README de ce référentiel).
Il n'y avait aucune annonce que l'importation de pip causerait ces dommages dans une mise à jour PATCH - cette annonce est venue pour une version qui n'a pas encore été publiée.
Ce changement n'a même pas été mentionné dans le Changelog
Nous ne voulons pas remplacer pip ou les développeurs de pip ! Nous t'aimons!
..mais nous ne voulons pas que ce genre de chose se reproduise !
..donc on veut que semver soit suivi!
Nous aimerions vraiment, vraiment un autre PATCH qui annule ce changement majeur !
La nécessité d'un moyen programmatique d'inspecter un environnement dans un monde pip> = 10.0.0 est un sujet pour une autre discussion, mais le fait est qu'on ne nous a jamais dit que nous ne devrions pas utiliser pip par programme dans le pip <=9 monde, et il y a eu un changement massif et non annoncé, et nous aimerions vraiment qu'il soit inversé, car il affecte négativement des milliers de personnes.

Merci encore,
Riche

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub ou désactivez le fil de discussion.

@Miserlou

Étant donné le format de la chaîne de version, nous pensions tous que les responsables de pip suivaient la version sémantique

En tant que personne fortement opposée à semver, pouvez-vous me dire dans quel format mes chaînes de version doivent être pour éliminer cette confusion ? "Trois nombres en pointillés" n'implique pas "suit strictement semver" pour moi, donc cette hypothèse est une surprise.

En réponse à ce commentaire : que pip adhère ou non à semver, ou promette de s'y conformer, l'utilisation d'un schéma de versionnage major.minor.micro porte toujours la promesse implicite d'une sorte de retenue autour des micro-versions. Si une broche de version compatible comme ~= 9.0.1 n'est pas suffisante pour protéger les utilisateurs contre les interruptions inattendues de la rétrocompatibilité, la seule alternative sûre qui reste est la correspondance de version simple . S'il n'y a aucune intention de prendre en charge autre chose que la correspondance de version, alors pip pourrait tout aussi bien passer à un schéma de version de style Chrome qui n'a qu'un seul composant croissant de manière monotone.

Edit : je vois que @dstufft proposait déjà d'aller dans ce sens en adoptant des versions basées sur la date. Je pense que ce serait un malheureux dommage collatéral résultant de cet incident.

Alors oui, en tant qu'utilisateurs d'un projet de logiciel dirigé par des bénévoles, nous devons équilibrer nos attentes avec une appréciation de la nature de la relation utilisateur/mainteneur. Il est également clair que cette version n'était pas destinée à faire échouer soudainement import pip . D'un autre côté, cependant, je pense qu'il est raisonnable que les gens soient frustrés par ce type de régression qui se produit dans une micro-version, et publier une version 9.0.3 qui résout le problème semble être un remède raisonnable.

En aparté, je peux reproduire cela dans un virtualenv (2 ou 3, peu importe) avec les étapes suivantes :

virtualenv -p python3 /tmp/pip
/tmp/pip/bin/pip install -e path/to/clone/of/pip/9.0.2
/tmp/pip/bin/pip install requests
/tmp/pip/bin/python

Ensuite, dans le shell python :

>>> import requests
>>> import pip

Si les requêtes n'ont pas encore été importées, alors import pip réussit.

interruptions inattendues de la rétrocompatibilité

Veuillez m'indiquer où import pip a été documenté comme étant une API stable qui relève des promesses de rétrocompatibilité que nous faisons ? Je voudrais m'assurer de supprimer cette documentation car nous ne prenons absolument pas en charge cette utilisation.

À moins que vous ne soyez d'avis qu'absolument rien ne peut casser, même des utilisations non prises en charge et non testées. Dans ce cas, vous voudrez probablement épingler == car il est totalement impossible de savoir ce que vous utilisez à ce moment-là, et chaque changement devient potentiellement un changement de rupture pour quelqu'un ( xkcd obligatoire).

pip est le gestionnaire de paquets de Python. Python est un langage de programmation. Les gens doivent inspecter leurs environnements par programmation. 1+1=2.

Il était parfaitement raisonnable pour les gens de supposer que c'était la bonne façon de procéder. Il n'y avait pas - et il n'y a toujours pas _ - quoi que ce soit dans la documentation disant _pas_ de le faire. Pour rappel, ce sont plus de 700 000 candidatures qui sont arrivées à cette même conclusion ! Aussi - il n'y a pas d'autre moyen de le faire!

Ce n'est pas parce que quelque chose n'est pas documenté dans ReadTheDocs que c'est interdit - nous rencontrons et utilisons tous les jours des projets qui fournissent simplement du code de cette façon.

Si quoi que ce soit, le fait que pip même _a_ une interface de ligne de commande semble être une bonne indication qu'il peut être utilisé comme une bibliothèque, puisqu'il a déjà un client Python !

De plus, nous ne parlons pas d'API privées avec un espace de noms _ , comme c'est la convention, ou même de toute méthode publique spécifique, nous parlons seulement de _juste appeler import_ qui provoque cet échec catastrophique.

Il n'y avait pas - et il n'y a toujours pas - quoi que ce soit dans la documentation disant de ne pas le faire.

https://pip.pypa.io/en/latest/user_guide/#using -pip-from-your-program

Si vous cliquez sur le lien "Docs" de _ce dépôt_, vous n'arrivez pas à cette page. Personne ne fait référence à la dernière. Vos propres liens vers la documentation ne renvoient pas à la dernière version. Il n'y a aucun moyen d'accéder à cette page. Tout va à stable, ce qui n'inclut pas cette section.

@Miserlou Je pense que cette note est une gentillesse pour les personnes qui pensent en quelque sorte qu'elles devraient importer les composants internes d'un outil de ligne de commande simplement parce qu'il se trouve être implémenté en Python et que ces composants internes sont importables.

Je comprends que vous avez une interprétation différente de l'interface publique de pip que moi, les développeurs et la plupart des gens qui pensent que pip est un programme CLI, mais quel est le mal réel de cela ? Épinglez simplement pip != 9.0.2 et finissez-en.

Il est évident que nous sommes tous sur la même page à ce stade quant à ce qui fait et ne fait pas partie de l'API publique prise en charge, et il n'y a rien qui puisse être fait maintenant pour avertir rétroactivement tout le monde.

Pour être honnête, les responsables de pip ont déjà déclaré que SI le temps le permet, ils essaieront de résoudre ce problème, bien que tout le monde soit encouragé à déposer une demande d'extraction pour accélérer les choses.

Je pense que pour l'instant, tout ce que nous pouvons faire est de sensibiliser les bibliothèques tierces à ce problème et de les signaler à ce problème. Les bibliothèques tierces à long terme doivent de toute façon résoudre ce problème et, espérons-le, d'une manière où elles ne import pip , mais appellent pip via la ligne de commande (avec un sous-processus ou des commandes python similaires).

Je crois que cette discussion a peu de chances d'être productive et qu'il n'y a vraiment rien d'autre à dire. Il y a:

• Une description adéquate du problème.
• Solutions de contournement possibles que quelqu'un pourrait employer s'il le rencontrait.
• Justification de la raison pour laquelle nous ne considérons pas qu'il s'agit d'un changement radical conformément à nos directives de compatibilité descendante.
• Une déclaration que je vais essayer de trouver le temps de le réparer (mais pas de promesses à ce sujet).
• Un appel à l'action que l'on peut faire si une personne affectée par cela veut rendre plus probable qu'un 9.0.3 existe avec le correctif.

À ce stade, la discussion ne sert à rien, sauf à frustrer davantage toutes les personnes impliquées, je me retire donc de ce problème pour le moment. Ce problème sera résolu soit à la sortie de la version 10.0, soit de la version 9.0.3. Si quelqu'un fait des efforts dans l'appel à l'action, il est invité à ouvrir une demande d'extraction ou à soumettre un diff sur ce problème.

Afin de rendre ce mantra ne pas importer de pip plus visible, que diriez-vous de renommer l'espace de noms en "_pip". Cela indique que l'ensemble n'est pas destiné à un usage public au niveau du nom.
De plus, il serait plus facile de dire au code d'auto-inspection de ne pas regarder les éléments commençant par un trait de soulignement. Eh bien, ce dernier aurait également besoin de changements dans le code d'inspection d'implication. Mais au moins il y a une chance d'automatiser (par convention) sans gérer les listes noires.

Ok, dernière chose que je jure - pip 10 a déjà déplacé tout le code pertinent vers pip._internal (nous n'avons pas utilisé _pip car cela casserait python -m pip , qui est pris en charge).

Quelqu'un peut-il vérifier si https://github.com/pypa/pip/pull/5100 résout ce problème pour eux ?

Grattez cela, je pense que # 5100 est faux, pourriez-vous vérifier https://github.com/pypa/pip/pull/5101 à la place s'il vous plaît.

@dstufft Je peux confirmer que le correctif de # 5101 résout le problème pour moi.

Merci @dstufft pour le temps que vous avez consacré à ce problème. Je travaillerai avec les équipes d'Anaconda pour communiquer ce problème et les aider à s'éloigner de l'importation de pip.

Pour mémoire dans ce fil, # 5101 a également résolu mon problème.

Idem, #5101 permet à l'importation de fonctionner à l'intérieur de notre outil. Caveat emptor : Je n'ai pas testé le pip patché ni notre outil de manière approfondie.

Cela devrait être corrigé dans la version 9.0.3.

Merci pour la résolution rapide, de la part de quelqu'un qui n'a jamais écrit import pip de sa vie, mais qui a été consommateur d'un paquet qui l'a fait. Après avoir lu ce fil, il semble que de nombreuses applications aient importé pip, sans le savoir contre les meilleures pratiques, et de nombreux développeurs et utilisateurs sont potentiellement affectés par v9.0.2 et v10.

Je deuxième/troisième/nième un avertissement de dépréciation approprié est ajouté pour rendre les choses plus fluides. peut-être même un article sur pypi.python.org ?

Hourra ! Merci pour cela!

J'aimerais aussi vraiment un avertissement de dépréciation et, plus important encore, des instructions appropriées sur la façon d'inspecter par programme les environnements python dans un monde pip10! Il y a clairement un besoin pour cela, étant donné que plus de 700 000 applications ont été affectées par ce bogue.

pip list --format=json ?

Tout d'abord, merci à tous ceux qui contribuent à pip car il couvre totalement tous mes cas d'utilisation avec quelques options et arguments conviviaux.

En raison de ce "comportement indéfini étonnamment largement adopté et utile" , devons-nous créer un piplib en tant que libgit2 pour git ? Veuillez noter que libgit2 ne partage aucun code avec git et est maintenu par un autre groupe de git. Et c'est bon pour l'écosystème git. Peut-être que piplib couvrira des cas d'utilisation intéressants auxquels nous ne nous attendions pas.

Voici une histoire similaire : https://public-inbox.org/git/1267957655.3759.29.camel@mattotaupa/T/

@drunkwcodes Je soupçonne que ce que vous proposez est déjà implémenté dans les packages existants mentionnés par la documentation pip , packaging , setuptools et distlib . Pour autant que je sache d'après ce fil, il n'y a pas de problème avec une lacune dans les fonctionnalités, mais certaines personnes ont des problèmes avec des outils qui tentent d'importer et d'inspecter chaque module, et traitent les échecs d'importation comme des erreurs fatales.

Il me semble que de tels outils pourraient contourner ce problème en enveloppant les instructions d'importation dans un bloc try/except, mais cela semble également être un précédent discutable à établir. Étant donné la sortie de pip 9.0.3, cependant, je pense que cela ne vaut probablement pas la peine de débattre du problème d'importation à moins que le problème ne se reproduise dans pip 10. Quoi qu'il en soit, tant que les responsables ne font pas tout leur possible pour faire import pip échouent, ou rejettent sommairement les correctifs qui corrigent de tels échecs, il y aurait un terrain d'entente sur lequel se tenir.

@sruggier Les packages mentionnés sont tous bons, et WheelFile.install() a également besoin de plus de promotion. Mais le service à guichet unique pip.main() fourni est irremplaçable avec tout ce qui précède. Cela vaut toujours la peine d'essayer.

Le plus important est que j'espère que ces besoins seront pris en charge par un autre projet, et que pip10 arrivera en douceur sans garanties supplémentaires. La dépréciation et la minimisation de la base de code sont les points entiers d'une version majeure.

Les détails concrets de mise en œuvre d'un "logiciel" d'infrastructure permanente sont ridicules. Vous ne pouvez pas juger les mainteneurs par le cas d'abus documenté et retenir la roue du pip.

Si vous insistez pour utiliser pip comme bibliothèque, de nombreuses hypothèses devront être reconsidérées.

@drunkwcodes Juste pour être clair, pip.main() est l'utilisation la plus facile à remplacer - il vous suffit d'utiliser subprocess.run([sys.executable, '-m', 'pip', <rest of args>]) .

De plus, la raison pour laquelle WheelFile.install() n'est pas promu est que le projet wheel a également déclaré qu'il ne fournissait pas d'API visible par l'utilisateur - nous avions initialement mentionné wheel dans les documents pip, mais l'avons supprimé à leur demande. Le PEP de la roue est assez clair sur la façon dont vous installez une roue, cependant - ce n'est pas difficile à implémenter dans un module tiers.

J'apprécie le travail que vous faites tous sur pip, et je sais que ce n'est pas facile. Mais pour mémoire :

Je suis un peu déçu que les gens ne se soient pas encore éloignés du pépin d'importation. Les personnes touchées par ce problème devront encore se préparer au pip 10

spaCy s'est éloigné de import pip . Mais certaines personnes utilisent toujours spaCy 1, qui a importé pip --- et pour des raisons évidentes, n'a pas associé pip à une version de correctif. Si le changement était intervenu dans la v10, nos anciennes versions n'auraient pas été affectées. Nous venons de publier un correctif pour résoudre ce problème.

instruction appropriée sur la façon d'inspecter par programme les environnements python dans un monde pip10

Quelle est la position de PyPA sur distlib ? Pip l'utilise évidemment dans une certaine mesure, mais il utilise également l'emballage, que distlib prétend déprécier.

S'il n'y a pas de position officielle, alors au moins les réflexions et opinions actuelles des principaux responsables de pip seraient très appréciées. S'il y a des discussions pertinentes sur ce sujet ailleurs, un simple pointeur vers d'autres discussions me suffit.

Je ne suis pas au courant que distlib déprécie l'empaquetage. Il mentionne "distutils2/packaging" mais distutils2 était quelque chose de différent.

Mon opinion personnelle est que distlib et l'emballage sont des choses parfaitement raisonnables à utiliser. Vous devez les évaluer vous-même pour confirmer qu'ils répondent à vos besoins, évidemment, comme toute autre dépendance sur laquelle vous comptez.

Peut-être que déprécier est un mot trop fort alors. La source de ma compréhension actuelle :

https://distlib.readthedocs.io/en/latest/overview.html#distlib -evolved-out-of-packaging

Ah, c'est un "packaging" différent - c'était le module stdlib proposé qui était destiné à remplacer distutils. C'est complètement différent du projet PyPI packaging . Il pourrait être utile de demander au projet distlib de clarifier un peu mieux cette distinction.

Il pourrait être utile de demander au projet distlib de clarifier un peu mieux cette distinction.

Déjà fait :) Voir : https://bitbucket.org/pypa/distlib/issues/100/clarify-project-positioning-and-status

Ce fil a été automatiquement verrouillé puisqu'il n'y a eu aucune activité récente après sa fermeture. Veuillez ouvrir un nouveau problème pour les bogues associés.