<p>pip install --editable y pip install clash para paquetes de espacio de nombres</p>

El mismo problema aquí :(

Publiqué un código para probar este error: http://public.hg.stephane-klein.info/hgwebdir.cgi/test_pip_namespace_bug_3/

La raíz del problema aquí es que setuptools incluye dos métodos para hacer que los paquetes de espacio de nombres funcionen: el método __init__.py (que está documentado y puede ser utilizado por humanos), y el método ...-nspkg.pth file, que es solo se usa con --single-version-externally-managed (que usa pip). Los dos métodos no son compatibles entre sí.

Después de una discusión con mitsuhiko y otros sobre IRC, parece que la mejor solución (parcial) para pip es hacer que "pip install -e" agregue una versión modificada del archivo setuptools estándar ... nspkg.pth para cada paquete desarrollado instalado . (Las modificaciones necesarias son usar la ruta de desarrollo de enlace de huevo en lugar de sitedir, y omitir la verificación de init .py por completo, ya que un paquete de espacio de nombres instalado por desarrollo tendrá un init .py). Esto significa que pip será al menos compatible consigo mismo (los paquetes de espacio de nombres pip-installed y pip-editable-installed funcionarán juntos). Los paquetes de espacio de nombres instalados por Pip y setuptools / distribuidos no serán compatibles.

Esto también me mordió recientemente. Otro problema causado por esto es que, dado que un __init__.py no está instalado para el paquete de espacio de nombres (suponiendo que solo haya instalado un paquete en ese espacio de nombres, y se haya instalado, una sola versión, administrado externamente) rompe la búsqueda del módulo de nose. Quizás sea culpa de nose, pero sigo pensando que es razonable esperar que si un directorio no contiene un __init__.py no sea un paquete de Python.

Creo que pip debería de alguna manera acabar con el nspkg.pth por completo e instalar el __init__.py . Siempre que el paquete en sí esté diseñado correctamente (es decir, el __init__.py está vacío excepto para extender_path / declare_namespace) no debería ser un problema. --single-version-externally-managed se diseñó teniendo en cuenta a los empaquetadores del sistema, pero no van a utilizar pip en primer lugar. Así que me pregunto si hay alguna forma de desactivar este comportamiento por completo sin ser demasiado intrusivo.

+1 para cambiar de '--single-version-externally-managed': esa opción no está diseñada para los casos de uso de pip en absoluto. Si pip no puede hacer al menos un trabajo tan bueno instalando cosas como easy_install, ¿cuál es su propósito?

Cambiar completamente de --single-version-externally-managed no va a suceder; las instalaciones planas son una característica. Cambiar de él solo en el caso de los paquetes de espacio de nombres es una posibilidad que consideraría para evitar estos problemas. No me gusta, pero no parece haber una gran opción, dada la incompatibilidad inherente entre los dos tipos de soporte de paquetes de espacio de nombres integrados en setuptools / distribution.

Decir que --single-version-externally-managed "no está diseñado para los casos de uso de pip" es algo entre incorrecto y una pista falsa. La bandera está destinada a permitir instalaciones planas de una sola versión, administradas por alguna herramienta que no sea easy_install. Para eso precisamente lo usa pip; el hecho de que el autor de setuptools originalmente (e incorrectamente) pensó que solo los empaquetadores del sistema estarían interesados ​​en tal característica es irrelevante.

La rotura aquí es un error inherente en la técnica que setuptools usa para paquetes de espacio de nombres con esa bandera, y el error está tan presente cuando la bandera es utilizada por su audiencia originalmente prevista, los empaquetadores del sistema (vi por primera vez el error en la interacción entre un " setup.py desarrollar "paquete instalado y un paquete de espacio de nombres instalado del paquete del sistema).

También estoy experimentando este error. Supongo que este es uno de esos errores irresolubles que llegó para quedarse. Oh bien.

Aceptaría un parche para evitar --single-version-externally-managed cuando se trata de un paquete de espacio de nombres, lo que creo que resolvería este problema. Actualmente no tengo ningún plan para escribir ese parche.

¿Por qué no una opción que podemos pasar a pip install para no usar --single-version-externally-managed ? Pruebo comentando eso en ./pip/req.py:568 y todos los paquetes ahora instalados en el directorio de huevos, al igual que lo hace easy_install. En algún momento quiero hacer esto si utilicé pip y easy_install para que mi site-packages no se mezcle con algunos paquetes instalados de forma plana y otros no.

No veo ningún problema con la opción --egg para optar por no participar en --single-version-externally-managed .

https://github.com/k4ml/pip/commit/93cd6b16207d2eba201a7fc3126624b616f5e6f9

¿Alguien puede comentar si me estoy moviendo en la dirección correcta? Esta es la primera vez que pirateo el código pip, por lo que se basa en mis pocos minutos de vislumbrar parte de él, solo para obtener pip install --egg somepackages instalar todo en un solo directorio de huevos.

¿Alguien puede comentar si me estoy moviendo en la dirección correcta?

Me parece bien, solo necesita una prueba. Las pruebas son en su mayoría de alto nivel
pruebas de integración usando ScriptTest, debería ser fácil escribir una basada en
ejemplos existentes. En este caso, querrá probar que la instalación
un paquete de muestra da como resultado un archivo .egg, no una instalación plana, en
paquetes de sitio. Debería instalar un paquete del sistema de archivos local,
no la red: tests/packages/FSPkg probablemente funcionará bien. Añadiendo
la prueba de tests/test_basic.py está bien.

¡Gracias!

Solicitudes de extracción: https://github.com/pypa/pip/pull/541

También estoy pensando en hacer posible establecer esta bandera en pip.conf. Lo que piensas de eso ?

También estoy pensando en hacer posible establecer esta bandera en pip.conf. Lo que piensas de eso ?

Discutamos sobre la solicitud de extracción.

Solicitud de extracción combinada n. ° 541, que proporciona una solución. ¡Gracias @ k4ml!

Aviso: la opción --egg , que se agregó para solucionar este problema, podría eliminarse sin que se ofrezca una solución alternativa. Ver discusión en el n. ° 1749

Aquí hay un script para reproducir realmente este problema.

https://gist.github.com/Ivoz/d9bff05069e0ec53e6ea

No soy un gran admirador de la solución --egg, pero debe haber una solución menos engorrosa para esto.

sin una solución alternativa, mientras desarrollo, no puedo usar --editable una vez y luego editar y probar. cada vez que guardo mi código tengo que ejecutar pip install -I --no-deps . que se vuelve muy viejo y frágil (léase: a veces lo olvido).

parte del problema con la forma en que se manifiesta todo este problema es que es silencioso. simplemente no puede importar un módulo aunque esté instalado y pip le indique que está allí.

Sería un paso positivo simplemente hacer que pip se quejara si intenta instalar paquetes editables como parte de un espacio de nombres donde ya está instalado un paquete no editable en ese espacio de nombres. o alternativamente para quejarse si intenta instalar un paquete no editable que es parte de un espacio de nombres donde ya está instalado un paquete editable en ese espacio de nombres.

Otra opción, si realmente queremos que los paquetes de espacio de nombres y las instalaciones editables siempre funcionen, podría ser que si un paquete de espacio de nombres se instala como editable, pip podría reorganizar todos los otros paquetes en ese espacio de nombres como editables junto con el paquete deseado.

Envié 2 propuestas para solucionar este problema en setuptools https://bitbucket.org/pypa/setuptools/issue/250/develop-and-install-single-version. FYI.

poniendo

import pkg_resources; pkg_resources.fixup_namespace_packages ('')

en un archivo .pth en site-packages parece suficiente para que pip install -e installed funcione correctamente.

Esto también afecta a dos paquetes con el mismo espacio de nombres superior con ambos instalados como editables. La instalación del segundo paquete está rota.

Usamos un espacio de nombres global para todas nuestras aplicaciones y, por lo tanto, este problema es un poco difícil (+ el problema de que setuptools no admite ruedas, que son necesarias debido a la falta de un compilador en nuestras plataformas de implementación de Windows). Además, todas las soluciones recomendadas parecen fallar en nuestra configuración con Python 3.4.

Después de darme cuenta de que pip install -e ejecuta setup.py develop para el proyecto que debería ser editable, me enganché al procedimiento de setuptools y escribí un archivo * .pth, que "introduce" los paquetes de espacio de nombres cuando el proceso de Python empieza. Esto nos resuelve el problema al usar setuptools 18 y pip 7.1.0.

Un archivo setup.py de ejemplo, que muestra cómo se puede lograr, se puede encontrar aquí:
https://gist.github.com/cbrand/a1624ac3e9c81ce45fcb

Espero que esto también sea útil para otras personas.

También me encontré con este hoy, y me impide cambiar de buildout a virtualenv + pip.

Creé una pequeña demostración para demostrar el problema. Para probarlo, descomprima el .tar.gz y ejecute el script {{run-me}} dentro de él. Puede resultar útil al probar una solución.

También estoy abordando este problema.

Mientras trataba de entender, encontré la solución propuesta por @carljm en https://github.com/pypa/pip/issues/3#issuecomment -1659959, es decir, _have "pip install -e" agregar una versión modificada del estándar setuptools ... archivo nspkg.pth para cada paquete de desarrollo instalado_.

Experimenté con ese enfoque manualmente y parece funcionar bien. Parece que al mismo tiempo resolvería la cuestión de los árboles de origen poco profundos con paquetes de espacio de nombres faltantes, como se describe en # 3160.

Entonces, me pregunto si ese enfoque todavía se considera válido, si hubo algún intento de implementarlo y si se consideraría un parche para esto.

Entonces ... ¿no hay esperanza de que este se arregle en un futuro próximo?

Algún efecto secundario de pkg_resources.get_distribution() hace que la importación funcione. Descubrimos esto cuando el código que cargaba los puntos de entrada funcionaba correctamente mientras el shell de Python fallaba.

Esto también puede explicar por qué un shell ipython no tiene problemas para importar los paquetes.

Me sorprende que este error siga abierto sin una solución clara después de 5 años.

Si su trabajo es pegar marcos juntos en un marco unificado, pip hace que su trabajo sea una mierda. Sinceramente, no tengo idea de cómo seguir adelante con mi trabajo debido a este error.

Este es un problema difícil de solucionar en proyectos realizados principalmente por voluntarios,
Siéntase libre de agregar el soporte necesario en las herramientas de configuración para que pip pueda hacer esto correctamente

Brandon Github [email protected] escribe:

Me sorprende que este error siga abierto sin una solución clara después de 5 años.

Sí, es una lástima.

Si su trabajo consiste en pegar marcos en un marco unificado,
pip hace que tu trabajo sea una mierda. Sinceramente, no tengo ni idea de cómo proceder con
mi trabajo debido a este error.

Recientemente apliqué el truco fixup_namespace_packages ('') mencionado anteriormente y
parece funcionar: creé un z.pth dentro de los paquetes del sitio de venv
que contiene solo import pkg_resources; pkg_resources.fixup_namespace_packages('')

Vale la pena intentarlo, en mi humilde opinión.

¡Otro golpe más aquí!

Solo mencionaré que cada paquete de médula utiliza espacios de nombres (algunos paquetes llenan hasta cuatro o cinco) y que este problema en particular ha sido una pesadilla de mi existencia cuando se trata de ayudar a los nuevos usuarios a configurar las herramientas de desarrollo. . Tengo apenas 60 paquetes usando esto. La nota entry_points también es interesante, ya que prácticamente todos los paquetes que contribuyen a un espacio de nombres también contribuyen con entry_points .

El enfoque pip solo funciona, en mi experiencia, si _todos_ los paquetes están instalados, editables, desde el disco, que cooperan en el espacio de nombres. Si se instala un paquete no editable a través de pip, toda la bola de hilo comienza a desenredarse con algunos síntomas muy, muy obtusos para los nuevos usuarios. (Como módulos que se pueden importar de forma intermitente; una comprobación general de la cordura de la importación del espacio de nombres principal y la verificación de que namespace.__path___ ha identificado rápidamente el paquete borked culpable en la prueba). Mezclar paquetes instalados correctamente con pip y setup.py develop 'd los de origen (evitando pip) parece, sin embargo, funcionar.

También parece que podemos entrar en situaciones extrañas en las que un solo paquete que contribuye al espacio de nombres se puede instalar de tres formas diferentes, a veces todas simultáneamente. (Las llamadas repetidas a pip uninstall , cada vez que encuentra más archivos, es tan divertido de ver como desafortunado). La instalación de dependencias cuando se usa pip install -e parece ser inconsistente. En la mayoría de los casos, terminamos con espacios de nombres correctamente descomprimidos (instalados), archivos pth-link (instalados editables) y, en un caso, de alguna manera logramos instalar un .egg comprimido, a pesar de zip_safe siendo False en ese paquete dependiente y no se proporciona una distribución .egg en Pypi.

La frustración con los problemas del espacio de nombres alcanza su punto máximo después de la cuarta vez que se bombardea un entorno virtual para empezar de cero. ;)

No es una solución pero solo pongo algunas notas. Al mezclar entre paquetes 'editables', paquetes con espacio de nombres y paquetes normales, tengo más suerte con buildout + mr.developer.

Si bien el truco de reparación que mencionó

Después de jugar un poco con la instalación de pip y el modo editable, se me ocurrió la misma idea que @carljm (agregando un archivo -nspkg.pth para cada paquete editable), pero nadie parece haber implementado eso (o era el ahora obsoleto) -opción huevo?).

¿Sigue siendo un problema en las versiones más recientes de python con PEP420 implementado? (leer: ¿ayudaría cambiar a una versión más nueva de python?)

Usar el estilo PEP420 de manera efectiva me ayudó varias veces ahora con el modo editable.

Desafortunadamente, viene con sus propios fallos: por ejemplo, setuptools ' find_packages no lo admite , por lo que mis paquetes más nuevos contienen el siguiente truco:

-    packages=find_packages('src'),
+    packages=['toplevel.child.' + package
+              for package in find_packages('src/toplevel/child/')],

nadie parece haber implementado la adición de un -nspkg.pth para cada paquete editable.

Consulte Setuptools 31, que agrega soporte para esta función y también coexiste con los paquetes PEP-420 en Python 3.5+.

Para cualquiera que tenga curiosidad, aquí hay una lista exhaustiva de cómo funcionan los paquetes de espacios de nombres en pip install , pip install -e , python setup.py install y python setup.py develop :

https://github.com/jonparrott/namespace-pkg-tests/blob/master/table.md

tl; dr: Puede usar pip install -e y python setup.py develop siempre que todos los demás paquetes en su espacio de nombres se hayan instalado usando pip .

Voy a cerrar este tema. Parece que setuptools 31 ha solucionado esto para nuestros scripts de reproducción, y más allá de eso, no hay nada que pip pueda hacer aquí.

@jonparrott
¿Qué versiones de pip y setuptools se utilizaron para obtener resultados en https://github.com/jonparrott/namespace-pkg-tests/blob/master/table.md ?

@dstufft Aunque aprecio que supuestamente esté arreglado, me gustaría ver que la tabla de compatibilidad de @jonparrott se vuelva a ejecutar como prueba. Espero lo mejor, planifique lo peor para los tickets que tienen casi 7 años y tienen escenarios de falla con un alcance tan amplio. La confianza no es alta dada la extensa historia de este problema, y ​​al volver a ejecutar la suite nox yo mismo, las fallas indicarían una falta de resolución real.

En los ejemplos de @jonparrott , los casos python setup.py install directamente (excluyendo los fallos de PEP 420 en Python 2, que se esperan). Esto está fallando incluso en los casos en los que pip no está involucrado en absoluto (como python setup.py install + python setup.py develop ).

Este boleto era para combinaciones de pip install . y pip install -e o python setup.py develop .

El gráfico ya publicado por @jonparrott demuestra que este ticket está resuelto y cualquier problema restante aquí es un problema con python setup.py install y no con pip.

Acabo de volver a ejecutar mis pruebas y todo es igual a como lo ejecuté inicialmente. Estoy de acuerdo con la evaluación de @dstufft : pip ha hecho todo lo posible para resolver esto.

@ piotr-dobrogost la prueba usa las últimas versiones de ambos. Al momento de escribir estas líneas, pip 9.0.1 y setuptools 34.3.2.