El desarrollador Brett Cannon, responsable de las extensiones de Python para VS Code, explica en un artículo los motivos que le llevaron a redactar la PEP 832, dedicada al descubrimiento de entornos virtuales. La propuesta nace de un problema muy concreto: ni los editores ni los agentes de IA saben de antemano qué herramienta de gestión de entornos (Hatch, Poetry, uv, virtualenvwrapper, conda, etc.) utiliza un proyecto, ni dónde guarda dicha herramienta los entornos. Esa falta de información impide lanzar código, analizar dependencias o aplicar correctamente funciones como el autocompletado y el linting.
Cannon describe tres escenarios problemáticos. El primero ocurre al abrir por primera vez un proyecto recién clonado, cuando no existe ninguna pista sobre la herramienta preferida. El segundo afecta a la localización de entornos creados fuera del árbol del proyecto, algo habitual en herramientas como conda. El tercero se da cuando un mismo usuario acumula cientos de entornos compartidos entre proyectos, imposibles de asociar de forma automática.
Como solución, la PEP plantea tres piezas. Un directorio .venv convencional que actúe como caso trivial de descubrimiento. Un archivo .python-envs con la lista de rutas a entornos, cuyo último registro sería el predeterminado. Y una tabla [workflow] en pyproject.toml que indique al editor cómo invocar la herramienta elegida en modo servidor mediante el Workflow Server Protocol, un diálogo JSON-RPC sobre entrada y salida estándar. Cannon también sugiere una convención de nombres en la línea de comandos como alternativa. El objetivo final es estandarizar la comunicación entre editores y herramientas de gestión, de modo que la experiencia de empezar a trabajar con Python sea más sencilla y no dependa de integraciones a medida como la extensión de Hatch.
