Pip: Error con `importar pip` en pip 9.0.2

Puedo confirmarlo también. A punto de presentar el mismo problema.

Este es un engaño de #5079: importar pip no es un caso de uso admitido (y nunca lo ha sido).

Vamos... ¿haciendo un cambio radical enorme en un solo aumento de versión x.x.PATCH ? ¿Para un método de nivel superior que se llama "principal"? Creo que es una forma bastante pobre ...

Esto también rompió Anaconda y se me ocurrió la misma solución que @Miserlou :

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

Se informan errores en muchos proyectos.

Este error también me molestó cuando intentaba usar pip para actualizar mi anaconda-navigator.

¿Hay alguna posibilidad de que obtengamos una versión 9.0.3 que solucione esto, idealmente muy pronto?

Esto ya está afectando a muchos proyectos importantes (Anaconda, SpaCy, Zappa), y hay más de 850 000 usos de esto solo en GitHub que ahora están interrumpidos por esta supuesta actualización de versión de "parche".

¿Puede al menos revertir este cambio masivo en 9.0.3 y luego _anunciar_ a los usuarios posteriores su intención de cambiar este comportamiento para una futura versión 10.xx o al menos 9.xx?

Tampoco queremos usar una versión anterior, pero eso es exactamente lo que terminamos haciendo. 9.0.2 no existe dentro de nuestro entorno de CI, al menos por ahora.

También viendo este éxito en algunos proyectos de OpenStack.

Pip 10 saldrá en aproximadamente un mes. Según tengo entendido, el problema es con el código que usa import pip para acceder a la funcionalidad interna de pip. Nunca hemos admitido oficialmente dicho uso y hemos documentado explícitamente esa falta de compatibilidad desde hace algún tiempo (aunque solo en la versión "más reciente" de los documentos en https://pip.pypa.io/en/latest/user_guide /#using-pip-from-your-program, porque no hemos tenido una nueva versión estable desde que se agregó esa sección de documentación). También anunciamos una reorganización de las partes internas para dejar en claro que el uso de API internas no es compatible en octubre pasado (ver https://mail.python.org/pipermail/distutils-sig/2017-October/031642.html). Ese cambio, que está en el pip 10, interrumpirá cualquier uso de este tipo, independientemente del pip que haría una posible versión de pip 9.0.3. Así que es difícil ver esto como una ruptura repentina e inesperada.

Si @dstufft quiere hacer un lanzamiento de emergencia 9.0.3, estoy de acuerdo con eso. Pero solo será un beneficio a muy corto plazo, y estoy un poco decepcionado de que la gente aún no se haya alejado de import pip . Las personas afectadas por este problema aún deberán prepararse para pip 10, y deben comprender que simplemente cambiar a import pip._internal no es algo que apoyaremos ni recomendaremos.

Las propuestas para reintroducir cierto nivel de soporte de API son ciertamente una opción (ver #5080 por ejemplo) pero en esta etapa, es demasiado tarde para que tales cambios lleguen al pip 10.

Sin advertencias emitidas por el código para aquellos que usan la forma anterior, nada que denote esto como "interno" al comenzar con _, y esto solo es un problema de corrección de errores, en realidad creo que es bastante fácil ver esto como una rotura repentina e inesperada. .

Sí, este es el tipo de cambio que la gente podría esperar de una actualización de la versión MAJOR . Eso estaría bien.

Desafortunadamente, este cambio masivo llegó en una actualización PATCH , que _se supone que arregla las cosas, no las rompe_. Esto es exactamente lo contrario de la versión semántica. Y, como resultado, estamos viendo daños masivos en todo el ecosistema de Python.

Debe revertir este cambio lo antes posible en otra actualización PATCH y, a continuación, hacer que el cambio más importante venga con la actualización de la versión MAJOR . Ahora que ya rompiste todo prematuramente para todos, creo que estarán más conscientes de que se avecina un gran cambio real.

También creo que es un engaño decir que esto ya fue documentado y anunciado, considerando que _no_ estaba documentado en la documentación estable , y que el anuncio decía que la ruptura ocurriría _para la versión principal_, no en un parche de un mes. previo.

Por favor, ahorre a todos un gran dolor de cabeza, revierta este problema y comience a adherirse a las versiones semánticas.

@Miserlou OK, entiendo tu punto: apuntamos al cambio de nombre interno para pip 10 porque es una versión principal. Realmente no conozco los controladores para el lanzamiento del parche: @dstufft me envió un ping al respecto y aparentemente es para evitar una ruptura significativa para los usuarios de Mac OS cuando nos llega una fecha límite inminente para el soporte de TLS, que es antes del lanzamiento de pip 10. Esperábamos que los problemas fueran lo suficientemente importantes como para justificar el lanzamiento de un parche a corto plazo. Ciertamente no había intención de romper el uso existente.

Tengo que dejar la decisión de un seguimiento 9.0.3 a @dstufft . No tengo los detalles de lo que pasó en 9.0.2 ni sé si es posible identificar cómo solucionar este problema. Y no puedo juzgar si sacar 9.0.2 por completo será un beneficio general, ya que no tengo idea de cuántas personas se ven afectadas por el problema de Mac OS. Entiendo que (al menos para algunas personas) fijar a 9.0.1 es una solución, por lo que puede terminar siendo la opción menos mala.

El problema de macOS TLS afectará a todos los que usen un sistema Python en macOS <10.13

Tengo que dejar la decisión de un seguimiento 9.0.3 a @dstufft

Estoy en la misma posición que @pfmoore.

La solución alternativa, si la tiene disponible, es verificar el orden de las importaciones y probar mover la importación de pip por encima de otras importaciones de paquetes (específicamente, importar pip _antes_ de las solicitudes de importación parece resolver algunos casos). (Tenga en cuenta que esto aún implica el uso de las funciones internas de pip, que no se admite oficialmente).

Mismo problema aquí con pip 9.0.2 en un gitlab-ci con 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'

FYI, 9.0.2 se lanzó con compilaciones rotas:

Referencia de Travis-CI: https://travis-ci.org/pypa/pip/builds/354616774?utm_source=github_status&utm_medium=notification

De acuerdo, los errores pueden no estar relacionados, aunque esto simplemente huele a "lanzamiento apresurado"...

@pfmoore

Si @dstufft quiere hacer un lanzamiento de emergencia 9.0.3, estoy de acuerdo con eso. Pero solo será un beneficio a muy corto plazo, y estoy un poco decepcionado de que la gente aún no se haya alejado del pip de importación. Las personas afectadas por este problema aún deberán prepararse para pip 10, y deben comprender que simplemente cambiar a import pip._internal no es algo que apoyaremos o recomendaremos.

No puedo creer que esta sea una declaración del propietario de este repositorio... Literalmente acabas de decir "a la mierda las versiones semánticas" y "quién necesita una política de obsolescencia de todos modos".

siempre se documentó que pip NO tenía una API de python consumible, estoy decepcionado con las personas que, incluso en ese momento, intentan cambiar el karma de "te lo dije desde hace bastantes años".

@RonnyPfannschmidt Esto es como decir "Le dijimos 100 veces que no puede conducir por encima del límite de velocidad" y luego hacer cumplir el límite de velocidad reemplazando todos los autos con motor por autos de pedernal, para que la gente no pueda pasar el límite de velocidad nunca más.

Acabas de demostrar perfectamente que cambiar las palabras es tan malo: el dicho fue "no confíes en que se romperá". Ahora se rompió y, de repente, el proyecto que te dijo antes que se romperá tiene la culpa.

que solo echas la culpa porque no te gusta tener la culpa

@RonnyPfannschmidt

que solo echas la culpa porque no te gusta tener la culpa

Por lo tanto, está diciendo que tengo la culpa de usar paquetes de terceros que se basan en una característica no documentada de pip. Tal vez, lo estoy... Debí haber examinado esos paquetes de terceros para detectar esos errores y haber enviado un problema o, mejor aún, un PR.

Pero afrontemos la realidad: hay muchos proyectos que se utilizan en la producción que ahora están rotos. Esta no es una cuestión de moral, no es una cuestión de culpa de quién es. Es una cuestión de "¿puede arreglar esto y proporcionar una advertencia/desaprobación adecuada".

Si un paquete de terceros que usa se rompe porque se basa en API internas no documentadas y no garantizadas, me parece que debe informar un error en ese paquete.

Hay una línea fácil de descubrir entre qué partes de pip están y no están destinadas al consumo de terceros, y no apoyo tratar de obligar a sus desarrolladores a mantener API internas que nunca deberían haber sido consumidos por paquetes de terceros. No apoyo tratar esto como culpa de los desarrolladores de pip y enviar usuarios enojados a su manera. Si quiere enojarse con alguien, enójese con cualquier paquete que use que dependa de API internas y presione para que sus mantenedores arreglen su propio código.

@anx-ckreuzberger

No puedo creer que esta sea una declaración del propietario de este repositorio... Literalmente acabas de decir "a la mierda las versiones semánticas" y "quién necesita una política de obsolescencia de todos modos".

Si bien entiendo la frustración aquí, me molesta cada vez más la disposición de las personas a culpar a los mantenedores de pip por cosas que nunca prometimos.

Si quieres hacer acusaciones como esa, por favor respaldalas con

1. Un puntero a una declaración de cualquiera de los mantenedores de pip que admitimos el uso de la API interna de pip en el código de usuario.
2. Un puntero a una declaración de cualquiera de los mantenedores de pip que pip utiliza versiones semánticas.

No creo que encuentres esa evidencia...

Por lo tanto, está diciendo que tengo la culpa de usar paquetes de terceros que se basan en una característica no documentada de pip.

No, pero no es aceptable acusar a los mantenedores de pip en lugar de a esos proyectos. Estamos tratando de ayudarlo, pero no podemos responsabilizarnos por lo que hacen esos proyectos. Exprese sus quejas con ellos.

Pero afrontemos la realidad: hay muchos proyectos que se utilizan en la producción que ahora están rotos. Esta no es una cuestión de moral, no es una cuestión de culpa de quién es. Es una cuestión de "¿puede arreglar esto y proporcionar una advertencia/desaprobación adecuada".

Intentamos proporcionar una advertencia. Enviamos anuncios hace meses , agregamos documentos que explican la situación y respondimos constantemente a los problemas en el rastreador que indican que el uso de API internas no es compatible. Agregar obsolescencias está lejos de ser tan fácil como usted sugiere, ya que pip en sí arrojaría esas advertencias (o habría una manera de que pip las desactive, lo que otros simplemente copiarían; ya estamos escuchando de personas que planean simplemente import pip._internal , por lo que incluso ese cambio no los detendrá: decepcionados :).

En cuanto a "arreglar" esto, admitiré felizmente que 9.0.2 se lanzó rápidamente para abordar un problema urgente, y no anticipamos este problema. Tal vez lanzar un 9.0.3 con una vida útil de 2 a 3 semanas sea algo razonable, yo no lo creo, pero he dicho que lo consideraremos. Personalmente , no puedo aceptar hacerlo, ya que no soy el que está involucrado en los lanzamientos de 9.0.x. Estoy trabajando en el pip 10, lo que hará que todo este debate sea irrelevante, por lo que es probable que esta sea mi última palabra sobre este tema: necesito concentrarme en las cosas relacionadas con ese lanzamiento.

Mi consejo personal:

1. Fije a 9.0.1 si se ve afectado por esto y necesita una solución ahora .
2. Esté preparado para pip 10, cuando todas las dependencias que tiene actualmente que están rotas porque usan API internas de pip se romperán nuevamente. Empuje esas dependencias para que tomen medidas sobre la información que hemos estado brindando durante meses, y alégrese de haber recibido una advertencia anticipada de que sucedería.
3. Si se libera pip 9.0.3, retire el pin.
4. Por favor , pruebe la versión beta de pip 10 cuando salga e informe cualquier problema a las partes relevantes (proyectos de terceros si llaman a pip internamente, nosotros si llama a pip usted mismo).

Experimenté el mismo problema con pip 9.0.2 y Python 2.7.14 dentro de un contenedor docker.
Sin embargo, no puedo reproducir el problema en mi máquina de desarrollo fuera de un contenedor acoplable.
Busqué una importación de pip (grep'd para import.pip , from.pip , \'pip , \"pip ) pero no pude encontrar nada.
En Plone estamos usando un mecanismo para incluir automáticamente configuraciones de paquetes incluidos en un archivo setup.py de setuptools, lo que suena sospechoso, pero nuevamente, este solo usa __import__ y nada de pip AFAIcansee.

Esta es la parte relevante del rastreo:

  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'

Por lo que entiendo, solo importando pip, sin usarlo, ya se rompe. Este no es un buen comportamiento ciudadano en la tierra de Python. No admitir su uso / no proporcionar una API pública es una cosa, simplemente interrumpir la importación es otra. Esto afecta una gran cantidad de código de inspección automática.

Piénselo de esta manera: pip es una utilidad de línea de comandos, no una biblioteca. El hecho de que esté escrito en Python es irrelevante. Esa es la realidad del asunto.

@pfmoore

Si bien entiendo la frustración aquí, me molesta cada vez más la disposición de las personas a culpar a los mantenedores de pip por cosas que nunca prometimos.

Piénselo de esta manera: pip es una utilidad de línea de comandos, no una biblioteca. El hecho de que esté escrito en Python es irrelevante. Esa es la realidad del asunto.

La conclusión es que realmente no importa lo que prometiste. Lo que importa es lo que hiciste y cuál es la situación resultante. Tal vez lo pensó como una utilidad de línea de comandos. Pero lo lanzaste como una biblioteca. Esa es la realidad del asunto:

Has lanzado una biblioteca con Feature X. La gente comenzó a usar Feature X. Claro, dijiste "chicos, por favor no usen Feature X". Pero seguiste publicándolo con Feature X. Durante años. Y así la gente siguió usándolo. Decenas, quizás cientos, de miles de proyectos, grandes y pequeños, utilícenlo ahora. De repente, lo elimina en una actualización menor sin la advertencia adecuada.

¿Qué crees que pase después?

En el corto plazo, las personas simplemente anclarán la versión anterior y no la quitarán a menos que haya una buena razón.

A largo plazo... bueno, depende de cuántas personas decidan que sería más rentable reemplazarlo que arreglar todo lo que ha roto.

@pfmoore , ¿ve algo sospechoso en el rastreo que mencioné anteriormente? No hay uso de ningún pip interno AFAIK. Es interesante que la mayoría de las personas tengan este problema dentro de los contenedores docker.

@ todos, acusar a los mantenedores de código roto no ayuda a resolver el problema.

Piénselo de esta manera: pip es una utilidad de línea de comandos, no una biblioteca. El hecho de que esté escrito en Python es irrelevante. Esa es la realidad del asunto.

Hecho: No se puede importar, si se importa incluso mediante el código de inspección automática por alguna razón: todos los descansos. Supongo que esto sucede en el caso de @thet .
Conclusión: pip debe aislarse del espacio de nombres global o actual de Python virtualenv/venv en el que instala los paquetes. De esa manera no lo contamina y ni siquiera ocurre la importación por accidente.

En primer lugar, lo siento si acusé a los mantenedores del repositorio por código defectuoso. Cualquier acusación se hizo por frustración y, en todo caso, apunta al hecho de que, en mi humilde opinión, la versión 9.0.2 es, por definición, semver, una versión de parche (aunque @pfmoore dejó en claro que pip no necesariamente usa semver, que es otro tema para otro día supongo).

@MikeHart85

En el corto plazo, las personas simplemente anclarán la versión anterior y no la quitarán a menos que haya una buena razón.
A largo plazo... bueno, depende de cuántas personas decidan que sería más rentable reemplazarlo que arreglar todo lo que ha roto.

bastante Me refiero a mirar a los administradores de paquetes de JavaScript: npm, bower, yarn, lo que se publique el próximo ~ año ~ semana

No, pero no es aceptable acusar a los mantenedores de pip en lugar de a esos proyectos. Estamos tratando de ayudarlo, pero no podemos responsabilizarnos por lo que hacen esos proyectos. Exprese sus quejas con ellos.

Entiendo que mis (¿nuestras?) quejas en relación con este problema podrían estar mal dirigidas. Aunque debe admitir que es muy difícil convencer a alguien de que esto es culpa de los mantenedores de terceros.

Intentamos proporcionar una advertencia. Enviamos anuncios hace meses, agregamos documentos que explican la situación

¿Fue esto para pip 9.0.2 o para pip 10? Si fuera para pip 9.0.2, me parecería bien si hubiera una nota en el registro de cambios . De todos modos, gracias por ser muy proactivo en el desarrollo de pip 10 y enviar anuncios sobre no usar import pip , ¡eso es bueno! ¡Seguid así!

Agregar obsolescencias está lejos de ser tan fácil como usted sugiere, ya que pip en sí arrojaría esas advertencias (o habría una manera de que pip las desactive, lo que otros simplemente copiarían; ya estamos escuchando de personas que planean simplemente import pip._internal, por lo que incluso ese cambio no los detendrá decepcionados).

No creo que esto sea demasiado difícil... Ya tienes esto en el __init__.py :

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

¿Qué tal si simplemente agregamos un else?

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")

editar : incluso puede generar una excepción aquí si desea ser "estricto" al respecto y agregar declaraciones similares a los submódulos.

El hecho de que la gente solucione esto es otra cosa. Si desea piratear una biblioteca, siempre puede aplicarle ingeniería inversa. Siempre puedes encontrar una manera de evitarlo. Pero no debe considerar todas las formas a su alrededor dentro de sus decisiones de diseño.

A largo plazo... bueno, depende de cuántas personas decidan que sería más rentable reemplazarlo que arreglar todo lo que ha roto.

Siempre encuentro divertida esta "amenaza". Viene con un malentendido fundamental sobre la cantidad de esfuerzo que se pone en algo como pip y cuánto cuesta realmente (y lo poco que la gente está dispuesta a pagar por ello). Si sientes que puedes hacerlo mejor, entonces hazlo por todos los medios, yo (y supongo que los demás) lo agradecemos. Una cantidad de esfuerzo no trivial en los últimos años ha sido documentar y diseñar estándares con uno de los objetivos explícitos de hacer posible que tal cosa suceda.

Es importante mantener un sentido de perspectiva sobre estas cosas. Hay.. menos de 15? 20? personas comentando cómo esto los rompió (aunque siempre hay un problema de "punta del iceberg" con estas métricas), mientras tanto, pip 9.0.2 ya es el segundo instalador más utilizado en la última semana (contando los días que ni siquiera ha existido for) y ha descargado 17 millones de archivos de PyPI desde su lanzamiento. Mirando solo el último día, es el 80% del camino para superar a pip 9.0.1 como el instalador más utilizado en PyPI.

Entonces, aunque reconozco que esto rompió las cosas para algunas personas, es un número relativamente pequeño de personas que hacen cosas sin soporte o en situaciones bastante extremas.

SI puedo encontrar el tiempo, puedo intentar cortar un 9.0.3, principalmente para resolver el caso en el que @thet se ha topado donde es solo un importador automático que intenta importar cosas, y en realidad no están tratando de usar las API internas de pip de ninguna manera. Si eso también termina resolviendo el comportamiento de las personas que usan las API internas de pip, no me esforzaré por romperlas específicamente, pero si no es así, tampoco me esforzaré por solucionarlo. ellos específicamente tampoco.

Tenga en cuenta que lleva muchas horas lanzar un 9.0.x en este punto (las cosas han divergido en master lo suficiente como para que se requiera un poco de esfuerzo para hacer un lanzamiento) y eso no cuenta el tiempo requerido para depurar y solucionar el problema real. Si desea aumentar las posibilidades de que esto suceda, la mejor manera de hacerlo es depurar, corregir y proporcionar un parche (o una rama de la etiqueta 9.0.2 en su propia bifurcación).

En primer lugar, lo siento si acusé a los mantenedores del repositorio por código defectuoso. Cualquier acusación fue hecha por frustración.

Gracias. La frustración es alta aquí, y lo entiendo.

¿Qué tal si simplemente agregamos un else?

Buena idea. Ojalá hubiéramos pensado en esto hace algún tiempo. Por supuesto, no tiene sentido ahora, ya que el espacio de nombres interno se reorganizará en el pip 10, por lo que es demasiado tarde. Ciertamente recordaré este truco para el futuro.

¿Fue esto para pip 9.0.2 o para pip 10?

Para 10.0. No había ninguna intención original de lanzar 9.0.2, solo lo hicimos como un lanzamiento de emergencia para que los usuarios de Mac OS no perdieran todo el acceso a PyPI cuando los cambios de TLS entren en vigencia.

@dstufft ha respondido aquí de manera mucho más completa, por lo que creo que esto está tan resuelto como es probable que esté por ahora.

Siempre encuentro divertida esta "amenaza".

No es una amenaza en absoluto, disculpas si se presentó de esa manera.

Es una observación sobre algo que ocurre con demasiada frecuencia en el mundo del software. La gente no trabaja con tus promesas o intenciones. La gente trabaja con el producto que entregas. Si su producto tiene una característica de la que muchas personas dependen, ya no puede simplemente quitársela de debajo de los pies. Si lo hace, comenzarán a ver su producto como roto. Si la única explicación que proporcionas es "bueno, nunca prometimos esto de todos modos", entonces comenzarán a ver tu falta de voluntad para reconocer sus preocupaciones como una responsabilidad.

Cuanto más sucede esto, mayor es el deseo y la demanda de una alternativa. Claro, la gente subestima la cantidad de trabajo que lleva. Pero eso solo los hace más , no menos, propensos a comenzar a trabajar en uno. Una vez que la bola está rodando, tiene vida propia.

Las alternativas no siempre son buenas. Tienden a ensuciar las cosas. Personalmente, prefiero un solo administrador de paquetes. Para todo. Pero me conformaré con un solo administrador de paquetes para Python.

Cuando las personas informen que rompiste una función, intencionalmente o no, considera explicar brevemente por qué tuviste que romperla o por qué mantenerla no era viable, en lugar de descartar las preocupaciones con "esto no fue compatible todo el tiempo".

Hola @dstufft , gracias por participar. ¡Este hilo se está poniendo muy caliente!

En primer lugar, ¡gracias por tu trabajo! Sé que el mantenimiento es una tarea interminable e ingrata, y me imagino que solo empeora cuando administras un proyecto tan grande y popular como pip .

Ahora, al problema que nos ocupa: aunque veinte _mantenedores_ han informado este problema hasta ahora, sé que ya está afectando a miles de _personas_; algunos de los proyectos afectados son masivos por derecho propio: Anaconda, OpenStack, SpaCy, Zappa y tienen muchas decenas de miles de usuarios. Sé que nuestro canal de Slack está inundado de discusiones sobre esto. (Literalmente, mientras escribía esto, apareció un nuevo problema).

Claramente, hay muchos proyectos importantes de Python que necesitan la capacidad de inspeccionar sus entornos mediante programación. Esta es una cosa totalmente razonable que necesita ser capaz de hacer. Además, la documentación nunca advirtió contra hacer esto , ¡y todavía no lo hace! (¡Haga clic en el enlace Documentos del LÉAME de este repositorio!)

Creo que la situación hasta ahora es:

• Dado el formato de la cadena de versión, todos creíamos que los mantenedores de pip están siguiendo el control de versiones semántico
• Los mantenedores de pip lanzaron un "parche" que introdujo un cambio masivo
• Este cambio no fue anunciado ni documentado, y supongo que inesperado e involuntario.
• Ahora, simplemente llamando a import pip inmediatamente rompe un programa, que es extremadamente hostil al desarrollador
• Esto está causando grandes dolores de cabeza en todo el ecosistema de Python.
• La documentación no advierte (y _todavía no lo hace, haga clic en el enlace Docs en el LÉAME de este repositorio) contra el uso pip mediante programación.
• No hubo ningún anuncio de que import pip causaría este daño en una actualización PATCH ; ese anuncio se produjo para una versión que _aún no se ha lanzado_.
• Este cambio ni siquiera se mencionó en el registro de cambios.
• ¡No queremos reemplazar a pip ni a los desarrolladores de pip! ¡Te amamos!
• ..pero no queremos que este tipo de cosas vuelvan a suceder!
• ..entonces queremos que semver sea seguido!
• ¡Realmente nos gustaría otro PATCH que deshaga este gran cambio!

La necesidad de una forma programática de inspeccionar un entorno en un mundo pip>=10.0.0 es un tema para otra discusión, pero el hecho es que nunca nos dijeron que no deberíamos usar pip mediante programación en el pip. <=9 mundo, y hubo un cambio masivo, no anunciado, y realmente nos gustaría verlo al revés porque está afectando negativamente a miles de personas.

Gracias de nuevo,
Rico

En primer lugar: gracias a los mantenedores de pip por sus esfuerzos y los conocimientos dentro del proyecto. Creo que esto realmente ayuda a otros a comprender el problema (aunque podría valer la pena escribir un artículo de blog resumido al respecto).

@dstufft

Es importante mantener un sentido de perspectiva sobre estas cosas. Hay.. menos de 15? 20? personas comentando cómo esto los rompió (aunque siempre hay un problema de "punta del iceberg" con estas métricas), mientras tanto, pip 9.0.2 ya es el segundo instalador más utilizado en la última semana (contando los días que ni siquiera ha existido for) y ha descargado 17 millones de archivos de PyPI desde su lanzamiento. Mirando solo el último día, es el 80% del camino para superar a pip 9.0.1 como el instalador más utilizado en PyPI.

Estoy bastante seguro de que la métrica está muy sesgada por todos los comandos pip install pip --upgrade automatizados de los sistemas de integración/entrega continua (deberían usar cachés y, por lo tanto, no es necesario volver a instalar paquetes desde pypi todo el tiempo; pero al al mismo tiempo, uno tampoco debe hacer import pip ... así es como funciona el mundo de TI).

El hecho de que (menos de) 15 personas se hayan quejado de esto debería mostrar dos cosas:

1. No creo que mucha gente use 9.0.2 (en producción) todavía, algunos todavía pueden estar tratando de depurar este problema y lo arreglarán "temporalmente" usando pip 9.0.1 hasta que se resuelva (o para siempre). .) - Además, es posible que algunas personas no se hayan dado cuenta de que algo aún no funciona...
2. Hay personas que ya hablan de ello dentro de los 2 días posteriores al lanzamiento. Más personas experimentarán este problema. Espere 2 semanas y podría terminar con 100 personas que se quejan (por ejemplo, cuando terminan un sprint y se implementan en QA/staging). En este momento, realmente no sabe cuántas personas se verán afectadas por este cambio.

De todos modos, hablar y discutir sobre este tema les da a las personas un buen ejemplo de por qué uno nunca debe confiar en las API internas y, con suerte, algunos mantenedores de paquetes de terceros actualizarán sus proyectos debido a lo que se ha hablado aquí.

Claramente, hay muchos proyectos importantes de Python que necesitan la capacidad de inspeccionar sus entornos mediante programación. Esta es una cosa totalmente razonable que necesita ser capaz de hacer. Además, la documentación nunca advirtió contra hacer esto, ¡y todavía no lo hace! (¡Haga clic en el enlace Documentos del LÉAME de este repositorio!)

No me queda claro por qué tendría que advertir contra esto. El uso de pip como cualquier otra cosa que no sea una herramienta de línea de comandos está completamente sin documentar . Al buscar en la documentación, no veo ninguna referencia a la importación de pip. Es como quejarse porque vinculaste algunos .so usados ​​por Chrome y rompieron la compatibilidad con ABI.

La interpretación habitual de SemVer es que se aplica a la interfaz pública admitida (en este caso, la CLI), no a las partes internas no documentadas. Cualquiera que use las partes internas debería fijar sus versiones pip todos modos , ya que están sujetas a cambios arbitrarios.

No hay nada que revertir realmente. Las correcciones de backporting para evitar que una parte significativa de los usuarios de macOS no puedan acceder a PyPI en un futuro cercano tiene un error cuando se aplica a la base de código 9.0.x que parece expresarse solo en condiciones no admitidas. El único camino a seguir es hacer trabajo adicional para resolver ese error en la serie 9.0.x. Como dije, si puedo encontrar tiempo, intentaré hacerlo, si desea aumentar las posibilidades de que suceda, proporcione un parche.

La documentación no advierte contra esto porque no es posible proporcionar una lista exhaustiva de las cosas que podría hacer con pip pero que no son compatibles. En cambio, confiamos en el enfoque bastante común de documentar lo que se admite y se debe suponer que todo lo que no está documentado no se admite (y si desea confiar en algo que no está documentado, abrir un problema solicitando que se documente y, por lo tanto, se admita ).

A más largo plazo, es probable que avancemos hacia un esquema de lanzamiento basado en la fecha para (con suerte) eliminar cualquier confusión sobre si somos semver o no.

Enviado desde mi iPhone

El 20 de marzo de 2018, a las 11:02 a. m., Rich Jones [email protected] escribió:

Hola @dstufft , gracias por participar. ¡Este hilo se está poniendo muy caliente!

En primer lugar, ¡gracias por tu trabajo! ¡Sé que el mantenimiento es una tarea interminable e ingrata, y me imagino que solo empeora cuando administras un proyecto tan grande y popular como pip!

Ahora, al problema que nos ocupa: aunque veinte mantenedores han informado este problema hasta ahora, sé que ya está afectando a miles de personas: algunos de los proyectos afectados son masivos por derecho propio: Anaconda, OpenStack, SpaCy, Zappa y tienen muchas decenas de miles de usuarios. Sé que nuestro canal de Slack está inundado de discusiones sobre esto. (Literalmente, mientras escribía esto, apareció un nuevo problema).

Claramente, hay muchos proyectos importantes de Python que necesitan la capacidad de inspeccionar sus entornos mediante programación. Esta es una cosa totalmente razonable que necesita ser capaz de hacer. Además, la documentación nunca advirtió contra hacer esto, ¡y todavía no lo hace!

Creo que la situación hasta ahora es:

Dado el formato de la cadena de versión, todos creíamos que los mantenedores de pip están siguiendo el control de versiones semántico
Los mantenedores de pip lanzaron un "parche" que introdujo un cambio masivo
Este cambio no fue anunciado ni documentado, y supongo que inesperado e involuntario.
Ahora, simplemente llamar a import pip rompe inmediatamente un programa, lo cual es extremadamente hostil para el desarrollador.
Esto está causando grandes dolores de cabeza en todo el ecosistema de Python.
La documentación no advierte (y aún no lo hace, haga clic en el enlace Docs en el LÉAME de este repositorio) contra el uso de pip mediante programación.
No hubo ningún anuncio de que import pip causaría este daño en una actualización de PATCH; ese anuncio se produjo para una versión que aún no se ha lanzado.
Este cambio ni siquiera se mencionó en el registro de cambios.
¡No queremos reemplazar a pip ni a los desarrolladores de pip! ¡Te amamos!
..pero no queremos que este tipo de cosas vuelvan a suceder!
..entonces queremos que semver sea seguido!
¡Realmente nos gustaría otro PARCHE que deshaga este gran cambio!
La necesidad de una forma programática de inspeccionar un entorno en un mundo pip>=10.0.0 es un tema para otra discusión, pero el hecho es que nunca nos dijeron que no deberíamos usar pip mediante programación en el pip. <=9 mundo, y hubo un cambio masivo, no anunciado, y realmente nos gustaría verlo al revés porque está afectando negativamente a miles de personas.

Gracias de nuevo,
Rico

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub o silencie el hilo.

@miserlou

Dado el formato de la cadena de versión, todos creíamos que los mantenedores de pip están siguiendo el control de versiones semántico

Como alguien que se opone firmemente a semver, ¿puede decirme en qué formato deberían estar las cadenas de mi versión para eliminar esta confusión? "Tres números punteados" no implica que "siga estrictamente a semver", por lo que esta suposición me sorprende.

En respuesta a este comentario : Ya sea que pip se adhiera o no a semver, o prometa adherirse a él, el uso de un esquema de versiones major.minor.micro todavía conlleva una promesa implícita de algún tipo de restricción en torno a los micro lanzamientos. Si un pin de lanzamiento compatible como ~= 9.0.1 no es suficiente para proteger a los usuarios de interrupciones inesperadas en la compatibilidad con versiones anteriores, la única alternativa segura que queda es la coincidencia de versión simple. Si no hay intención de admitir nada más que la coincidencia de versiones, entonces pip también podría cambiar a un esquema de versión de estilo Chrome que tiene solo un componente que aumenta monótonamente.

Editar: Veo que @dstufft ya propuso moverse en esta dirección al adoptar versiones basadas en fechas. Creo que sería un desafortunado daño colateral como resultado de este incidente.

Así que sí, como usuarios de un proyecto de software impulsado por voluntarios, debemos equilibrar nuestras expectativas con una apreciación de la naturaleza de la relación usuario/mantenedor. También está claro que esta versión no tenía la intención de hacer que import pip repente comenzara a fallar. Sin embargo, por otro lado, creo que es razonable que la gente se sienta frustrada por este tipo de regresión que ocurre en una versión micro, y lanzar una versión 9.0.3 que soluciona el problema parece un remedio razonable.

Aparte, puedo reproducir esto en un virtualenv (2 o 3, no importa) con los siguientes pasos:

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

Luego, dentro del shell de python:

>>> import requests
>>> import pip

Si las solicitudes aún no se han importado, entonces import pip tiene éxito.

interrupciones inesperadas en la compatibilidad con versiones anteriores

Indíqueme dónde se documentó import pip como una API estable que cumple las promesas de compatibilidad con versiones anteriores que hacemos. Me gustaría asegurarme de eliminar dicha documentación ya que enfáticamente no apoyamos ese uso.

A menos que sea de la opinión de que absolutamente nada puede fallar, incluso los usos no probados y sin soporte. En cuyo caso, probablemente desee anclar == porque es completamente desconocido qué es lo que puede estar usando en ese momento, y cada cambio se convierte potencialmente en un cambio importante para alguien ( xkcd obligatorio).

pip es el administrador de paquetes de Python. Python es un lenguaje de programación. Las personas necesitan inspeccionar sus entornos programáticamente. 1+1=2.

Era perfectamente razonable que la gente supusiera que esta era la forma correcta de hacerlo. No había, y todavía no hay , nada en la documentación que diga _no_ hacer esto. Como recordatorio, ¡hay más de 700.000 solicitudes que llegaron a esta misma conclusión ! Además, ¡no hay otra manera de hacerlo!

El hecho de que algo no esté documentado en ReadTheDocs no significa que esté prohibido: todos nos encontramos y usamos proyectos todos los días que simplemente proporcionan código de esta manera.

En todo caso, el hecho de que pip incluso _tenga_ una interfaz de línea de comandos parece ser una buena indicación de que se puede usar como biblioteca, ¡ya que ya tiene un cliente de Python!

Además, no estamos hablando de API privadas con un espacio de nombres _ , como es la convención, ni siquiera de ningún método público específico, solo estamos hablando de _simplemente llamar a import_ que causa esta falla catastrófica.

No había, y todavía no hay, nada en la documentación que diga que no se debe hacer esto.

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

Si hace clic en el enlace "Documentos" de _este mismo repositorio_, no accederá a esa página. Nadie hace referencia a la última. Sus propios enlaces a la documentación no enlazan con la última. No hay manera de llegar a esa página. Todo va al establo, que no incluye ese apartado.

@Miserlou Creo que esa nota es una amabilidad para las personas que de alguna manera piensan que deberían importar las partes internas de una herramienta de línea de comandos solo porque está implementada en Python y esas partes internas son importables.

Entiendo que tiene una interpretación diferente de la interfaz pública de pip que yo, los desarrolladores y la mayoría de las personas que piensan en pip como un programa CLI, pero ¿cuál es el daño real de esto? Solo fija pip != 9.0.2 y listo.

Es obvio que todos estamos en la misma página en este punto en cuanto a lo que es y no es parte de la API pública admitida, y no hay nada que se pueda hacer ahora para avisar a todos de manera retroactiva.

Para ser honesto, los mantenedores de pip ya declararon que SI el tiempo lo permite, intentarán solucionar este problema, aunque se alienta a todos a presentar una solicitud de extracción para acelerar las cosas.

Creo que por ahora todo lo que podemos hacer es hacer que las bibliotecas de terceros sean conscientes de este problema y señalarles este problema. Las bibliotecas de terceros a largo plazo deben solucionar este problema de todos modos y, con suerte, de una manera en la que no import pip , sino que llamen a pip a través de la línea de comandos (con subprocesos o comandos similares de python).

Creo que es poco probable que esta discusión sea productiva ni hay nada más que decir. Hay:

• Una descripción adecuada del problema.
• Posibles soluciones alternativas que alguien podría emplear si se encuentra con él.
• Justificación de por qué no consideramos que esto sea un cambio importante según nuestras pautas de compatibilidad con versiones anteriores.
• Una declaración de que intentaré encontrar tiempo para arreglarlo (aunque no hay promesas al respecto).
• Se puede hacer una llamada a la acción si alguien afectado por esto quiere que sea más probable que exista un 9.0.3 con la corrección.

En este punto, la discusión no tiene ningún propósito real, excepto frustrar aún más a todos los involucrados, por lo que me retiro de este tema por ahora. Este problema se cerrará con el lanzamiento de 10.0 o 9.0.3. Si alguien se esfuerza en la llamada a la acción, puede abrir una solicitud de extracción o enviar una diferencia sobre este problema.

Para hacer que este mantra de no importar pip sea más visible, ¿qué tal cambiar el nombre del espacio de nombres a "_pip"? Esto indica que el todo no es para uso público a nivel de nombre.
Además, sería más fácil decirle al código de inspección automática que no mire las cosas que comienzan con un guión bajo. Bueno, esto último también necesitaría cambios en el código de inspección de participación. Pero al menos existe la posibilidad de automatizarlo (por convención) sin administrar listas negras.

Ok, lo último que juro: pip 10 ya movió todo el código relevante a pip._internal (no usamos _pip porque eso rompería python -m pip , que es compatible).

¿Alguien puede verificar si https://github.com/pypa/pip/pull/5100 les resuelve esto?

Tacha eso, creo que #5100 está mal, ¿podrías verificar https://github.com/pypa/pip/pull/5101 en su lugar, por favor?

@dstufft Puedo confirmar, la solución en # 5101 resuelve el problema por mí.

Gracias @dstufft por tu tiempo para abordar esto. Trabajaré con los equipos de Anaconda para comunicar este problema y ayudarlos a dejar de importar pip.

Para que conste en este hilo, #5101 también resolvió mi problema.

Ditto, #5101 permite que la importación funcione dentro de nuestra herramienta. Caveat emptor: no he probado el pip parcheado ni nuestra herramienta de forma exhaustiva.

Esto debería corregirse en 9.0.3.

Gracias por la resolución rápida, de alguien que nunca escribió import pip en su vida pero fue consumidor de un paquete que sí lo hizo. Después de leer este hilo, parece que muchas aplicaciones han importado pip, sin saberlo, en contra de las mejores prácticas, y muchos desarrolladores y usuarios se ven potencialmente afectados por v9.0.2 y v10.

Segundo/tercero/Nth se agrega una advertencia de desaprobación adecuada para que las cosas sean más fluidas. ¿tal vez incluso una publicación de pypi.python.org?

¡Hurra! ¡Gracias por esto!

También me encantaría una advertencia de desaprobación y, lo que es más importante, instrucciones adecuadas sobre cómo inspeccionar mediante programación los entornos de Python en un mundo pip10. Claramente, es necesario, dado que más de 700,000 aplicaciones se vieron afectadas por este error.

pip list --format=json ?

En primer lugar, gracias a todos por contribuir con pip people, ya que cubre totalmente todos mis casos de uso con algunas opciones y argumentos fáciles de usar.

Debido a este "comportamiento indefinido sorprendentemente adoptado y útil", ¿necesitamos hacer un piplib como libgit2 para git? Tenga en cuenta que libgit2 no comparte ningún código con git y es mantenido por otro grupo de git. Y es bueno para el ecosistema git. Tal vez piplib cubra algunos casos de uso interesantes que no esperábamos.

Aquí hay una historia similar: https://public-inbox.org/git/1267957655.3759.29.camel@mattotaupa/T/

@drunkwcodes Sospecho que lo que propones ya está implementado en los paquetes existentes que menciona la documentación de pip, packaging , setuptools y distlib . Por lo que puedo decir de este hilo, no hay problema con una brecha en la funcionalidad, pero algunas personas tienen problemas con las herramientas que intentan importar e inspeccionar cada módulo, y tratan las fallas de importación como errores fatales.

Me parece que tales herramientas podrían solucionar este problema al envolver declaraciones de importación en un bloque try/except, pero eso también parece ser un precedente cuestionable para establecer. Sin embargo, dado el lanzamiento de pip 9.0.3, creo que probablemente no valga la pena debatir el problema de la importación a menos que el problema vuelva a ocurrir en pip 10. De todos modos, siempre que los mantenedores no hagan todo lo posible para hacer import pip fallan, o rechazan sumariamente los parches que solucionan tales fallas, habría un terreno común en el que apoyarse.

@sruggier Los paquetes mencionados son todos buenos, y WheelFile.install() también necesita más promoción. Pero el servicio integral pip.main() proporcionado es insustituible con todo lo anterior. Todavía vale la pena intentarlo.

Lo más importante es que espero que estas necesidades sean cubiertas por otro proyecto, y pip10 llegará sin problemas y sin garantías adicionales. La desaprobación y la minimización del código base son los puntos principales para un lanzamiento importante.

Los detalles de implementación concretos para un "software" de infraestructura permanente son ridículos. No se puede juzgar a los mantenedores por el caso de abuso documentado y detener la rueda de pip.

Si insiste en usar pip como lib, será necesario reconsiderar muchas suposiciones.

@drunkwcodes Para que quede claro, pip.main() es el uso más fácil de reemplazar: simplemente necesita usar subprocess.run([sys.executable, '-m', 'pip', <rest of args>]) .

Además, la razón por la que WheelFile.install() no se promociona es que el proyecto de la rueda también ha declarado que no proporciona una API visible para el usuario; originalmente mencionamos la rueda en los documentos de pip, pero la eliminamos a pedido de ellos. Sin embargo, el PEP de la rueda es bastante claro acerca de cómo instalar una rueda: no es difícil de implementar en un módulo de terceros.

Aprecio el trabajo que todos ustedes hacen en pip y sé que no es fácil. Pero para el registro:

Estoy un poco decepcionado de que la gente aún no se haya alejado de import pip. Las personas afectadas por este problema aún deberán prepararse para pip 10

spaCy se ha alejado de import pip . Pero algunas personas todavía usan spaCy 1, que importó pip --- y por razones obvias, no identificó pip como un lanzamiento de parche. Si el cambio se hubiera producido en la v10, nuestras versiones anteriores no se habrían visto afectadas. Acabamos de emitir una revisión para solucionar este problema.

instrucciones adecuadas sobre cómo inspeccionar mediante programación los entornos de python en un mundo pip10

¿Cuál es la posición de PyPA sobre distlib? Pip obviamente lo está usando de alguna manera, pero también lo está usando empaquetado, que distlib pretende desaprobar.

Si no hay una posición oficial, al menos los pensamientos y opiniones actuales de los mantenedores centrales de pip serían muy apreciados. Si hay discusiones relevantes sobre este tema en otros lugares, un simple indicador de otras discusiones es suficiente para mí.

No estoy al tanto de que distlib desaprueba el empaquetado. Menciona "distutils2/packaging" pero distutils2 era algo diferente.

Mi opinión personal es que tanto distlib como packaging son cosas perfectamente razonables de usar. Debe evaluarlos usted mismo para confirmar que satisfacen sus necesidades, obviamente, al igual que cualquier otra dependencia en la que confíe.

Tal vez desaprobar es una palabra demasiado fuerte entonces. La fuente de mi comprensión actual:

https://distlib.readthedocs.io/en/latest/overview.html#distlib -evolucionado-fuera-del-empaquetado

Ah, ese es un "empaquetado" diferente: fue el módulo stdlib propuesto el que estaba destinado a reemplazar distutils. Es completamente diferente del proyecto PyPI packaging . Podría valer la pena pedirle al proyecto distlib que aclare esa distinción un poco mejor.

Podría valer la pena pedirle al proyecto distlib que aclare esa distinción un poco mejor.

Ya lo hice :) Consulte: https://bitbucket.org/pypa/distlib/issues/100/clarify-project-positioning-and-status

Este hilo se ha bloqueado automáticamente ya que no ha habido ninguna actividad reciente después de que se cerró. Abra un nuevo problema para los errores relacionados.