# Entorno virtual de Python: qué es y cómo usar venv > Un entorno virtual separa las bibliotecas de un proyecto de la instalación global de Python. Esta guía muestra cuándo crearlo, cómo activarlo, cómo registrar dependencias y qué revisar antes de compartir el código. - URL canónica: https://visteesto.com/nota/entorno-virtual-python-que-es-venv - Autor: [Martin Rodriguez](https://visteesto.com/autor/martin-rodriguez) - Publicado: 2026-09-27T18:00:00.000Z - Actualizado: 2026-09-27T18:00:00.000Z - Sección: Tecnología - Tema: entorno-virtual-python-venv-dependencias - Idioma: es - Consulta principal: qué es un entorno virtual de Python y cómo usar venv ## Resumen verificable - El módulo venv de la biblioteca estándar crea entornos virtuales aislados para paquetes de Python. ([evidencia](https://docs.python.org/3/library/venv.html)) - La activación de un entorno modifica la ruta de la terminal para usar su intérprete y sus scripts de instalación. ([evidencia](https://packaging.python.org/en/latest/guides/installing-using-pip-and-virtual-environments/)) - El archivo requirements.txt puede registrar dependencias instaladas para repetir una instalación en otro entorno. ([evidencia](https://packaging.python.org/en/latest/guides/installing-using-pip-and-virtual-environments/)) - Los editores de código permiten elegir el intérprete de Python asociado a un proyecto y sus herramientas. ([evidencia](https://code.visualstudio.com/docs/python/environments)) ## Aporte editorial de VisteEsto VisteEsto convierte la documentación de venv y packaging en una secuencia de decisiones sobre intérprete, dependencias, editor, CI y archivos que sí deben versionarse. ## Qué es un entorno virtual 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. 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. ## Cómo crear y activar venv 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. ## Instalar y registrar dependencias 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. ## Editor, pruebas y automatización 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. ## Checklist antes de compartir el proyecto 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. ## Fuentes consultadas - Fuente primaria: [Python documentation: venv — Creation of virtual environments](https://docs.python.org/3/library/venv.html) - Fuente primaria: [Python Packaging User Guide: Installing packages using pip and virtual environments](https://packaging.python.org/en/latest/guides/installing-using-pip-and-virtual-environments/) - Fuente primaria: [Visual Studio Code: Python environments](https://code.visualstudio.com/docs/python/environments) ## Imágenes y licencias - Proyecto Python aislado dentro de un entorno virtual. Autor: VisteEsto. Licencia: [VisteEsto editorial](https://visteesto.com/terminos). [Origen](https://visteesto.com/nota/entorno-virtual-python-que-es-venv). - Terminal que activa un entorno virtual de Python. Autor: VisteEsto. Licencia: [VisteEsto editorial](https://visteesto.com/terminos). [Origen](https://visteesto.com/nota/entorno-virtual-python-que-es-venv). - Dependencias de Python registradas para reconstruir un proyecto. Autor: VisteEsto. Licencia: [VisteEsto editorial](https://visteesto.com/terminos). [Origen](https://visteesto.com/nota/entorno-virtual-python-que-es-venv). ## Cómo citar Citar título, autor, fecha de publicación o actualización y la URL canónica. Las afirmaciones centrales incluyen su evidencia directa arriba. Esta versión Markdown es una representación accesible; la nota HTML canónica es la fuente editorial de referencia.