Acordado. El comportamiento actual de pip para enlaces de dependencia realmente apesta.

4295

3610

[Escribí en el n. ° 3939, moviendo mi comentario aquí]

Entonces, aquí está el problema principal: si no quiero usar un archivo requirements.txt (porque, digamos, quiero dependencias declarativas todas especificadas en setup.cfg ), ¿cómo se supone que debo especificar un URL como dependencia?

Esto no funciona:

[options]
install_requires = 
  requests==2.18.4
  https://github.com/example/example_lib/archive/master.zip

También creo que los enlaces de dependencia son raros y está bien eliminarlos, pero canónicamente, ¿cómo se sirve este caso de uso si no es con ellos?

Otro problema es que dependency_links aparentemente no se puede especificar en setup.cfg, solo como argumentos de setup.py. Si van a estar indeseables, eso debería arreglarse.

¿Hay alguna novedad al respecto? ¿Hay alguna alternativa en curso? dependency_links_ parece ser la única opción para la distribución interna / privada de bibliotecas.

En lugar de desaprobarlo, debería arreglarse, mucha gente se olvida o se confunde porque se olvida de poner tanto el nombre-versión de la biblioteca en install_requires como el enlace de dependencia que contiene el tarbal junto con el huevo. Como alternativa, me encantaría ver que @jleclanche ha sugerido un enlace simple al tarball en install_requires (especificar el huevo podría ser opcional).

No creo que estemos solos: https://stackoverflow.com/questions/3472430/how-can-i-make-setuptools-install-a-package-thats-not-on-pypi

Las herramientas de

@dstufft por cierto: me gustaría argumentar que la existencia de devpi demuestra una solución más limpia al problema que hace que los enlaces de dependencia sean innecesarios

En mi humilde opinión, la herencia del índice + la lista blanca / lista negra es más consistente y más comprensible a nivel de operaciones

@RonnyPfannschmidt , gracias por la sugerencia, parece que me estoy perdiendo algo importante (las discusiones sobre esta desaprobación han reddit :

devpi podría ser una solución, pero traer otro servicio al juego que necesita mantenimiento y tener que esperar a que un administrador lo configure, no me permitirá trabajar muy pronto. Además, todavía tendríamos la necesidad de crear paquetes y luego ponerlos en devip (¿o tiene devpi una función para rastrear los repositorios de git?)

Idealmente, me gustaría una alternativa que no me lleve más que agregar un archivo en mi biblioteca, o algunas líneas en setup.py.

Básicamente, no entiendo la decisión subyacente de eliminarlo, puedo ver cómo puede conducir a malas prácticas e inseguridades, pero mientras se mantenga para uso interno, no debería ser un problema importante.

4175 significa que el soporte de URL PEP 508 estará allí en el pip 10. Creo que esto se puede cerrar.

Pensamientos @pfmoore @dstufft?

Pensé que https://github.com/pypa/pip/pull/4175/commits/86b07792e7ae762beeaeb471ab9db87e31bc285d significaba que la sintaxis @ no se puede usar para dependencias, por lo que esto significa que # 4175 no es una solución para este problema . Los comentarios allí fueron que no deberíamos implementar @ soporte para dependencias hasta que PyPI pudiera bloquear las cargas que lo usaron (porque no queremos instalar algo de PyPI para poder tomar cosas de URL arbitrarias , presumiblemente).

No debería quedar obsoleto hasta que exista una alternativa, es decir, soporte PEP 508. Hasta entonces, demasiada gente lo está usando.

¿Cuál es el flujo de trabajo adecuado para esto?

Digamos que hay una biblioteca a la que necesito agregar una función. Lo apuesto a Github. La función no se fusionará pronto, así que tengo una herramienta que configuré para usar mi bifurcación de Github en lugar de PyPi.

Ahora todos mis usuarios tienen que agregar --process-dependency-links al instalar mi herramienta con pip, que es una marca obsoleta e incluso una vez eliminada.

¿Hay alguna opción en setup.py que me falta o realmente no hay forma de evitar esto? Parece que la única forma viable de hacer esto es empujar hacia arriba un paquete pypi bifurcado. Eso solo aumentará la confusión del usuario una vez que su solicitud de extracción se fusione, de todos modos.

Vayamos a esto.

--process-dependency-links realmente no tiene una alternativa hoy. Por lo tanto, sugeriré que sigamos adelante y lo desapruebe.

Sin embargo, la bandera significa que pip se comunicaría con URL arbitrarias; debería tener una advertencia adjunta sobre esto.

@pradyunsg a menos que haya un plan real para acabar con él para siempre, sugiero encarecidamente que dejes descansar a ese zombi o que lo eliminen.

No creo que las personas que realmente lo necesitan tengan ningún incentivo para arreglar la situación a menos que pip diga "NO, no asumo tu deuda".

Como mantenedor de pip, mi preocupación es no permitir que pip sea un vector de exploits. Pip asume PyPI como el índice predeterminado, por lo que existe una confianza implícita en PyPI allí. Entonces mis primeras preguntas son:

1. ¿Existen paquetes en PyPI que tengan metadatos dependency_links ?
2. ¿Podría modificarse PyPI para rechazar la carga de proyectos con dependency_links (o ya lo hace)?
3. Alternativamente, ¿podría pip simplemente negarse a procesar enlaces de dependencia (independientemente de si la opción está configurada) para los paquetes descargados de PyPI?

Si pudiéramos estar seguros de que no hay forma de que los usuarios de pip sean mordidos por paquetes en PyPI con dependency_links maliciosos, estaría menos preocupado. Los usuarios que opten por utilizar un índice personalizado deben decidir por sí mismos si confían en él. (Preferiría retener la bandera incluso entonces; esto es potencialmente un exploit remoto y siempre debe optar por participar explícitamente).

Entonces, con los siguientes cambios:

1. Pip nunca procesará los enlaces de dependencia de PyPI (ya sea explícitamente o simplemente porque sabemos que no están allí)
2. La --process-dependency-links está obsoleta, pero solo funciona para índices personalizados.

Estaría bien con aceptar eso como el status quo. Las personas que necesitan una función de estilo de enlace de dependencia pueden decidir entre sí cómo (si es que quieren) avanzar.

Si alguien quisiera, podríamos poner todo eso en una definición estándar de metadatos de enlace de dependencia, y la desaprobación actual se convertiría en "el comportamiento actual se eliminará a favor del comportamiento especificado en el estándar". Pero desde un punto de vista centrado en pip, prefiero simplemente hacerlo: dejar que las personas que necesitan enlaces de dependencia se encarguen del trabajo de estandarización (después de todo, es para su beneficio, ya que luego tienen una ruta: obtener un cambio estándar - modificar el comportamiento de pip con pleno consenso de la comunidad).

Básicamente, tenemos una función que está destinada a reemplazar los enlaces de dependencia, pero pip aún no ha comenzado a respetarla, porque aún no tenemos una forma de bloquear las cargas a PyPI que la usan.

¿Te refieres al # 4175? ¿Cuál está bloqueado debido a 86b0779? ¿Quizás podríamos modificar https://github.com/pypa/pip/blob/master/src/pip/_internal/req/req_install.py#L167 para dar solo el error si comes_from es PyPI?

Luego, podríamos cambiar la advertencia de depreciación por --process-dependency-links para decir que los usuarios deben cambiar a la sintaxis @ y eliminar --process-dependency-links después de un período de depreciación razonable (tendríamos que comenzar el reloj avanza desde el punto en el que la sintaxis @ está disponible).

@pfmoore Sí, eso es exactamente, y parece un posible camino a seguir.

está bien. Si nadie más lo hace primero, me ocuparé de escribir un PR.

Por lo que he deducido, el problema del usuario aquí es que deben aprobar una opción que diga explícitamente "hey, estoy en desuso" cuando la pasas por una funcionalidad que no tiene una alternativa.

Estoy a favor de eliminar el soporte de dependency_links por completo durante un período de desactivación. Y mientras tanto, agregar soporte de dependencia de URL PEP 508, sobre lo que creo que pip aún debería ser ruidoso cuando se usa y que aún deben ser opcionales.

Eso significaría:

• poner la capacidad de procesar direcciones URL PEP 508 detrás de una bandera
  
  
  
  • aparte: debería nombrar la bandera de modo que un usuario preocupado por la seguridad verifique los documentos
  
  
• comenzar a negarse a instalar PEP 508 url-deps cuando provienen de un paquete PyPI
• los enlaces de dependencia permanecen obsoletos pero tenemos una fecha para eliminarlos
  
  
  
  • Honestamente, no quiero darle a esto un período de desaprobación más largo que una versión única que imprime la alternativa.
  
  

Lo escribí ayer pero no lo envié. Ahora me doy cuenta de que es básicamente lo mismo que el último comentario de @pfmoore .

_¡Hurra!

¿Deberían los departamentos de URL requerir una marca de habilitación? PEP 508 no lo dice, y la implementación actual no lo hace. Puedo ver la lógica, pero no confío en mi juicio sobre las preguntas de seguridad frente a las de facilidad de uso.

Además, me gustaría ver documentación clara sobre cómo los proyectos deberían cambiar de los enlaces de dependencia a la sintaxis @ antes de comenzar a presionar el interruptor. Ya es bastante difícil llegar a las personas que se verán afectadas por las bajas, y las advertencias de que no pueden averiguar cómo abordarlas no ayudarán. Idealmente, la advertencia debería incluir un puntero a un documento "cómo cambiar", en mi opinión.

No confío en mi juicio sobre las cuestiones de seguridad frente a las de facilidad de uso.

Me inclino por: "estar seguro de forma predeterminada" y optar por un comportamiento menos seguro.

documentación clara sobre cómo los proyectos deben cambiar de enlaces de dependencia a la sintaxis @ antes de comenzar a presionar el interruptor

Suena bien para mí.

Me inclino por: "estar seguro de forma predeterminada" y optar por un comportamiento menos seguro.

Como alguien que se queda atrás para lidiar con el firewall y las restricciones de seguridad en mi trabajo, soy muy consciente de que no comprendemos mucho el tipo de entornos en los que es probable que esta característica sea más útil (desarrollo interno, código cerrado , flujos de trabajo estrictamente controlados y diseños de red, etc.). Por lo tanto, mi inclinación es estar seguro para el flujo de trabajo predeterminado (PyPI) pero no poner obstáculos adicionales en el camino de las personas con casos de uso que son claramente importantes para su flujo de trabajo, pero donde no comprendemos adecuadamente las compensaciones que tienen que hacer. fabricar.

En mi opinión, "si el paquete proviene de un servidor que usted optó explícitamente por usar" es suficiente para permitir enlaces URL.

¿Ver? No es que no tenga opiniones, solo que no estoy seguro de que mis prejuicios no se muestren: sonríe:

no poner obstáculos adicionales en el camino de las personas con casos de uso que son claramente importantes para su flujo de trabajo, pero en los que no comprendemos adecuadamente las compensaciones que tienen que hacer.

Lo suficientemente justo. Si algunos usuarios pudieran proporcionar información sobre su flujo de trabajo, sería bueno.

"si el paquete proviene de un servidor que usted optó explícitamente por usar" es suficiente para permitir enlaces URL.

No estoy seguro aquí. : /

¿Ver? No es que no tenga opiniones, solo que no estoy seguro de que mis prejuicios no se muestren 😄

Jeje.

Lo suficientemente justo. Si algunos usuarios pudieran proporcionar información sobre su flujo de trabajo, sería bueno.

En mi opinión, "si el paquete proviene de un servidor que usted optó explícitamente por usar" es suficiente para permitir enlaces URL.

Solo permitir fuentes de GitHub resolvería el 99% del problema para mí. Los paquetes ascendentes tienen errores o faltan características. Los bifurco y los soluciono, emito un PR, luego espero un tiempo posiblemente muy largo para fusionarlos y luego lanzarlos en PyPI. Mientras tanto, mis paquetes dependen de las correcciones en esos paquetes.

Esto puede ser opt-in, siempre que se pueda hacer en una línea.

No es realmente un problema de seguridad usar enlaces directos (asumiendo HTTPS / etc.), es solo una cuestión de disponibilidad. Dado que los estamos rechazando de PyPI, entonces diría que es lo suficientemente bueno y no necesitamos otra bandera.

En mi trabajo, caeríamos en algunos de los casos de uso que mencionó @pfmoore , a saber, desarrollo interno antes de que un paquete sea de código abierto, código cerrado, etc. (siempre paquetes internos dependiendo de otros paquetes internos, todos ellos en un servidor de control de versiones ).
Aunque, también veo el posible caso de uso de alguien que se refiere a la ubicación del sistema de archivos ...
¿Tendría sentido proporcionar una lista de hosts / ubicaciones en la lista blanca? El nombre de la bandera debe, en mi opinión , como sugirió --whitelisted-host ?

@masdeseiscaracteres Creo que puede haber entendido mal: estaba sugiriendo que si se recuperaba un paquete de PyPI, fallaríamos si alguna de sus dependencias se especificara a través de una referencia @ . Pero de todos modos no debería haber tales casos en PyPI (esperamos rechazarlos en algún momento, simplemente no hemos podido configurar eso todavía). Todos los demás usos de las referencias @ estarán bien.

Parece que vamos a seguir adelante con un PR que hace lo que describe @pfmoore en https://github.com/pypa/pip/issues/4187#issuecomment -389846189.

Los RR.PP. bienvenidos. :)

Tenga en cuenta que no he tenido tiempo de llegar a esto, no porque el cambio sea difícil (como se señaló, parece ser simplemente un cheque contra comes_from ) sino porque no sé cómo provocar el yo mismo me equivoco (y lo que es más importante, no sé cómo escribir una prueba que lo haga). Si alguien puede proporcionar un ejemplo de un caso de prueba de este tipo, sería de gran ayuda.

Si alguien puede proporcionar un ejemplo de un caso de prueba de este tipo, sería de gran ayuda.

Existe una prueba test_install_pep508_with_url_in_install_requires que demuestra esto.

En cuanto a los errores al instalar desde PyPI, no veo una mejor opción que cargar algo en PyPI que tenga un requisito de URL. 😞 Subí un paquete en PyPI para este propósito. https://pypi.org/project/pep-508-url-deps/

Otra cosa es - comes_from no es una URL o ruta, es una cadena con las líneas 'box==0.1.0 from file:///private/tmp/box' . Quien quiera solucionar este problema, ahora tiene que encontrar una forma mejor de solucionar el error, de modo que tengamos información sobre el origen de un paquete. :)

@pfmoore, este problema está cerca y es muy querido para mi corazón 😄 ¿La carga de @pradyunsg te da lo que necesitas, y todavía estás planeando abordar esto? Si no, podría intentarlo.

@bstrdsmkr No, y como dice @pradyunsg , no es tan simple como pensaba, ya que comes_from no es la URL de origen. Así que no sé cuándo tendré tiempo ahora (no tengo un uso personal para esta función, por lo que no es una de mis prioridades).

Como se señaló anteriormente, los RP son bienvenidos :-)

Agregaré que el paquete cargado no ayuda de ninguna manera para la implementación, solo es útil para probar la funcionalidad.

Tengo entendido que la solución deseada es algo como:

if req.url and is_like(req.url, PYPI.url):
    raise

en https://github.com/pypa/pip/blob/master/src/pip/_internal/req/req_install.py#L172
donde is_like() devuelve True si las URL se encuentran en el mismo dominio. ¿Es eso correcto?

Sí. Creo que sí. Ese será el cambio de código.

Y necesitaremos agregar / actualizar pruebas y una entrada de NOTICIAS.

También creo que este cambio es lo suficientemente importante como para garantizar la posibilidad de que el mensaje de desaprobación proporcione un enlace a los documentos + una sección adicional en la guía del usuario que indique a las personas cómo cambiar a la alternativa.

Como mantenedor de pip, mi preocupación es no permitir que pip sea un vector de exploits. Pip asume PyPI como el índice predeterminado, por lo que existe una confianza implícita en PyPI allí.

No, existe una confianza explícita. Y agregar salvaguardas contra el uso de fuentes externas en dependencias, en mi humilde opinión, no mejorará la situación: es más conveniente ocultar malware en pypi que en un VCS disponible públicamente.

En mi humilde opinión, un mejor enfoque sería utilizar los VCS del desarrollador como fuentes primarias y mantener pypy como un registro que los señala y un proxy de almacenamiento en caché con alguna prueba criptográfica sólida de que el contenido de VCS es idéntico al obtenido de pypy. quiero decir

0 registro

dev -- public key --> pypa

1 cargando

setuptools -- git+https:/.... --> pypa
pypi --> Tor --> give me that commit --> vcs
pypi <-- Tor <-- here -- vcs
pypi checks the signature matches the dev

2 inactivo:

pypi --> Tor --> give me that commit --> vcs
pypi <-- Tor <-- here -- vcs
pypi checks it

2 recuperando

flips a coin
if coin == 1:
  pip -- give me package git+https:/... --> pypi
  pip <-- signature || content -- pypi
  pip -- give me the signature --> vcs
  pip <-- signature -- vcs
else:
  pip -- give signature of package git+https:/... --> pypi
  pip <- signature -- pypi
  pip --> Tor --> give me that commit --> vcs
  pip <-- Tor <-- here -- vcs


pip checks if the signature matches the public key and signature from pypa
pip -- give me public key --> keyserver
pip <-- PK -- keyserver
pip checks signature given by VCS against the sdist given by pypy
pip caches public key and repo location

1 las fuentes instaladas coinciden con las de VCS debido a la firma
2 el autor también coincide
3 pypa puede hacer trampa con nuevos usuarios, pero los antiguos pueden detectar trampas
4 El autor puede hacer trampa mostrando en la interfaz web una rama distinta a la dada a pypy y enviar a pypy otra rama. No funcionará bien si hacemos que la rama sea una parte obligatoria de URI.

@KOLANICH Creo que te refieres a PyPI (índice de empaquetado de Python) cuando dices pypy / pypa. PyPy es una implementación alternativa de Python. PyPA (Python Packaging Authority) es un grupo de voluntarios que mantienen proyectos importantes en el espacio de Python Packaging. Por favor, obtenga los acrónimos correctos o absténgase de usarlos.

Está sugiriendo cambiar fundamentalmente el diseño de un servicio existente bien establecido. Si desea tener cambios tan importantes, puede proporcionar al menos un plan de transición (factible) y una implementación de POC, para administrar / cambiar la arquitectura para permitir la transición / minimizar la rotura de los flujos de trabajo existentes. Tenga en cuenta que depender del alojamiento externo es algo que se eliminó explícitamente de PyPI en el pasado en PEP 470 , sin embargo, ese fue un caso bastante diferente de lo que está sugiriendo.

PyPI es mantenido por voluntarios, que se ejecuta en infraestructura donada / patrocinada. Está sugiriendo que se conecte a través de Tor, otro servicio voluntario mantenido / administrado. Ambos son proyectos importantes y tienen un costo asociado con mantenerlos en funcionamiento, a pesar de que no es directamente transmitido por / visible para sus usuarios.

Sin embargo, este no es el lugar adecuado para esta discusión. Si desea proponer un rediseño de PyPI, le sugiero que inicie una discusión en https://github.com/pypa/warehouse.

Gracias por las sugerencias.

Vea # 5571 - el PR para esto por qué esto se ha empujado a una versión posterior.

La advertencia en el registro de instalación de PIP da esta URL, pero no hay solución al problema ni aquí ni en los otros tickets mencionados.

Además, esto es aún más confuso: ¿a qué te refieres cuando dices PyPI? ¿Te refieres a cualquier servidor que implemente la interfaz PyPI (por ejemplo, Artifactory) o, específicamente, pypi.org?

Ahora, obviamente, alguien que quiera apoyar tanto la instalación de un paquete a través de setuptools (también conocido como ejecutando setup.py install ) como mediante el uso de pip install ahora estará en un aprieto. Especificar enlaces de dependencia es la única forma en que alguien en esta situación puede lidiar con múltiples paquetes interdependientes.

Ahora, corrígeme si me equivoco, pero hasta ahora parece que si eliminas esto en función de la decisión que PyPA haya tomado sobre las cargas a sus servidores, básicamente, harás que pip inútiles para los usuarios de Artifactory / empresas que tienen repositorios privados con paquetes interdependientes.

Por favor, dígame que me equivoqué y me perdí algo en toda esta historia (lo seguí de forma intermitente durante un tiempo). Rojo PEP 508, pero realmente no hace ninguna diferencia en este sentido, al menos, no puedo ver cómo mejoraría o empeoraría las cosas.

@ wvxvw-traiana Creo que te perdiste PR # 5571
Antes de ese PR (y en la versión actual - 18.0), pip se negará a instalar cualquier dependencia especificada a través de la sintaxis PEP508.

Después de ese PR (ya combinado, por lo que debería estar en 18.1+), pip solo rechazará tales dependencias si el paquete que depende de ellas proviene de pypi.org.

Si instala un paquete de su repositorio privado que depende de cosas de pypi, obviamente está bien.
Si instala un paquete de pypi.org que depende de cosas de su repositorio privado, eso falla.
Si instala un paquete de su repositorio privado que depende de cosas en su repositorio privado, está bien.

Espero que ayude a aclarar las cosas

@bstrdsmkr ¿Es el mismo origen o pypi es un caso especial? Es decir

Si instala un paquete de su repositorio privado que depende de cosas de un repositorio privado diferente.

Para agregar más contexto sobre las razones detrás de esto:

1. Los enlaces URL directos permiten que un paquete active la descarga y ejecución de código arbitrario desde cualquier lugar de Internet. Eso está bien si asume la responsabilidad de que el paquete lo haga, por lo que permitimos enlaces URL directos en ese entendimiento.
2. La gente espera instalar desde PyPI (específicamente PyPI, no los índices de paquetes en general) y confía en los paquetes que descargan desde allí. Para evitar un compromiso de un paquete PyPI que exponga a una gran cantidad de usuarios de Python, no permitimos que los paquetes que provienen de PyPI dependan de enlaces URL directos (porque impone demasiada carga a nuestros usuarios insistir en que tienen que auditar todo de PyPI que utilizan para enlaces a código externo).
3. Los enlaces de dependencia son un mecanismo específico de setuptools y son procesados ​​por la maquinaria interna de setuptools, no por pip. Entonces, a diferencia de los enlaces URL directos, no tenemos ningún control sobre lo que hacen. Es por eso que los desaprobamos en favor del formulario de URL directo estándar, que manejamos nosotros mismos.

alguien que quiera apoyar tanto la instalación de un paquete a través de setuptools (también conocido como ejecutar setup.py install) como mediante el uso de pip install ahora estará en un aprieto.

Si es cierto, eso se debe a que setuptools no ha implementado soporte para enlaces URL directos, que es un estándar acordado. Siéntete libre de plantear eso con ellos.

Si instala un paquete de su repositorio privado que depende de cosas de un repositorio privado diferente.

Eso funciona bien. PyPI no está involucrado.

Bien, por un lado, estoy feliz de que esto no me afecte.

Por otro lado, esta "solución" parece, cómo lo digo yo ... demasiado fácil de solucionar.

echo "not-pypi 151.101.61.63" >> /etc/hosts
pip install --index-url not-pypi

No es mi negocio, en realidad, pero parece un enfoque realmente superficial. (El otro vector de ataque se mencionó en otros comentarios, donde simplemente puede descargar lo que quiera en setup.py).

No está diseñado para que sea difícil para los usuarios solucionarlo. Es un medio de ofrecer una solución (limitada) al hecho de que PyPI aún no tiene una forma de impedir que las personas carguen paquetes con dependencias directas de URL. Consulte https://github.com/pypa/pip/pull/4175#issuecomment -266305694 para obtener algo de contexto.

@dpwrussell pypi.org es un caso especial. Cualquier repositorio privado a cualquier repositorio privado funciona bien después del cambio.

@ wvxvw-traiana no está destinado a evitar que lo haga usted mismo. Está destinado a evitar que otra persona te haga eso cuando crees que solo estás instalando un paquete de pypi.org

Sin relación con la discusión actual, reabriré esto ya que en realidad no hemos actualizado la advertencia de desaprobación para esto.

5726 agrega lenguaje que sugiere el uso de URL PEP 508, que en mi opinión es el último bit necesario para esto.

Muy bien entonces. Permítanme resumir:

• Los enlaces de dependencia aún están en desuso y ahora están programados para su eliminación en pip 19.0.
• El reemplazo con respaldo estándar para él son las dependencias de URL PEP 508
• Al instalar desde PyPI, si un paquete tiene dependencias de URL PEP 508, pip cancelará la instalación.

@pfmoore ha elaborado las razones de estas decisiones aquí: https://github.com/pypa/pip/issues/4187#issuecomment -415067034

@pradyunsg ¿ Cuándo se permitirán las dependencias de URL PEP 508 en install_requires en setup.py? ¿Hay una fecha fijada?

En el próximo lanzamiento de pip, eso es 18.1, programado para octubre. Puede leer más sobre el ciclo de lanzamiento de 3 meses de pip en https://pip.pypa.io/en/latest/development/release-process/. :)

https://github.com/pypa/wheel/issues/249 debe abordarse antes de que las dependencias de URL de PEP 508 se conviertan en una alternativa viable.

pypa / wheel # 249 debe abordarse antes de que las dependencias de URL de PEP 508 se conviertan en una alternativa viable.

Esto ha sido abordado.

En las notas de la versión de pip 18.1 dice

Permitir que los requisitos de URL de PEP 508 se utilicen como dependencias.

Como medida de seguridad, pip generará una excepción al instalar paquetes de PyPI si esos paquetes dependen de paquetes que no también están alojados en PyPI. En el futuro, PyPI bloqueará la carga de paquetes con dichas dependencias de URL externas directamente. (# 4187)

Entonces, esto básicamente significa que las dependencias se pueden especificar usando URL, pero si no son URL de PyPI, ¿el paquete no se puede instalar usando pip? Tal vez me esté equivocando por completo, pero ¿cómo se supone que se deben usar las dependencias de URL entonces?

Los paquetes de

Los paquetes que NO están alojados en PyPI pueden tener dependencias de URL. Si instala el paquete directamente desde github (por ejemplo), las dependencias de la URL se resolverán e instalarán. Un ejemplo de tal instalación:

pip install git+https://github.com/bstrdsmkr/some_package.git

Básicamente, si instala desde una URL, puede depender de las URL; de lo contrario, no. Y solo para mayor claridad, también puede tener dependencias de URL y no URL

Una pequeña adición:

... si instala desde una URL, puede depender de las URL

... si instala desde una URL (VCS o de otro modo) o un archivo local o un índice de paquete que no es PyPI, puede ...

Entonces, ¿hay una versión de pip que procese install_requires según las descripciones anteriores? No puedo descifrar las etiquetas de arriba cuál era el estado final y la documentación de pip actual apunta a la documentación install_requires en setuptools que todavía dice usar dependency_links .

No puedo hablar con los documentos por mí mismo, pero esta "relajación" para permitir que los paquetes que no son de PyPI instalen dependencias de las URL se lanzó en pip 18.0

AFAIK, las dependencias de URL en install_requires son compatibles desde pip 18.1:

Permitir que los requisitos de URL de PEP 508 se utilicen como dependencias.

Fuente: notas de la versión

Uf, error tipográfico de mi parte - @pietrodn es obviamente correcto

Quiero dejar un ejemplo pequeño pero exitoso aquí para aquellos que se encontraron por primera vez con este problema aterrorizados (como yo) sobre qué hacer con nuestros enlaces de dependencia de procesos. Usando este flujo de trabajo, mis usuarios ahora pueden instalar pip desde GitHub o desde fuentes locales (no PyPI), o pip install requirements.txt, o instalar python setup.py, y trabajar en Travis-CI, con pip versión 18+, así que creo que cubre muchas bases. Espero que sea útil para alguien, y mis disculpas si esto parece fuera de tema para otros:

En su archivo requirements.txt, asumiendo que desea que las personas puedan depender de la rama dev de GitHub del paquete "foo", por ejemplo:

scipy>=0.17
matplotlib>=2.0
foo @ git+https://github.com/foo-organization/foo@dev#egg=foo-9999

En su archivo setup.py:

import os, sys
from setuptools import setup, find_packages

def read_requirements():
    """Parse requirements from requirements.txt."""
    reqs_path = os.path.join('.', 'requirements.txt')
    with open(reqs_path, 'r') as f:
        requirements = [line.rstrip() for line in f]
    return requirements

setup(
    ..., # Other stuff here
    install_requires=read_requirements(),
    )

Algunos dirían que combinar install_requires y requirements.txt es aconsejable, y para una versión publicada, estoy de acuerdo, pero creo que esto funciona bien para el desarrollo.

Ah, genial. Entonces, si los paquetes "A" y "B" usan este método, y el paquete "A" enumera "B" como una dependencia, cuando vaya a instalar "A", en realidad termina procesando el archivo requirements.txt para "B". (que normalmente no sucede) - ¿es así?

También leí esta mañana que install_requires en sí era algo malo porque esas instalaciones fueron realizadas por setuptools, lo que significa que se ignoraron las opciones de pip, pero no sé si esa información está desactualizada ...

También leí esta mañana que install_requires en sí era algo malo porque esas instalaciones fueron realizadas por setuptools, lo que significa que se ignoraron las opciones de pip, pero no sé si esa información está desactualizada ...

Estás confundiendo install_requires con setup_requires .

Ah, genial. Entonces, si los paquetes "A" y "B" usan este método, y el paquete "A" enumera "B" como una dependencia, cuando vaya a instalar "A", en realidad termina procesando el archivo requirements.txt para "B". (que normalmente no sucede) - ¿es así?

@stevebrasier Sí, creo que sí, lo que podría ser un problema si ha anclado diferentes versiones de otros paquetes requeridos en A que en B.

Hola chicos, solo quiero señalar que el camino de la desaprobación en este caso fue demasiado corto. Sé que los enlaces de dependencia se han marcado como obsoletos durante bastante tiempo, pero las URL PEP 508, que pueden usarse para reemplazarlos, no se han implementado hasta la 18.1. Como resultado, solo hubo una ventana de 3 meses para cambiar de los enlaces de dependencia a los requisitos de URL, que es muy poco tiempo para proyectos grandes.

@rgerkin Hola, estoy tratando de seguir tus instrucciones en vano.

Buscando PACKAGE @ git + ssh: //[email protected] : OWNER / PACKAGE. git @ SUCURSAL
Leyendo https://pypi.org/simple/PACKAGE/
No se pudo encontrar la página de índice para "PAQUETE" (¿tal vez esté mal escrito?)
Índice de escaneo de todos los paquetes (esto puede llevar un tiempo)
Leyendo https://pypi.org/simple/

PAQUETE @ git + ssh: //[email protected] : PROPIETARIO / PAQUETE. git @ BRANCH , esto está en install_requires.

¿Tiene una idea de por qué obtengo lo anterior?

@KevinMars Hay algunas diferencias entre mi ejemplo y lo que tienes, incluido el uso de git_ssh, bitbucket, sufijo a.git, una rama con nombre y ninguna etiqueta de versión. Quizás una o más de esas cosas están llevando a pip a buscar en PyPI en lugar de en su URL. ¿Qué versión de pip estás usando?

Para comentar algo que encontré: Usar setup.py para instalar el paquete con python setup.py install todavía requiere declaraciones de dependencias externas en dependency_links .

En su archivo setup.py:

import os, sys
from setuptools import setup, find_packages

def read_requirements():
    """Parse requirements from requirements.txt."""
    reqs_path = os.path.join('.', 'requirements.txt')
    with open(reqs_path, 'r') as f:
        requirements = [line.rstrip() for line in f]
    return requirements

setup(
    ..., # Other stuff here
    install_requires=read_requirements(),
    )

@rgerkin Gracias por compartir esta solución. Pero, ¿qué pasa si estoy usando pbr para configurar mi paquete de Python? ¿Cómo adaptar esto para que se ajuste a pbr?

@KevinMars Tengo

Me acabo de dar cuenta de que los enlaces de dependencia de procesos ya no existían. Estoy agradecido por todo el trabajo que hace la comunidad. Tratar de justificar la decisión en discusiones interminables y un laberinto de cierre de problemas y redirección fue la solución elegida, pero sigo pensando que dejar esta opción no habría perjudicado a nadie.