¡Una propuesta ambiciosa!

Soporte de configuración ini (una configuración ini global presente en la casa de los usuarios)

Considere usar appdirs (o similar) para descubrir la configuración en ubicaciones preferidas por la plataforma.

appdirs bien podría ser una opción, aunque luego tendríamos que comenzar el negocio de vender cosas en nuestro paquete. Para ser justos, el 70% de esto ya está hecho, solo necesitaría una mejor reorganización.

¿Por qué proveedor en lugar de depender únicamente de él? (No es que sea difícil de vender, es solo un archivo). En mi opinión, realmente debemos aceptar que (con la notable excepción de pip) las herramientas de empaquetado realmente deberían construirse como cualquier otra aplicación. Si tener dependencias es lo suficientemente difícil como para que las aplicaciones PyPA las eviten, ¿qué dice eso sobre lo bien que lo estamos haciendo para facilitar a nuestros usuarios el desarrollo de aplicaciones?

(Lo siento, no estoy haciendo un gran punto sobre virtualenv aquí, solo veo a tanta gente diciendo "agregar una dependencia de PyPI no es un gran problema", luego las herramientas de PyPA en las que trabajo vendiendo cosas me hacen preguntarme ...) .

Creo que sin vender la función de intérprete cruzado será difícil. Por ejemplo, crear un entorno virtual para un intérprete que no tenga virtualenv instalado.

PYTHONPATH = / t / ruta / a / virtualenv.whl python -m virtualenv

Uh, esto significaría que no podemos depender de ningún paquete adicional de virtualenv. Dado que proporcionaremos una zipapp, ¿qué casos de uso habilita esto?

@gaborbernat ¿ Te refieres a la opción -p ? Supongo que sí. Parece exactamente el tipo de situación en la que las zipapps estaban destinadas a ayudar, pero nadie ha hecho mucho para aclarar los detalles para que funcione bien.

De @pradyunsg :

Uh, esto significaría que no podemos depender de ningún paquete adicional de virtualenv

En realidad, como dijo @gaborbernat , la opción -p probablemente implica que :-( Pero me pregunto por qué necesitamos la opción "rueda en PYTHONPATH ", así como la opción zipapp, especialmente dado que las ruedas en PYTHONPATH no son compatibles en general (los usamos internamente dentro de virtualenv debido a las razones habituales de arranque de pip: pip es prácticamente una excepción a todo ;-))

período de

Mmm...

Mi preocupación aquí es que los efectos de red de esto podrían causar una desaceleración en la adopción de versiones más nuevas de Python y la explosión combinatoria de la cantidad de Pythons compatibles. CPython está discutiendo una cadencia de lanzamiento diferente para 3.9, por lo que 2 años podrían ser incluso más largos de lo que podrían tener algunos lanzamientos de desarrolladores principales.

Dicho esto, no quiero bloquear esto, pero sobre todo asegurarme de expresar que no estoy interesado en hacer esto.

(esperando IronPython y Jython en algún momento, ¿hay otros que debamos admitir?)

Definitivamente. @gaborbernat probablemente sepa que diría esto: sería bueno

Primero, soporte de configuración ini (una configuración ini global presente en la casa de los usuarios),

Soy parcial, realmente me gustaría ver que esto sea TOML. :)

(Todavía no he procesado esto por completo porque tengo que ir a algún lado, ¡pero parece un gran objetivo general!)

ya no podemos depender realmente de paquetes adicionales debido a la función de intérprete cruzado, por lo que no considero esto como un inconveniente importante, y me gustaría tener una forma simple sin instalación / dependencia de ejecutar entornos virtuales (necesario cuando las personas invocarnos desde los paquetes de nodos). Dado que no nos cuesta mucho ofrecer además zipapp parece barato.

Prefiero venv incorporado: si el python de destino tiene venv, crearemos el entorno usando eso (y luego realizaremos operaciones posteriores para facilitar otras garantías que ofrecemos)

No estoy seguro de entender la razón fundamental de esto. Parece que dificultará el mantenimiento de virtualenv y hará que los comportamientos sean más difíciles de entender para los usuarios finales. setuptools ya está yendo en sentido contrario al tratar de absorber distutils lugar de continuar parcheándolo.

@pganssle el alcance es diferente y el espacio del problema también. virtualenv es que a menudo los sistemas imponen restricciones adicionales a los paquetes del sistema, por lo que parchean el venv incorporado para adherirse a ellas. Replicar todos estos sería difícil, ver, por ejemplo, # 1362.

FWIW Creo que usar el paquete venv integrado para el aislamiento es la idea correcta, está integrado en el intérprete real (en lugar de distutils, que es solo un módulo stdlib), por lo que puede hacer las cosas mucho más limpias que virtualenv lata.

Virtualenv tampoco necesitaría parchear nada, solo usaría la API pública, lo que debería estar bien.

FWIW Recomendaría revisar mi antigua rama virtualenv de reescritura, ya hizo muchas de estas cosas.

Sin embargo, probablemente sugeriría que un sistema de complementos no es muy útil para virtualenv, a lo sumo, es probable que solo haya un gancho, un paso posterior a la creación e incluso entonces probablemente pueda salirse con una lista de cosas para instalar.

TAMBIÉN, todavía puede depender de cosas "naturalmente" y seguir utilizando zipapps, sólo tiene que vender dentro de la propia zipapp. Recomendaría alejarse de la opción de volver a ejecutar bajo la opción de python de destino, es algo malo y se puede hacer mucho más limpio.

697 - Relaciones públicas más antiguas de

PYTHONPATH = / t / ruta / a / virtualenv.whl python -m virtualenv

OTOH, probablemente no deberíamos estar haciendo esto de todos modos - https://www.python.org/dev/peps/pep-0427/#is -it-possible-to-import-python-code-direct-from- una-rueda-lima

@pradyunsg, ¿ hay otros métodos para arrancar pip sin poner la rueda en el camino?

Bootstrapping pip probablemente esté bien, es lo que virtualenv usa ahora ¹ . Pero yo recomiendo encarecidamente usarlo sólo para PIP, y no como un medio de funcionamiento virtualenv sí.

¹ Pero evitaría cualquier funcionalidad complicada: el uso de una rueda en PATH para instalar pip desde esa rueda está prácticamente garantizado que estará bien. Pero es posible que tenga problemas si, por ejemplo, accede a Internet usando una rueda de este tipo, ya que creo que certifi necesita su paquete de certificado integrado como un archivo real (pero puedo estar equivocado, eso nunca me causó un problema, pero sé que get-pip.py extrae los certificados de la rueda explícitamente para abordar este punto.

¿Alguna razón por la que no enviamos pip como zipapp ? Eso evitaría esta necesidad, según tengo entendido, y zipapp es compatible con python 2.7 🤔

@gaborbernat ¿lo has probado? ¿Funciona? Si el enfoque que describiste funciona en Windows, no tengo ninguna preocupación inicial, pero es probable que @dstuff, es decir, cuanto más simple, mejor

¿Alguna razón por la que no enviamos pip como zipapp?

Porque en ciertos casos, pip no se ejecutará directamente desde un archivo zip (o una rueda, es lo mismo), como dije anteriormente. El 99% (alerta - número compuesto) de las veces, funciona, pero a veces el hecho de que el paquete de certificados debe ser un archivo real es importante.

Sin embargo, probablemente funcionaría bien agrupar pip como un shiv , ya que shiv desempaqueta el zipapp antes de ejecutarlo, precisamente para evitar los casos de esquina en los que se rompe el zip. Sin embargo, nadie que yo sepa lo ha probado.

Como de costumbre, las principales razones por las que no ha sucedido son:

1. Nadie pensó en eso.
2. Nadie tuvo el tiempo ni la motivación para hacerlo.
3. El enfoque actual funciona bien y hay peces más grandes para freír.

Entonces, ¿hay otros métodos para arrancar pip sin poner la rueda en el camino?

No creo que necesitemos eso aquí: virtualenv está usando la rueda pip para instalar desde sí mismo IIRC, que debería funcionar bien. Como dijo @pfmoore , lo único "extra" que hace get-pip.py es descomprimir los certificados y proporcionarles una ruta. Dado que el caso de uso de virtualenv no llegará a la red, no necesitamos hacer nada nuevo aquí.

El enfoque actual funciona bien y hay peces más grandes para freír.

Esto, mucho más que los demás en mi opinión. Podríamos, pero hay problemas más impactantes que abordar. :)

Tuve un PR en un momento que construyó pip como una aplicación zip, funcionó pero IIRC tuve que hacer cambios en pip para que fuera completamente funcional.

Eso podría complicarse un poco ahora, ya que pip se invoca a sí mismo como un subproceso de sí mismo para PEP 517. No estoy seguro, pero definitivamente vale la pena explorarlo.

En este punto, shiv (u otra opción autoextraíble) sería más adecuada para pip que intentar convertir pip en zip ejecutable. Pero no creo que esto sea algo particularmente importante en este momento. Asegurepip ya sigue la ruta de la rueda en el camino, ¿por qué no hacer lo mismo? Se puede explorar el bootstrapping alternativo de pip después de freír todos los peces más grandes, y potencialmente se puede contribuir a stdlib.

Se puede explorar el arranque de pip alternativo después de freír todos los peces más grandes

Suena como un plan [uno que ya estamos siguiendo. ;)]

Gracias por los enlaces. Basándome en los comentarios, comencé un trabajo inicial en https://github.com/gaborbernat/virtualenv/tree/rewrite/src/virtualenv. El plan es ponerlo en forma de lanzamiento dentro del próximo mes (y tener una semana de revisión abierta antes de eso). Según el impacto del cambio, planeo publicarlo 20.0.0 .

+1 por usar venv si existe. Eso simplificaría el caso de uso de PyPy.

Así que la reescritura llegó a un estado en el que me siento cómodo con que la gente le eche un vistazo y dé algunos comentarios. Comuníquese conmigo si tiene algo de tiempo libre para ayudar con esto; el plan es que se publique antes de fin de mes 🤞 Nota https://github.com/pypa/virtualenv/milestone/7 aún debe implementarse, sin embargo, la idea central está ahí.

PD. Creé un RP de retroalimentación en https://github.com/pypa/virtualenv/pull/1481/

Solicitud de función: proporcione un mecanismo para definir variables de entorno personalizadas, por ejemplo, colocando un archivo env.txt en el directorio venv bin con el formato estándar:

VARNAME=value
OTHERVAR=othervalue

¿No creo que entiendo tu caso de uso? ¿Cómo se utilizarían, establecerían y cuándo se establecerían estas variables de entorno?

Editar. NUEVO MÉJICO. Veo que se expandió en https://github.com/pypa/virtualenv/issues/1124.

Una pequeña actualización; Me las arreglé para cerrar la mayoría de los problemas de bloqueo, excepto dos que todavía necesitan algo de amor: las pruebas incluyen encabezados + almacenamiento en caché de llamadas de interrogación de Python con algún bloqueo aplicado sobre los datos de la aplicación, para que podamos crear entornos virtuales en paralelo (a diferentes ubicaciones). Al ritmo actual, podría llegar unos días tarde ... pero definitivamente debería estar fuera el 7 de febrero.

¿Cuál es nuestro plan en términos de implementación? ¿Tendríamos una versión beta antes del lanzamiento principal?

Sí, quiero sacar algo el lunes ... Y luego dejar tentativamente una semana para comentarios, arreglos ... Y luego reemplazar master con reescribir y publicar.

No estoy 100% seguro de que una semana sea suficiente y definitivamente deberíamos comunicarnos a través de múltiples canales que queremos que la gente pruebe la versión beta.

La palabra clave allí era tentativamente . Soy optimista aquí, dada la cantidad de esfuerzo que he puesto, no espero problemas importantes, pero 🤷‍♂

virtualenv 20.0.0 beta1 está disponible .

Como la versión beta está disponible, creo que este problema es el propósito. Terminaré y podemos discutir más centrados en temas específicos.