Pipenv: Actualizar solo una dependencia bloqueada

Eso también podría ser útil para pipenv install , ya que a veces quiero instalar una nueva dependencia sin actualizar otras.

Aquí hay una pequeña cosa a tener en cuenta: cambiar una sola dependencia podría cambiar el conjunto general de requisitos.
Ej .: Actualizar foo de 1.0 a 2.0 podría requerir actualizar bar a> = 2.0 (mientras que antes era <2.0), y así sucesivamente.

Sé que en el contexto de pip-tools sí mismo (del cual pipenv toma su algoritmo de resolución de dependencia), ejecutar la resolución de dependencia solo "actualizará" los paquetes requeridos cuando se "vuelva a bloquear" si hay un archivo de bloqueo existente. Lo hace verificando si los pines existentes en el archivo de bloqueo son candidatos válidos primero al seleccionar el candidato en la resolución. pipenv probablemente podría hacer lo mismo.

Creo que es una idea razonable. De lo contrario, si desea actualizar absolutamente solo una dependencia, pipenv tendría que tener un modo para bloquear si cambiar una dependencia causa otros cambios, o de lo contrario perdería la garantía de un entorno válido.

¡Espero que esto ayude!

De hecho, eso fue lo que quise decir con:

Eso generaría un Pipfile.lock con actualizaciones solo para my-awesome-dep y sus dependencias.

De acuerdo al 100%, iré un poco más lejos: este debería ser el valor predeterminado.

Es decir, pipenv install foo nunca debe tocar nada más que foo y sus dependencias. Y pipenv lock ciertamente nunca debería actualizar nada, solo debería bloquear lo que ya está instalado.

AFAICT, así es como funcionan npm , yarn , gem , etc. No tiene sentido tener un archivo de bloqueo que en realidad no bloquee los paquetes, pero confía en que los autores de los paquetes no rompan las cosas en las versiones de parches y, por lo tanto, los actualice sin que se lo pidan. Puedo ver el uso de permitir actualizaciones, pero eso debería ser opcional, ya que es más sorprendente que no actualizarlas.

Me disculpo si me estoy apropiando de este problema para otra cosa, pero dado que está tan estrechamente relacionado con un problema que estaba a punto de crear, pensé en comenzar la conversación aquí. No dudes en decirme que debería hacer uno nuevo.

También encontré este problema relacionado: https://github.com/kennethreitz/pipenv/issues/418

Ser capaz de especificar pipenv install --upgrade-strategy=only-if-needed parece lo que estoy buscando, aunque, por supuesto, como mencioné, creo que debería ser el valor predeterminado, ya que se está convirtiendo en pip 10. Pero poder especificarlo de forma semipermanente env var sería algo, de todos modos.

Me sorprendería que ese cambio rompa el flujo de trabajo de alguien (las famosas últimas palabras ), ya que es más conservador que --upgrade-strategy=eager .

Intenté solucionar esto configurando export PIP_UPGRADE_STRATEGY=only-if-needed en mi configuración de shell. Esto no funciona y pipenv lock exhibe estos comportamientos sorprendentes:

1. "Actualiza" los paquetes que no necesitan actualizarse (pero ...)
2. ¡En realidad, no actualiza las versiones instaladas! es decir, pip freeze y Pipfile.lock muestran diferentes versiones!

Adivinar que pipenv está delegando a pip para la instalación, y pip respeta la configuración de las variables de entorno, pero pipenv lock no.

@ k4nar ¿Qué pasa ahora mismo que te

@brettdh Creo que puedo arrojar algo de luz porque tienes la mayoría de las piezas. pipenv lock no instala nada y no pretende hacerlo. Solo genera el archivo de bloqueo dado su entorno de host, versión de Python y un Pipfile . Si manipula su entorno de alguna otra manera o si usa pip directamente / manipula la configuración de pip fuera de pipenv / no está usando pipenv run o usando pip freeze dentro de una subcapa de pipenv, es bastante fácil para un archivo de bloqueo para estar desincronizado desde pip freeze . Los dos no están realmente relacionados.

Para ser claro:

1. Pipfile.lock es una resolución de dependencia estrictamente fija que usa el solucionador de herramientas pip basado en el usuario Pipfile
2. Si desea mantener pines estrictos de todo mientras actualiza solo un paquete, creo que puede hacerlo fijando estrictamente todo en su Pipfile excepto la única cosa que desea actualizar (corríjame si me equivoco @vphilippon)

En cuanto a su archivo de bloqueo y pip freeze desacuerdo entre sí, tendría que saber más información, pero creo que tenemos un problema abierto con respecto a nuestro solucionador de archivos de bloqueo cuando usamos versiones de Python que no son del sistema para resolverlo.

@techalchemy : Si tengo un Pipfile.lock con A, B y C donde B es una dependencia de A, me gustaría poder actualizar A y B sin actualizar C, o C sin actualizar A y B.
Nuevamente, por supuesto, puedo anclar todas mis dependencias y sus dependencias en mi Pipfile para hacer eso, pero sería una carga de mantener (como la mayoría de requirements.txt son).

Estoy de acuerdo con todo lo que escribió
todo en requirements.txt y no use pipenv. El punto de pipenv es
tener una herramienta que haga eso (y las cosas virtualenv, por supuesto)
más simple de administrar; es decir, todos los paquetes están bloqueados por defecto a una versión
que se sabe que funciona, pero debería ser sencillo actualizar una selección
pocos (sin actualizar inesperadamente otros).
El jueves 26 de octubre de 2017 a las 4:28 a. M. Yannick PÉROUX [email protected]
escribió:

@techalchemy https://github.com/techalchemy : Si tengo un Pipfile.lock
con A, B y C donde B es una dependencia de A, me gustaría poder
actualice A y B sin actualizar C, o C sin actualizar A y B.
Nuevamente, por supuesto, puedo anclar todas mis dependencias y sus dependencias en mi
Pipfile para hacer eso, pero sería una carga mantener (como
la mayoría de requirements.txt son).

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kennethreitz/pipenv/issues/966#issuecomment-339591307 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAFlnqUOEKARiFD8kEk3GVczF3NXBdVOks5swEKcgaJpZM4QEf--
.

Hm, veo lo que están diciendo. La premisa de pasar una configuración a pip no es lo que me preocupa, lo que me preocupa es resolver con pip-tools. ¿Cómo se ve este comportamiento en este momento?

@techalchemy Mencioné la diferencia pip freeze como una abreviatura de "las versiones del paquete que pipenv install instala difieren de las versiones del paquete que pipenv lock ahorra en Pipfile.lock ".

Es cierto, esto solo sucede cuando cambié los argumentos predeterminados de pip a través de la variable de entorno; Solo estaba señalando que era sorprendente que pipenv delegara en pip para la instalación pero no para el bloqueo de la versión; es decir, en lugar de bloquear lo que está instalado, bloquea lo que cree que debería instalarse, potencialmente con actualizaciones no solicitadas.

¿Podrías aclarar un poco tu pregunta? Creo que "resolver con pip-tools" se refiere a lo que está haciendo pipenv lock , y ¿la razón por la que no se ve afectado cuando establezco pip por defecto? ¿Y podría ser más específico sobre lo que quiere decir con "este comportamiento"?

@brettdh El mecanismo de bloqueo incluye una noción de "resolución de dependencia" que no existe en pip . Es manejado por pip-tools (o mejor dicho, una versión parcheada, integrada de una manera especial por pipenv que trae algunas diferencias con la herramienta original). En resumen, el mecanismo de bloqueo lee Pipfile y realiza una resolución de dependencia completa para seleccionar un conjunto completo de paquete que cumplirá con todas las restricciones definidas por los paquetes requeridos y sus dependencias .

@techalchemy

[...] se está resolviendo con pip-tools lo que me preocupa.

No estoy seguro de cómo esos --upgrade-strategy afectarían a pip-tools , porque funciona en algunos componentes internos de bajo nivel de pip . Tengo la sensación de que esto no daría el resultado esperado, ya que estas opciones toman en cuenta lo que está instalado, y eso no es lo que se trata en ese mecanismo. Pero tenemos otro enfoque para esto en pip-tools que podría hacerse aquí.

El comportamiento "original" de pip-tools es que solo actualiza lo que se necesita en el archivo de bloqueo (en su contexto, son los requisitos.txt), pero esto se "perdió" en la forma en que el resolutor se integró en pipenv . Déjame explicarte por qué.

Señalando mi currículum de cómo funciona pip-tools : https://github.com/kennethreitz/pipenv/issues/875#issuecomment -337717817
¿Recuerda la parte "seleccione un candidato"? Eso se hace consultando el objeto Repository .
En pipenv , configuramos directamente un PyPIRepository para el Resolver , pero pip-tools hace otra cosa, usa un objeto LocalRequirementsRepository , que mantiene los pines existentes de los requirements.txt previamente existentes (si se encuentran), y "fallbacks" en PyPIRepository .

Entonces, en pip-tools , sucede lo siguiente al seleccionar un candidato:

1. Consultar LocalRequirementsRepository por un candidato que coincida con foobar>=1.0,<2.0 .
2. Compruebe si un pin existente cumple con esos requisitos:
   
   
   
   • En caso afirmativo, devuelva ese pin como candidato.
   
   
   • De lo contrario, consulte el proxied_repository ( PyPIRepository ) del candidato.
   
   
3. Utilice el candidato devuelto

Efectivamente, significa que a los pines existentes se les da una "prioridad" como candidatos para probar primero.

Pero en pipenv , actualmente, simplemente:

1. Consulte PyPIRepository (directamente) para un candidato que coincida con foobar>=1.0,<2.0 .
2. Utilice el candidato devuelto.

Entonces, creo que el mismo comportamiento para el bloqueo en pipenv podría realizarse analizando Pipfile.lock para obtener los pines existentes y usar un LocalRequirementsRepository , como pip-tools hace en su comando pip-compile .

@vphilippon , ¿tiene una idea de lo difícil que sería la implementación?

@techalchemy

• Analizando Pipfile.lock para extraer los pines existentes: no he mirado eso. Depende de cómo estén estructuradas las cosas en pipenv . Necesitamos un conjunto de InstallRequirements que represente los pines en el Pipfile.lock .
• Usando LocalRequirementsRepository : Bastante fácil: cambie nuestro PyPIRepository actual por un LocalRequirementsRepository .

Pero, mientras estoy investigando esto, y siguiendo los comentarios de @brettdh , me doy cuenta de algunas cosas:

1. El comportamiento predeterminado actual de pipenv install no coincide con el comportamiento de pipenv lock . Hacer pipenv install requests solo no actualizará requests si sale una nueva versión (muy parecido a pip install ). Sin embargo, hacer pipenv lock actualizará Pipfile.lock con la última versión de requests que coincida con el especificador Pipfile y las restricciones de dependencia.
   Hay 2 formas principales de ver esto:
   
   
   
   • A) El Pipfile.lock debe permanecer lo más estable posible de forma predeterminada, sin cambiar los pines a menos que sea necesario, para permanecer como el entorno actual, y solo cambiar en caso de que cambiemos el entorno.
   
   
   • B) El Pipfile.lock debe obtener las versiones más recientes que respeten las restricciones / dependencias del entorno para poder beneficiarse libremente de los rangos abiertos en las dependencias Pipfile y lib, permitiendo adquirir continuamente nuevas versiones compatibles en tu entorno. Luego puede ejecutar pipenv update para beneficiarse del bloqueo nuevo.
   
   

IMHO, I would align the default behavior, which would be to go with A) by default. Because right now, everytime a lock is performed (i.e. after each installation), new versions can come in, which make the lockfile *drive the update of the environment*, which seems weird. But, this is arguable of course. While in development, I might want to continuously update my requirements to no get stale, like with B), so that should also be easily doable.

1. Incluso si usamos LocalRequirementsRepository para evitar actualizar los pines existentes correctos y terminamos alineando los comportamientos predeterminados, entonces debemos abordar el equivalente de --upgrade y --upgrade-strategy para la parte de bloqueo . Actualmente, definir alguna variable de entorno (como PIP_UPGRADE y PIP_UPGRADE_STRATEGY ) afectará el comportamiento de pipenv install , pero no afectará a pipenv lock , ya que no afecta el comportamiento de pip-tools (lo confirmé, ya que no estaba seguro al principio).
   De lo contrario, no habrá forma de actualizar el entorno sin eliminar el Pipfile.lock (se siente torpe y "todo o nada") o sin requerir una versión más nueva (me refiero a hacer un pipenv install requests>2.18.4 explícito, lo que requiere que sepa que hay una nueva versión, y cambia el especificador en el propio Pipfile , aumentando el límite inferior), lo cual es incorrecto. Como el "original pip-tools " no difiere a pip para lidiar con esto (ya que no está relacionado con lo que está instalado actualmente), ofrece una opción para especificar las dependencias para actualizar en el lockfile, y simplemente elimine los pines para estos paquetes (o todos) de la lista existing_pins, recurriendo efectivamente a la consulta de PyPI. No estoy seguro de cómo podemos hacer coincidir la noción de "--upgrade-strategy" con esto.

@techalchemy
Entonces, mientras decía que era bastante fácil simplemente "alinear el comportamiento predeterminado", ahora me doy cuenta de que esto causaría un problema importante para poder actualizar los paquetes (como en: simplemente busque la última versión que coincida con mis restricciones actuales) .

Si hay algo que no está claro, pregunte, se realizaron muchas ediciones al escribir esto.

(La resolución de dependencias no es fácil. Una buena y práctica resolución de dependencias es incluso peor 😄)

@vphilippon eso es exactamente lo que quise decir. Mantener las cosas que pip instala sincronizadas con las cosas que pip-tools resuelve no es trivial a menos que conduzca el proceso hacia atrás, utilizando el archivo de bloqueo resuelto para realizar la instalación. Estoy bastante seguro de que por eso las cosas se diseñaron de la forma en que estaban.

B) El Pipfile.lock debe obtener las versiones más recientes que respeten las restricciones / dependencias del entorno para poder beneficiarse libremente de los rangos abiertos en las dependencias Pipfile y lib, lo que le permitirá adquirir continuamente nuevas versiones compatibles en su entorno. A continuación, puede ejecutar pipenv update para beneficiarse del bloqueo nuevo.

Este flujo de trabajo posiblemente funcione con la configuración actual. Puede usar pipenv lock para generar un archivo de bloqueo, pero pipenv update reinstalará todo el entorno. Estoy bastante seguro de que podemos usar uno de nuestros varios formatos de salida para resolver el gráfico de dependencia (ya tenemos un formato json, como saben) y solo reinstalar cosas que no se alinean con el archivo de bloqueo. Esto podría ser más sensato, pero tendría curiosidad por la entrada de @nateprewitt o @erinxocon antes de tomar una decisión.

@vphilippon Totalmente de acuerdo en que A y B son flujos de trabajo deseables en diferentes situaciones. Algunos de su redacción en torno B me confundió un poco, sin embargo, parecía decir que pipenv lock podría resultar en un fichero de bloqueo que en realidad no coincide con el medio ambiente - en particular me oyó esto en que habría que "run pipenv update para beneficiarse de la cerradura nueva ", como si la cerradura estuviera" por delante "del entorno en lugar de coincidir con él.

Independientemente de si está en un flujo de trabajo A o en un flujo de trabajo B, algunas cosas me parecen constantes, y creo que esto también cuadra con lo que dice @techalchemy :

• El resultado de pipenv lock siempre debe ser un archivo de bloqueo que coincida con el entorno.
• El resultado de pipenv install siempre debe ser un entorno que coincida con el archivo de bloqueo.

Estoy ignorando los detalles de implementación, pero ese es el comportamiento básico que espero de un administrador de paquetes con una función de archivo de bloqueo.

Ejecutar pipenv update periódicamente le permite permanecer en modo B siempre que desee que todo esté actualizado, y tener la capacidad de pipenv install --upgrade requests permitiría actualizaciones específicas de un paquete y sus dependencias, sin afectar los paquetes que no necesitan actualizarse innecesariamente.

¿Me faltan algunos casos de uso? Puedo pensar en optimizaciones para B, por ejemplo, una bandera o env var que le dice que siempre se actualice con entusiasmo, pero creo que eso cubre lo básico. También sé que estoy recauchutando terreno que ya has cubierto; me resulta útil asegurarme de que entiendo de qué estás hablando. :)

Sin embargo, algunas de sus frases alrededor de B me confundieron un poco, pareciendo decir que el bloqueo de pipenv podría resultar en un archivo de bloqueo que en realidad no coincide con el entorno

@brettdh esto es correcto - el pip-tools que usamos para generar Pipfile.lock no le pide al virtualenv una lista de los paquetes que se han instalado. En cambio, compila una lista de paquetes que cumplen con los criterios especificados en la lista de pines del Pipfile . Debido a que el resolutor en sí se ejecuta usando el sistema o la instalación externa de python / pipenv / pip-tools, estamos haciendo una mierda suprema para convencerlo de que resuelva paquetes con la misma versión de python utilizada en virtualenv. La suposición sería que pip install resolvería las cosas de manera similar, pero ese no es siempre el caso, aunque ni siquiera estoy 100% seguro de eso. Pero sí, pipenv lock no se genera en base a virtualenv, se genera en base a Pipfile . Es un archivo de bloqueo de resolución de dependencia, no un pin de estado del entorno.

Como una posible resolución a esto: algo que pip en sí mismo admite actualmente, pero pip-compile no lo hace, es la noción de un archivo de restricciones.

Un archivo de restricciones se diferencia de un archivo de requisitos en que dice " Si este componente está instalado, entonces debe cumplir con esta restricción de versión". Sin embargo, si un paquete en particular en el archivo de restricciones no aparece en el árbol de dependencias en ninguna parte, no se agrega al conjunto de paquetes que se instalarán.

Esta es la característica que falta actualmente en pipenv , ya que las entradas deseadas para la generación Pipfile.lock son:

1. El contenido actualizado Pipfile como un nuevo archivo de entrada de requisitos
2. El conjunto completo de dependencias existentes de Pipfile.lock como un archivo de restricciones, excluyendo los paquetes específicamente nombrados en el comando actual

El soporte de archivos de restricciones en el nivel de resolución de herramientas pip sería suficiente para que pipenv admitiera un modo en el que los intentos de actualización implícita de dependencias fallarían como una violación de restricción, lo que permitiría al usuario decidir si deseaba agregar o no ese paquete al conjunto que se está actualizando.

actualmente no es compatible, gracias por los comentarios

@kennethreitz

Quieres decir:

1. Este comportamiento debería cambiarse, pero actualmente no es una prioridad,
2. Este comportamiento debe agregarse como algo opcional, pero actualmente no es una prioridad, o
3. ¿Este comportamiento no debería agregarse?

Este es un inconveniente suficiente dada la inconsistencia con la forma en que funcionan otros administradores de paquetes de bloqueo similares, por lo que sería bueno mantenerlo abierto como una solicitud para los RP.

Si, en cambio, es (3), y esto no se agregará, entonces creo que algunos de nosotros en el tema tendremos que ajustar nuestros planes para nuestra elección de herramientas de administración de paquetes de Python.

Quiero decir que esto no es compatible actualmente y agradezco los comentarios.

Entiendo que no es compatible. ¿También está diciendo que no aceptaría que los RP cambien este comportamiento o lo agreguen como una opción?

No tengo idea.

¿@ k4nar todavía está interesado en hacer un PR para esto? Específicamente, algo como pipenv install --only <dep-to-update que evita que se actualicen deps no relacionados. Dado que @kennethreitz parece no estar interesado en seguir discutiendo, me parece que esa es la única forma de averiguar si esa adición / cambio de comportamiento podría ser aceptable (y, por extensión, si la gente como @taion y yo podemos seguir usando pipenv).

Estoy interesado, pero no estoy seguro de saber cuál sería la mejor manera de implementar esto. Hay muchos componentes en acción (pip, pip-tools, pipfile, pipenv…) y probablemente muchas soluciones posibles.

Según https://github.com/kennethreitz/pipenv/issues/966#issuecomment -339707418, debería ser relativamente sencillo. Esa lógica de resolución de dep es en gran parte solo de pip-tools. Estaba planeando enviar un PR, pero no puedo justificar gastar el trabajo si no estamos dispuestos a hablar sobre cómo queremos que se vea la API antes de dedicar tiempo a escribir código.

Actualmente estoy buscando adoptar un enfoque alternativo, ya que Pipfile es un estándar, las interacciones con él no necesitan pasar por pipenv, y me gustaría solucionar algunas de las otras semánticas extrañas aquí, como borrar virtualenvs existentes por https : //github.com/kennethreitz/pipenv/issues/997.

Lamento comentar sobre un problema cerrado, pero me gustaría señalar que, a mi entender, el uso de pipenv en mis proyectos actualmente requiere un flujo de trabajo como este:

pipenv install foo
vim Pipfile.lock  # Manually remove all the unwanted updates
git add && git commit && git push

Me resulta realmente molesto tener que comunicar esto a los miembros de mi equipo. La alternativa parece ser anclar todo a las versiones exactas en Pipfile , pero eso frustra gran parte del propósito de usar pipenv en primer lugar.

IIUC, este comportamiento es el equivalente de apt realizando un apt dist-upgrade implícito siempre que ejecute apt install foo .

Esto se agrava por el hecho de que pipenv install actualiza las cosas en Pipfile.lock , pero no instala las actualizaciones en el virtualenv local. Si el desarrollador no examina cuidadosamente la diferencia de Pipfile.lock , todavía están usando las versiones anteriores localmente, pero una vez que comparten el código, todos los demás entornos ven las actualizaciones sorprendentes. La gente tiende a ignorar la diferencia de Pipfile.lock porque se considera un archivo generado automáticamente.

Estoy firmemente convencido de que "actualizar todo a la última versión permitida por Pipfile " debería ser una operación solicitada explícitamente que sea independiente de "install foo".

debe ser arreglado en maestro

El comportamiento todavía está presente, lo probé en pipenv 11.8.3 , @kennethreitz.

@ marius92mc El --selective-upgrade y --keep-outdated agregadas en versiones recientes: https://docs.pipenv.org/#cmdoption -pipenv-install-keep -anticuado

Eso permite a las personas que necesitan o desean más control sobre exactamente cuándo ocurren las actualizaciones optar por ese comportamiento, mientras que el comportamiento predeterminado sigue respetando OWASP A9 y presionando para obtener actualizaciones ansiosas en cada oportunidad.

@ncoghlan Creo que una cosa que se necesita (fácil de pedir, no tan fácil de hacer) es una pregunta frecuente sobre _cómo_ se comportan esas opciones (al menos sigue siendo confuso para mí).

Por ejemplo: el uso de --selective-upgrade y --keep-outdated seguirá causando que las bibliotecas desactualizadas en Pipfile.lock se actualicen, si no están directamente relacionadas con el paquete "seleccionado" que se actualizará .

Entonces parece que puede haber errores de implementación.

Están pensados ​​para dejar el archivo pipfile.lock como está, excepto por el nuevo cambio.

Avíseme si es útil proporcionar un Pipfile + .lock de prueba.

Creo que ha proporcionado suficiente información para que investiguemos. Intentaré hacer eso ahora.

En realidad, su pipfile / lock sería genial, si contiene resultados desactualizados.

@ncoghlan , gracias por
Intenté de nuevo con las opciones mencionadas y el resultado parece ser el mismo, todavía actualiza los otros paquetes también, cambiándolos en el archivo Pipfile.lock .

@kennethreitz https://github.com/simonpercivall/pipenv-selective-upgrade-test

¿Hay alguna actualización sobre este tema, @kennethreitz?

Perdón por las lentas respuestas a esto. Todavía no hemos identificado la causa raíz de la regresión aquí (sé que personalmente he estado manejando una migración del centro de datos este fin de semana, así que he sido un poco lento) pero solucionaremos esto en los próximos días.

¡Contribuciones bienvenidas como siempre!

Creo que falta un caso de uso que puede usar este mismo cambio: cuando estoy desarrollando una aplicación, a menudo necesito actualizar la versión de una sola dependencia. Los pasos que me gustaría seguir son:

1. Actualice la restricción de versión para la dependencia en setup.py
2. Ejecute pipenv lock --selective-upgrade ; pipenv sync o pipenv install --selective-upgrade "-e ."

@wichert Si Pipfile se ha editado de una manera que aumenta la versión mínima requerida más allá de lo que está en el archivo de bloqueo actual, entonces --keep-outdated ya debería cubrir lo que necesita. --selective-upgrade es para el caso en el que Pipfile no ha cambiado, pero desea actualizar a una nueva versión anclada de todos modos.

@ncoghlan Pipfile no ha cambiado en este escenario, solo setup.py al cambiar el requisito de versión mínima para una dependencia, generalmente a algo más reciente y actualmente en Pipfile.lock .

@wichert pipenv no captura cambios en su setup.py automáticamente porque no son herramientas de configuración. Tienes que ejecutar pipenv lock si quieres que eso suceda.

¿Cuál es el estado actual de esto? El 25 de marzo, alguien dijo que pensaba que los problemas de implementación se resolverían "en los próximos días", y otros informes de errores se han cerrado debido a que se han rastreado aquí; pero a partir de 2018.7.1 todavía veo el error informado por Simon Percivall (las dependencias indirectas siempre se actualizan) y ese error no se ha discutido desde el informe original. ¿Se sigue rastreando el problema?

(Actualmente vivo en una ciudad de segundo nivel en Senegal, por lo que mi Internet es terrible y sería un cambio de juego no volar mi límite de datos al actualizar las dependencias indirectas si es posible: P)

PD: Gracias por hacer Pipenv, es increíble <3

Si por su puesto. Estamos reescribiendo el resolutor para que sea compatible con esto ahora mismo. Queda por ver si aterriza en esta versión o en la próxima

No estoy tan seguro de mi habilidad de codificación para estimar cuándo aterrizaría el solucionador: p En serio, este es un proyecto completamente voluntario y no tenemos un mecanismo de fecha límite como lo haría en entornos comerciales (ni siquiera tenemos un jefe o un gerente de proyecto o lo que sea que tenga en su empresa que decida cuándo se debe hacer algo). Si desea que se haga algo en el plazo que desee, debe hacerlo usted mismo o, al menos, proporcionar una motivación real para que otros lo hagan.

@uranusjr FWIW, no vi ninguna demanda de conveniencia en el comentario de @benkuhn anterior, solo una pregunta sobre dónde están las cosas; es decir, qué trabajo se ha realizado para que los observadores externos puedan hacer sus propias estimaciones / decisiones.

Entiendo que pipenv es un proyecto voluntario y que los no contribuyentes no pueden pedir que se haga algo antes de una fecha sin registrarse para que suceda. Me pregunto si hay espacio para más transparencia en el proceso de desarrollo del proyecto o si simplemente no estoy buscando en los lugares correctos. Por lo general, la respuesta es "si el problema no se ha actualizado, no ha habido movimiento" o "mira esta solicitud de extracción de WIP", pero este problema en particular parece haber provocado un esfuerzo mucho mayor, por lo que los puntos pueden ser difíciles para conectar para aquellos que no están directamente involucrados.

Como siempre, muchas gracias a usted y a todos los que dedican su valioso tiempo a la mejora de pipenv. 👏

Por supuesto, este no tiene actividad o un PR en progreso porque es mucho más complicado que eso. Hablamos internamente principalmente sobre cómo queremos estructurar esto con respecto al proyecto más grande, y trabajamos iterativamente para establecer un enfoque que incluso podría comenzar a funcionar correctamente. Una vez que podamos resolver eso, podemos construir una lógica de resolución.

Mientras tanto, la pila de resolución en pipenv es súper complicada y no me sentiría cómodo pidiéndole a la gente que invierta demasiado esfuerzo tratando de desenredarlo para este propósito. Incluso el caso de uso más simple aquí requerirá una refactorización significativa. Estaremos encantados de revisar / discutir cualquier refactorización propuesta si alguien está interesado en ayudar a abordar esto, pero las dos cosas están estrechamente relacionadas.

Si alguien tiene experiencia en resolución de dependencias y resolución de satélites, ciertamente estaríamos interesados ​​en recibir información, pero todavía no hay una sola idea concreta. Hemos pasado por varias iteraciones que nunca planeamos llevar adelante como más que una prueba de concepto. No todo el código se convierte en un PR, y no todas las decisiones de organización del código ocurren en el rastreador de problemas. A veces charlamos sincrónicamente y proponemos y desechamos ideas en tiempo real.

Algo que iba a sugerir como un flujo de trabajo alternativo que podría abordar esto es facilitar la fijación a una versión específica en el _Pipfile_ al instalar.

Creo que es un poco sorprendente, pero no completamente irrazonable, que pipenv interprete foo = "*" en el sentido de "Solo necesito asegurarme de que _alguna_ versión de foo esté instalada, al usuario no le importa cuál". Con ese fin, tener algo como pipenv install --pin foo que da como resultado foo = "==1.2.3" lugar de foo = "*" en el Pipfile (donde 1.2.3 es la última versión actual de foo) parece que podría ayuda.

Sin embargo, el problema con esto es que el comportamiento de muchos paquetes puede cambiar mucho según sus dependencias (por ejemplo, la misma versión de pylint puede hacer cosas totalmente diferentes dependiendo de la versión de astroid que esté usando), y los paquetes no fijar sus propios departamentos exactamente. Así que no creo que esto lleve a nadie muy lejos. : /

(Me acabo de dar cuenta de que he estado comentando el problema equivocado. Perdón por el lío, ignórame) 😞

Un caso de uso real con el que he luchado durante algunas horas: quiero medir la cobertura de prueba en un proyecto de Django 2.0. Incluso pipenv install --keep-outdated --selective-upgrade --dev coverage insiste en actualizar el paquete Django que no es de desarrollo a la versión 2.1, que debido a roturas en otros lugares no puedo usar todavía. Realmente debe haber una manera de cambiar el conjunto de paquetes instalados sin actualizar paquetes completamente no relacionados a versiones posiblemente rotas. Siempre existirá la posibilidad de rotura en la última versión.

Intentaré la solución de @rfleschenberg , pero no sé si tener una propiedad _meta hash presuntamente incorrecta romperá algo.

@ l0b0 Si su aplicación realmente no puede manejar una versión particular de Django, creo que tiene sentido establecer esa restricción en su Pipfile.

@AlecBenzer Eso me suena a algo para setup.py.

@wichert Eso también podría tener sentido (en realidad, no estoy del todo claro en qué circunstancias le gustaría tener un setup.py y un Pipfile), pero si tiene una línea en su Pipfile que dice:

Django = "*"

le estás diciendo a pipenv que quieres que instale _cualquier_ versión de Django. Si lo que realmente quiere que haga es instalar 2.0 o una versión anterior, dígale que en su lugar:

Django = "<=2.0.0"

Si bien en este caso particular pipenv está actualizando Django sin una razón real, podría ser que en algún momento intentes instalar un paquete que requiera Django> 2.0.0, momento en el que pipenv lo instalará felizmente si no lo has dicho es lo que necesita <= 2.0.0.

Si lo que realmente quiere que haga es instalar 2.0 o una versión anterior, dígale que en su lugar

@AlecBenzer reflexionando, ahora se me ocurre que esto es lo que hace npm / yarn por defecto cuando instala un paquete; encuentran la última versión major.minor y especifican ^major.minor.0 en package.json, lo que evita actualizaciones inesperadas de versiones principales, incluso cuando se solicita explícitamente una actualización a la última. Me pregunto si Pipenv debería hacer lo mismo, pero ese sería un tema aparte.

Por supuesto, su archivo de bloqueo también evita actualizaciones accidentales incluso de versiones menores y de parche, que es lo que se solicita aquí.

Creo que se ha discutido anteriormente y en otros lugares, pero hay una tensión / compensación en el espacio de diseño entre npm / yarn y pipenv. Cualquier administrador de paquetes aparentemente tiene estos objetivos, con alguna prioridad relativa:

• Facilite la instalación y actualización de paquetes
• Haga que sea difícil romper accidentalmente su aplicación con una actualización de dependencia errante

El problema de anclar una versión exacta en el Pipfile es que luego es más difícil actualizar los paquetes; por eso existe pip-tools (aunque es para requirements.txt).

La bandera --keep-outdated no parece funcionar como se esperaba, como se indicó cuando se volvió a abrir el problema. Si ese comportamiento debería o no ser el predeterminado y cómo se alinea con otros administradores de paquetes, no es realmente el problema central aquí. Arreglemos la cosa primero.

@brettdh

reflexionando, ahora se me ocurre que esto es lo que hace npm / yarn por defecto cuando instalas un paquete; encuentran la última versión major.minor y especifican ^ major.minor.0 en package.json, lo que evita actualizaciones inesperadas de versiones principales, incluso cuando se solicita explícitamente una actualización a la última. Me pregunto si Pipenv debería hacer lo mismo, pero ese sería un tema aparte.

Sí, está en la línea de lo que estaba tratando de sugerir en https://github.com/pypa/pipenv/issues/966#issuecomment -408420493

¡Realmente emocionado de saber que se está trabajando en esto!

Mientras tanto, ¿alguien tiene una solución alternativa sugerida que sea menos laboriosa y propensa a errores que ejecutar pipenv lock y revertir manualmente los cambios resultantes del archivo de bloqueo que no quiero aplicar?

@benkuhn No que yo sepa, hago el mismo bloqueo y vuelvo a bailar todo el tiempo.

Ah, está bien, al menos a veces puedes evitar la reversión manual:

1. pipenv lock
2. git commit -m "FIXME: revert"
3. pipenv install packagename
4. git commit -m 'Add dependency on packagename'
5. git rebase -i
6. Elimina el compromiso FIXME: revert

Desafortunadamente, todavía es posible crear un Pipfile.lock inconsistente si su Pipfile.lock comienza con una versión de un paquete que es demasiado antiguo para satisfacer los requisitos de packagename , pero quizás pipenv se quejará sobre esto si pasa?

--keep-outdated parece mantener sistemáticamente desactualizadas solo las dependencias explícitas que están especificadas (no fijadas) en Pipfile, mientras que todas las dependencias implícitas se actualizan.

¿Estoy en lo cierto de que no es posible actualizar / instalar una dependencia única usando pipenv==2018.7.1 sin actualizar otras dependencias? Probé diferentes combinaciones de --selective-upgrade y --keep-outdated sin éxito.

Editar Pipfile.lock manualmente no es divertido ...

Igual que @ max-arnold, es mi primer día usando la herramienta en un proyecto existente, y debo decir que estoy realmente decepcionado , antes de comenzar a usarlo, revisé el sitio de documentación y el video de demostración, se veía impresionante para mí, y ahora esto: en un proyecto real, trabajar con pip o pipenv es casi lo mismo, no veo el punto, como muchos otros dijeron en el hilo, si tengo un archivo de bloqueo, por qué está actualizando mis otras dependencias si no hay necesidad de actualizarlas.

Por supuesto, ### si la actualización es obligatoria, está bien actualizar todas las dependencias necesarias, pero solo esas, no todas las desactualizadas.

Además, las opciones --selective-upgrade y --keep-outdated no están claras para qué sirven, hay otro problema resaltando esto aquí # 1554, y nadie puede responder qué hacen estas opciones, increíble.

Pero mi mayor decepción es por qué este paquete fue recomendado por la documentación oficial de Python en sí, estas recomendaciones deben realizarse con más cuidado, sé que este puede ser un gran proyecto en la función, tiene mucho potencial, pero cosas simples como esta (nosotros no están hablando de un error o una característica menor), hacen que este proyecto no sea elegible para entornos de producción, pero de repente, debido a que fue recomendado por los documentos de Python, todos están tratando de usarlo, en lugar de buscar otras herramientas que tal vez funcionen mejor, o simplemente quédate con pip , eso no resuelve también estos problemas, pero al menos es muy minimalista y se incluye principalmente en cualquier entorno (no agrega dependencias adicionales).

@mrsarm Gracias por tu opinión. Lo siento, las cosas no funcionan para ti. Sin embargo, no entiendo de dónde viene la decepción. Nadie está imponiendo a Pipenv a nadie; si no funciona para usted, no lo use. Así es como funcionan las recomendaciones.

Su perorata tampoco tiene nada particularmente relacionado con este problema. Entiendo que se requiere un poco de autocontrol para no tirar basura sobre las personas cuando las cosas no salen como tú quieres, pero por favor muestra algo de respeto y absténgase de hacerlo.

@uranusjr no es basura, es una opinión, y algunas veces no es una opción, como mi caso, donde alguien eligió pipenv para crear un proyecto en el que comencé a trabajar ahora, y tengo que lidiar con esto.

Pero las cosas se ponen peor ahora, y lo que voy a decir no es una opinión, es un hecho.

Después de intentar agregar una dependencia que descarté para evitar lidiar con este problema (porque es una dependencia de desarrollo, así que creé un segundo entorno con pip y el antiguo enfoque requirements-dev.txt , solo con esa herramienta), necesitaba agregar otra dependencia.

La nueva dependencia es PyYAML, digamos la última versión. Si lo instalas en cualquier entorno nuevo con pip , verás que la biblioteca no agrega ninguna dependencia, por lo que solo se instala PyYAML, así de simple en estos casos con Pip. Pero al agregar la dependencia con Pipenv (porque un proyecto que no creé se administra con Pipenv), sucedió el mismo problema, a pesar de que PyYAML no tiene ninguna dependencia y no está instalado previamente en el proyecto (una versión anterior), pipenv actualiza todas mis dependencias en el archivo de bloqueo y el entorno virtual, pero no quiero actualizar las otras dependencias, solo una para agregar un solo módulo nuevo sin ninguna dependencia.

Entonces, la conclusión (y nuevamente una opinión, no un hecho como pipenv rompió todas mis dependencias) es que Pipenv en lugar de ayudarme a lidiar con la administración de dependencias, lo convirtió en un infierno.

He seguido este hilo durante meses y creo que cualquier proyecto real finalmente tropezará con este problema, porque el comportamiento es inesperado, contraintuitivo y, sí: peligroso.

Hace aproximadamente un mes probé una alternativa más completa a pipenv , poetry ; resolvió los problemas que _yo_ necesitaba resolver:
1) administrar un conjunto de dependencias (setup.py, setup.cfg, pip y pipfile -> pyproject.toml)
2) orientado al futuro, compatible con versiones anteriores (nuevamente pyproject.toml )
3) bastante poco obstinado ( no, realmente no estoy pidiendo instalar redis )
4) y la solución al problema clásico de Pipenv: "Además, tienes que decirle explícitamente [pipenv] que no actualice los paquetes bloqueados cuando instales nuevos. Este debería ser el predeterminado". [[1] (https://github.com/sdispater/poetry#what-about-pipenv)] [[2] (https://github.com/pypa/pipenv/issues/966#issuecomment-339117289)]

Sopesé compartir estos pensamientos sobre el tema pipenv , pero como dijo @uranusjr , "nadie está forzando a Pipenv a nadie", y no estoy forzando a la poesía. Me gusta, funciona bien y resuelve mis problemas, pero solo estoy compartiendo una solución alternativa y más completa al problema que estaba teniendo. Solo toma todo eso como mis 2 ¢.

• como descargo de responsabilidad, no soy miembro del equipo de Poesía ni

ps Creo que la preocupación de que Pipenv sea la solución "oficial" se debe a sus integraciones de primera clase , algo que usted, @uranusjr , podría ver como una simple recomendación, la industria en general lo está tomando como el "enfoque bendito adelante". Francamente, esa recomendación tiene más autoridad en la comunidad que ciertos PEP que han existido durante más de un año.

Nadie te obliga a participar en nuestro rastreador de problemas; Si no tiene un comentario productivo, busque un foro que no sea para triar problemas.

Para los usuarios que estén interesados ​​en probar el solucionador alternativo que https://github.com/sarugaku/passa, que generará archivos de bloqueo compatibles. La poesía hace muchas cosas diferentes, pero también tiene limitaciones y problemas en sí misma, y ​​tenemos un desacuerdo en la filosofía de diseño sobre el alcance.

Este es un proyecto que gestionamos en nuestro tiempo libre; Si desea ver algo arreglado o tiene un mejor enfoque, estaremos encantados de aceptar contribuciones. Si estás aquí simplemente para decirnos que arruinamos tu día y tu proyecto, solo te pediré una vez que te despidas.

No hemos olvidado ni ignorado este problema, tenemos una implementación completa de una solución en el solucionador vinculado anteriormente. Tenga paciencia, sea cortés o busque otro lugar para hablar. Para aquellos que han estado esperando pacientemente una solución, prueben el solucionador mencionado anteriormente; estamos ansiosos por ver si satisface sus necesidades. Implementa el retroceso y la resolución adecuados y no debería manejar esta estrategia de actualización

En el corto plazo, creo que podemos conseguir una curita para esto en pipenv si no terminamos cortando primero.

@dfee No estoy realmente seguro de que difuminar las líneas entre aplicaciones y bibliotecas sea la respuesta correcta a la gestión de dependencias, por lo que no veo el enfoque de la poesía como una ventaja. No estuve involucrado en el problema que tuviste con el motor de recomendaciones, pero lo eliminamos hace algún tiempo ...

@techalchemy

No estoy realmente seguro de que difuminar las líneas entre aplicaciones y bibliotecas sea la respuesta correcta a la gestión de dependencias, por lo que no veo el enfoque de la poesía como una ventaja.

¿Por qué sin embargo? Nunca entendí esta idea de que debes administrar las dependencias de una biblioteca y una aplicación de manera diferente. La única diferencia entre los dos es el archivo de bloqueo que se necesita para que una aplicación garantice un entorno reproducible. Aparte de eso, es lo mismo. Este es el estándar en la mayoría de los otros lenguajes y Python parece la excepción aquí por alguna razón y esto es malo desde el punto de vista de la experiencia del usuario, ya que esto hace que las cosas sean más complejas de lo que deberían ser.

también tiene limitaciones y problemas en sí mismo

¿Cuáles? Tengo mucha curiosidad acerca de los problemas o limitaciones que encontró al usar Poetry.

Mis disculpas por haber sido tan grosero. Ahora, al leer mis comentarios, me doy cuenta de que a pesar de la información que proporcioné y algunas de mis opciones siguen siendo válidas (en mi humilde opinión), no se apropió de la forma en que escribí lo que quería decir.

Entiendo que el rastreador de problemas es más un lugar donde discutir errores y mejoras, y discutir si esto es un error o un error de diseño no está claro en el hilo, pero nuevamente mis disculpas.

Creo que hay dos temas importantes aquí:

• ¿Debería pipenv actualizar todas sus dependencias desactualizadas donde está intentando instalar una nueva dependencia: las que no son necesarias para actualizar porque el nuevo paquete / versión que estamos tratando de instalar puede funcionar con las dependencias existentes, e incluso las que no están? ¿Qué dependencias del nuevo paquete que estamos intentando instalar? Quizás esto esté fuera del alcance de este boleto, pero es un tema muy importante para discutir.
• ¿Uno de estos parámetros --keep-outdated --selective-upgrade nos permite evitar este comportamiento? No está claro qué hacen estas opciones, hay una falta de documentación sobre ellas, e incluso en el tema relacionado (# 1554) nadie está respondiendo eso.

En caso de que haya un error en uno de estos parámetros --keep-outdated --selective-upgrade , sigo pensando que no establecer cualquier parámetro que resuelva la actualización innecesaria de las dependencias por defecto es una muy mala idea.

Para comparar con un escenario similar, imagine que ejecuta apt-get install vim para simplemente instalar la herramienta vim en su sistema (y las dependencias o actualizaciones necesarias de vim, si corresponde), pero imagine también que en esta situación apt actualiza todas las demás dependencias de su sistema: python, el sistema QT, el kernel de Linux ... y así sucesivamente. No es que apt no deba permitirnos actualizar otras dependencias, pero hay un comando claro para hacerlo: apt-get upgrade , mientras que apt-get install PACKAGE solo instala / actualiza el PAQUETE y sus dependencias.

@sdispater, la distinción está en el centro de cada desacuerdo que hemos tenido y es increíblemente sutil, pero te señalaría https://caremad.io/posts/2013/07/setup-vs-requirement/ o un buen artículo para el caso de uso de elixir: http://blog.plataformatec.com.br/2016/07/understanding-deps-and-applications-in-your-mixfile/

pyproject.toml no es realmente compatible con los metadatos de definición de la biblioteca, y en absoluto con ninguna versión de pip que no implemente peps 517 y 518 (los cuales aún tienen los detalles de implementación resueltos) como autoridad archivo de declaración de biblioteca. setup.cfg existe para ese propósito (el sucesor real de setup.py ) y en mi humilde opinión, ambos deberían ser compatibles. Una biblioteca se publica y está destinada al consumo con dependencias abstractas para que puedan jugar bien en la caja de arena con otros; las aplicaciones suelen ser bestias grandes y complejas con a veces cientos de dependencias directas. Así que una de nuestras principales divergencias es que cuando diseñamos y construimos nuestras herramientas, también tenemos esto en cuenta.

@mrsarm Para su primera pregunta, el comportamiento de actualización fue intencional (y se discutió extensamente en ese momento, / cc @ncoghlan y relacionado con las preocupaciones de seguridad de OWASP). En el segundo punto, el comportamiento actualmente no está implementado correctamente, por lo que el problema aún está abierto, lo que nos llevó a reescribir el solucionador de respaldo detrás de pipenv, que mencioné anteriormente. Simplemente no apoyó este comportamiento. Se supone que --selective-upgrade actualiza selectivamente solo las cosas que son dependencias del nuevo paquete, mientras que --keep-outdated retendría todo lo que satisfaga las dependencias requeridas por un nuevo paquete. Ligeramente diferente, pero estoy bastante seguro de que ninguno de los dos funciona correctamente en este momento.

pyproject.toml no es realmente compatible con los metadatos de definición de la biblioteca, y en absoluto con ninguna versión de pip que no implemente peps 517 y 518 (los cuales aún tienen los detalles de implementación resueltos) como un archivo de declaración de biblioteca autorizado . setup.cfg existe para ese propósito (el sucesor real de setup.py) y en mi humilde opinión, ambos deberían ser compatibles.

Bueno, esto ciertamente está fuera de tema, pero es una discusión importante, así que no puedo evitarlo.

En realidad, no existe un estándar alrededor de setup.cfg este momento, aparte de las convenciones establecidas por distutils y setuptools. pyproject.toml es absolutamente para metadatos de biblioteca como el sucesor de setup.py o la comunidad habría colocado los requisitos de construcción en setup.cfg lugar.

pyproject.toml describe cómo construir un proyecto (PEP 518), y parte de la construcción describe metadatos. NO estoy diciendo que pyproject.toml necesite una ubicación estándar para estos metadatos, pero PEP 518 usa este archivo para instalar una herramienta de compilación y, a partir de ahí, es muy razonable esperar que la herramienta de compilación use una configuración declarativa de otro lugar en el archivo para determinar cómo construir el proyecto.

De todos modos, volviendo a pipenv vs poesía, parece haber una idea flotando alrededor de que las aplicaciones no necesitan ciertas características que obtienen las bibliotecas, como puntos de entrada, y esto es simplemente incorrecto. Debería ser sencillo que una aplicación sea un paquete de Python.

La única diferencia verdadera entre una aplicación y una biblioteca en mi experiencia con Python y con otros ecosistemas es si está usando un archivo de bloqueo o no. Por supuesto, hay un tercer caso en el que realmente solo desea un requirements.txt o Pipfile y ningún código real y eso parece ser todo en lo que pipenv se ha centrado hasta ahora ( pipenv install -e . cae en esta categoría ya que pipenv todavía tiene miedo de intentar admitir los metadatos del paquete). Desafortunadamente, si bien el diseño de pipenv es más limpio con este enfoque, también es mucho menos útil para la mayoría de las aplicaciones porque PEP 518 decidió apostar sobre cómo instalar proyectos en modo editable, por lo que para continuar usando pipenv estaremos atrapados en setuptools bastante mientras tanto, ya que no puede usar pyproject.toml para alejarse de las herramientas de configuración y aún usar pipenv install -e . .

En realidad, no existe un estándar en torno a setup.cfg en este momento aparte de las convenciones establecidas por distutils y setuptools. pyproject.toml es absolutamente para metadatos de biblioteca ya que el sucesor de setup.py o la comunidad habría colocado los requisitos de compilación en setup.cfg en su lugar.

Distutils es parte de la biblioteca estándar y setuptools está instalado con pip ahora, así que decir que no hay estándar es un poco tonto. Sin mencionar que usa el estándar descrito en pep 345 para metadatos, entre otros, y también se puede usar para especificar requisitos de compilación.

la comunidad habría colocado los requisitos de compilación en setup.cfg en su lugar.

¿Te refieres a los autores de la motivación? Puede preguntarles por qué tomaron su decisión, lo describen todo en el punto de partida.

pyproject.toml describe cómo construir un proyecto (PEP 518), y parte de la construcción describe metadatos. NO estoy diciendo que pyproject.toml necesite una ubicación estándar para estos metadatos, pero PEP 518 usa este archivo para instalar una herramienta de compilación y, a partir de ahí, es muy razonable esperar que la herramienta de compilación use la configuración declarativa de otra parte del archivo. para determinar cómo construir el proyecto.

Esto apareció en la lista de correo recientemente: nada en ningún lugar ha declarado un estándar alrededor de pyproject.toml aparte de que se utilizará para declarar los requisitos del sistema de compilación. Cualquier otra cosa es una suposición; puede llamar a eso "metadatos de definición de biblioteca", pero no lo es. Intente definir solo un sistema de compilación sin información adicional sobre su proyecto (es decir, sin metadatos compatibles con pep-345) y cárguelo en pypi y déjeme saber cómo va.

De todos modos, volviendo a pipenv vs poesía, parece haber una idea flotando alrededor de que las aplicaciones no necesitan ciertas características que obtienen las bibliotecas, como puntos de entrada, y esto es simplemente incorrecto. Debería ser sencillo que una aplicación sea un paquete de Python.

¿Quién dice que las aplicaciones no requieren puntos de entrada? Pipenv tiene una construcción completa para manejar esto.

así que para continuar usando pipenv estaremos atascados en setuptools bastante más tiempo ya que no puede usar pyproject.toml para cambiar de setuptools y aún usar pipenv install -e.

No seguir aquí ... no vamos a dejar pip vendored en la versión 10 para siempre, literalmente he estado describiendo nuestro nuevo resolutor, y el instalador real simplemente recurre a pip directamente ... ¿cómo evita esto que las personas usen editable instala?

Esto apareció en la lista de correo recientemente: nada en ningún lugar ha declarado un estándar alrededor de pyproject.toml

Eso es correcto, no es un "estándar", sin embargo, en ese mismo hilo reconozca que al llamarlo pyproject.toml probablemente pidieron a las personas que usen este archivo para otras configuraciones / configuraciones relacionadas con el proyecto.

Entonces, por la misma lógica que invocaste aquí:

Distutils es parte de la biblioteca estándar y setuptools está instalado con pip ahora, así que decir que no hay estándar es un poco tonto.

pyproject.toml es un estándar y la comunidad lo ha adoptado como la ubicación estándar para colocar información relacionada con el sistema de compilación y otras partes de un proyecto de Python.

No seguir aquí ... no vamos a dejar pip vendored en la versión 10 para siempre, literalmente he estado describiendo nuestro nuevo resolutor, y el instalador real simplemente recurre a pip directamente ... ¿cómo evita esto que las personas usen editable instala?

PEP 517 aprovechó las instalaciones editables ... lo que significa que no hay una forma estándar de instalar un proyecto en modo editable si no está utilizando herramientas de configuración (que tiene un concepto conocido como modo de desarrollo que instala el proyecto en modo editable).

Distutils es parte de la biblioteca estándar y setuptools está instalado con pip ahora, así que decir que no hay estándar es un poco tonto. Sin mencionar que usa el estándar descrito en pep 345 para metadatos, entre otros, y también se puede usar para especificar requisitos de compilación.

Sí, se espera que el sistema de compilación genere el archivo PKG-INFO descrito en PEP 345. Este es un formato de transferencia que va en una sdist o rueda y se genera a partir de un setup.py/setup.cfg, no es un reemplazo como tal para los metadatos de cara al usuario. El uso de PEP 518 de pyproject.toml se trata de admitir alternativas a distutils / setuptools como un sistema de compilación, nadie está tratando de reemplazar los formatos sdist / wheel en este momento. Esos sistemas de compilación de reemplazo necesitan un lugar para colocar sus metadatos y, afortunadamente, PEP 517 reservó el espacio de nombres tool. para que estos sistemas lo hicieran. No es una suposición: tanto Flit como Poesía han adoptado este espacio de nombres para "metadatos de definición de biblioteca".

Intente definir solo un sistema de compilación sin información adicional sobre su proyecto (es decir, sin metadatos compatibles con pep-345) y cárguelo en pypi y déjeme saber cómo va.

Qué constructivo.

¿Quién dice que las aplicaciones no requieren puntos de entrada? Pipenv tiene una construcción completa para manejar esto.

¿Dónde está esta construcción? Ni siquiera puedo encontrar la palabra "entrada" en ninguna página de la documentación de pipenv en https://pipenv.readthedocs.io/en/latest/, ¿ así que "una construcción completa" suena bastante descabellada? Si se refiere a instalaciones editables, hemos llegado al punto que estaba señalando anteriormente: pipenv decidió acoplarse a pipenv install -e . como la única forma de conectarse y desarrollar una aplicación como un paquete, en el futuro previsible, el soporte de pipenv aquí está acoplado a las herramientas de configuración. Creo que toda la controversia se reduce a este punto y la gente (ciertamente yo) está frustrada de que ahora podamos definir bibliotecas que no usan setuptools pero que no pueden desarrollarse en ellas con pipenv. Para ser perfectamente claro, esto no es estrictamente culpa de pipenv (PEP 518 decidió apostar por las instalaciones editables), pero su negativa a reconocer el problema ha sido frustrante en el discurso, ya que la poesía proporciona una alternativa que maneja este problema de una manera compatible. con el formato pyproject.toml . Pipenv sigue diciendo que la poesía toma malas decisiones, pero en realidad no intenta proporcionar un camino a seguir.

https://pipenv.readthedocs.io/en/latest/advanced/#custom -script-shortcuts

Lea la documentación.

@bertjwregeer :

pyproject.toml es un estándar y la comunidad lo ha adoptado como la ubicación estándar para colocar información relacionada con el sistema de compilación y otras partes de un proyecto de Python.

Genial, y estamos felices de acomodar sdists y ruedas construidas con este sistema y hasta que haya un estándar para instalaciones editables, continuaremos usando pip para construir sdists y ruedas y manejar la resolución de dependencias de esa manera. Por favor lea mis respuestas en su totalidad. Los autores y mantenedores de pip, de los peps en cuestión, yo y @uranusjr conocemos bastante bien las diferencias entre las instalaciones editables y las implicaciones de construirlas bajo las limitaciones de pep 517 y 518. Hasta ahora, todo lo que estoy viendo ¿Es que los peps en cuestión no abordaron específicamente cómo construirlos porque lo dejan en manos de las herramientas, lo que por alguna razón todos piensan que significa que pipenv nunca podrá usar nada más que herramientas de configuración?

Ya he dicho que esto no es correcto. Si está realmente interesado en la implementación y en tener una conversación productiva, me alegra tener eso. Si simplemente está aquí para decir que no sabemos lo que estamos haciendo, pero no está interesado en saber primero qué es lo que estamos haciendo, esta es su única advertencia. Somos voluntarios con tiempo limitado y estoy practicando una política de tolerancia cero para compromisos tóxicos. No pretendo que mi trabajo sea perfecto y no pretendo que pipenv sea perfecto. Estaré feliz de contribuir con mi tiempo y esfuerzo a este tipo de discusiones; a cambio les pido que sean respetuosos, que se ciñan a los hechos y que los que participen también estén dispuestos a aprender, escuchar y escucharme. Si estás aquí solo para hacer una caja de jabón, tendrás que buscar otra plataforma; este es un rastreador de problemas. Lo moderaré según sea necesario.

Esta discusión está completamente fuera de tema . Si alguien tiene algo constructivo que decir sobre el tema en cuestión, no dude en continuar esa conversación. Si alguien tiene problemas o preguntas sobre las implementaciones de nuestro sistema de compilación, abra un nuevo problema. Si tiene problemas con nuestra documentación, aceptamos muchas solicitudes de extracción en torno a la documentación y somos conscientes de que debe solucionarse. Por favor, posponga toda esa discusión a nuevos temas para esos temas. Y tenga en cuenta: se seguirán aplicando las mismas reglas: esto no es una tribuna, es un rastreador de problemas.

https://pipenv.readthedocs.io/en/latest/advanced/#custom -script-shortcuts
Lea la documentación.

Los puntos de entrada son un concepto más general que los scripts de consola y este vínculo es completamente erróneo al abordar esas preocupaciones. <soapbox> Prohibición: no eres el único responsable de los grandes proyectos de código abierto aquí y ninguno de mis comentarios ha sido un ataque personal contra ti o el proyecto. Las personas que comentan aquí lo hacen porque quieren usar pipenv y aprecian mucho lo que hace. Mi comentario no fue la primera publicación fuera de tema en este hilo, pero es el único marcado. Tus comentarios sarcásticos que indican que crees que no sé de qué estoy hablando son vergonzosos y tóxicos.

En el proyecto que mantenemos, podemos jabones. Y sí, pip admitirá todos los sistemas de compilación compatibles que ambos parecen comprender muy bien producirán metadatos consumibles, y como pipenv usa pip como herramienta de respaldo para impulsar su proceso de instalación, como describí, sí, pipenv admitirá todos los estampación. Ya dije esto.

Así que sí, lleva tu toxicidad a otro lugar. Tu actitud no es bienvenida aquí. Última advertencia. No se tolerarán los intentos persistentes de incitar al conflicto.