Entorno virtual de Python: qué es y cómo usar venv

Un entorno virtual de Python es un directorio que contiene una instalación aislada de paquetes y los archivos necesarios para usarlos desde un proyecto. El intérprete base sigue existiendo en el sistema, pero las dependencias del proyecto se instalan dentro de ese entorno separado.

También puede servirte: Git merge o rebase: qué cambia y cuándo usar cada uno

Aislar dependencias evita que una actualización para una aplicación rompa otra. También hace visible qué necesita cada repositorio: dos proyectos pueden usar versiones distintas de una biblioteca sin modificar la instalación global ni depender del orden en que se ejecutaron comandos anteriores.

El entorno no es una caja de seguridad ni incluye automáticamente una base de datos o un servicio externo. Organiza paquetes de Python y el intérprete que los ejecuta. Las variables secretas, los servicios y las herramientas del sistema requieren controles adicionales.

La biblioteca estándar incluye el módulo `venv`. Desde la carpeta del proyecto se puede crear un entorno con `python -m venv .venv`, usando el intérprete que el equipo haya elegido. El nombre `.venv` es una convención útil porque muchas herramientas lo detectan, aunque no es obligatorio.

La activación cambia el `PATH` de la terminal para que `python` y `pip` apunten al entorno. En macOS o Linux se usa `source .venv/bin/activate`; en Windows PowerShell, `.venv\Scripts\Activate.ps1`. Si la política de ejecución bloquea el script, hay que resolver esa configuración sin copiar paquetes al sistema.

La activación sólo afecta a esa terminal. Al cerrarla, el entorno deja de estar activo y el proyecto sigue teniendo su directorio. También se puede llamar al intérprete con la ruta completa, una opción práctica para scripts y automatizaciones que no deben depender de una sesión interactiva.

Con el entorno activo, `python -m pip install requests` instala el paquete en `.venv` y no en la instalación global. Usar `python -m pip` ayuda a que pip corresponda al mismo intérprete que ejecutará el proyecto, en lugar de confiar en un ejecutable con otro origen.

Para compartir el conjunto instalado se puede generar `requirements.txt` con `python -m pip freeze`. Ese archivo debe revisarse antes de confirmarlo: puede incluir paquetes de desarrollo o versiones que no representan la política que el equipo quiere mantener. Un proyecto grande puede preferir un archivo de dependencias administrado por otra herramienta.

La lista de paquetes no reemplaza los locks ni las instrucciones del proyecto. Hay que registrar la versión de Python, el comando de instalación y cualquier dependencia del sistema. La reproducibilidad mejora cuando otra persona puede crear un entorno limpio y repetir la instalación desde archivos versionados.

Los editores suelen permitir elegir el intérprete del proyecto. Seleccionar `.venv` hace que el análisis, las pruebas y la ejecución usen las mismas bibliotecas que la terminal. Si el editor apunta al Python global, puede mostrar errores que no aparecen al correr el programa dentro del entorno correcto.

En integración continua no conviene subir `.venv` al repositorio. El trabajo debe crear un entorno nuevo, instalar dependencias declaradas y ejecutar pruebas desde cero. El directorio local puede ignorarse con `.gitignore`, mientras los archivos que describen dependencias sí deben versionarse.

Una automatización estable comprueba qué Python está usando y muestra la versión cuando falla. También debe separar dependencias de producción, desarrollo y pruebas cuando el proyecto lo necesita. El entorno virtual reduce sorpresas, pero no corrige una especificación incompleta ni una dependencia que dejó de ser compatible.

Confirmá la versión de Python que requiere el proyecto y creá `.venv` desde esa base. Instalá dependencias usando el mecanismo documentado, ejecutá una prueba mínima y verificá que el intérprete activo sea el esperado. Un comando corto de diagnóstico ahorra tiempo cuando otra persona empieza desde cero.

Agregá `.venv/` al archivo de exclusiones y nunca subas secretos, cachés o binarios generados. Versioná `requirements.txt` u otro archivo de dependencias y explicá cómo actualizarlo. Si una biblioteca necesita un compilador o una librería nativa, documentá ese requisito fuera del entorno.

Antes de borrar el entorno, guardá cualquier archivo de configuración que el proyecto necesite y comprobá que puede reconstruirse. El entorno virtual es descartable por diseño: la fuente de verdad debe estar en el código, las dependencias declaradas y las instrucciones que permiten volver a crear la instalación.