Cuando una pequeña oficina se hace cargo de una aplicación de Python o configura de nuevo un equipo, debe poder conocer con precisión qué paquetes utiliza. Con venv y pip se puede preparar una reconstrucción controlada. Lo decisivo es contar con un entorno de partida limpio, dependencias revisadas y pruebas de la aplicación. Una exportación de paquetes por sí sola no garantiza una reproducibilidad universal.
1. Definir los requisitos previos y el directorio de trabajo
Todos los ejemplos de Unix que figuran a continuación deben ejecutarse exclusivamente en un proyecto de prueba independiente, no en el directorio de la aplicación en producción. Como requisito previo, debe haber un intérprete de Python ya instalado, con mantenimiento vigente y compatible con el proyecto. Documente de antemano:
- la versión prevista del intérprete, incluida la subversión,
- el sistema operativo y la arquitectura del procesador,
- el estado del proyecto, la configuración necesaria y las pruebas de la aplicación disponibles.
python3 representa aquí ese intérprete seleccionado deliberadamente. Antes de empezar, compruebe a qué intérprete corresponde; si es necesario, utilice su ruta explícita. No sustituya el Python del sistema operativo ni modifique el PATH global. Todas las rutas relativas se refieren al directorio raíz del proyecto de prueba. Los nombres de archivo como requirements-snapshot.txt son ejemplos elegidos libremente y, si se cambian, deben actualizarse de forma coherente en todos los lugares donde aparezcan.
2. Preparar un entorno de origen limpio
Cree un entorno propio, inicialmente limpio, para el estado previsto del proyecto:
python3 -m venv .venv-srcInstale allí únicamente las dependencias previstas para el proyecto de prueba, siguiendo sus instrucciones de instalación. Utilice expresamente .venv-src/bin/python -m pip para evitar actuar por error sobre otro entorno. No incorpore una colección de paquetes sin revisar procedente de un entorno de trabajo compartido ni realice actualizaciones indiscriminadas de paquetes.
Según la documentación de venv, los paquetes del proyecto están aislados de forma predeterminada. Sin embargo, el entorno sigue vinculado a su intérprete base y no constituye un entorno aislado de seguridad. No es necesario activarlo si se utilizan rutas explícitas al intérprete. Pruebe ahora la aplicación con datos de prueba adecuados; solo después debe realizar la exportación.
3. Registrar y revisar el conjunto de paquetes probado
.venv-src/bin/python -m pip freeze > requirements-snapshot.txtpip freeze informa de los paquetes instalados. No es un solucionador que genere archivos de bloqueo y, de forma predeterminada, omite determinados paquetes de arranque. Por tanto, el archivo es una instantánea de partida, no una descripción completa del intérprete, las herramientas y la plataforma.
Abra el archivo exportado antes de compartirlo. Revise especialmente las instalaciones editables, las rutas locales y las URL de paquetes privados. Elimine las credenciales de los archivos que vaya a compartir. Aclare también cómo se mantendrá el acceso autorizado a los paquetes privados necesarios; limitarse a borrar esas entradas no permite una reconstrucción completa. Registre las dependencias directas y transitivas, en lugar de enumerar solo las bibliotecas utilizadas directamente.
4. Reconstruir de forma independiente y verificar
Conserve .venv-src sin cambios. Cree junto a él un segundo entorno con un intérprete adecuado y compatible e instale la lista revisada:
python3 -m venv .venv-rebuild
.venv-rebuild/bin/python -m pip install -r requirements-snapshot.txt
.venv-rebuild/bin/python -m pip checkpip check comprueba exclusivamente la compatibilidad declarada de las dependencias. Un resultado sin incidencias no sustituye ni las pruebas de la aplicación ni una auditoría de seguridad. Por ello, realice las mismas comprobaciones funcionales que en el entorno de origen: por ejemplo, una importación prevista, una ejecución de procesamiento típica y la comprobación de los resultados. Ejecute también estas comprobaciones expresamente con .venv-rebuild/bin/python. Documente los errores y los resultados de las pruebas antes de aceptar la reconstrucción.
5. Documentar con más detalle la plataforma y los archivos de paquetes
Para mejorar la trazabilidad, registre además las versiones utilizadas de Python y pip, así como el sistema operativo y la arquitectura. Según la guía de pip para instalaciones repetibles, las dependencias directas y transitivas completamente fijadas, junto con los hashes de paquetes verificados, pueden aportar más garantías al procedimiento. Los hashes confirman que los archivos de paquetes son los esperados, no que estén libres de software malicioso. Los archivos Wheel pueden ser específicos de una plataforma; por tanto, un conjunto de versiones de paquetes disponible en otra arquitectura no es automáticamente equivalente.
6. Asegurar la vuelta atrás y registrar el resultado
Conserve el entorno anterior, así como una copia de seguridad de la aplicación y los datos, hasta que se haya verificado la nueva instalación. Si se producen errores, descarte únicamente el nuevo entorno de prueba e investigue la causa; la base de trabajo anterior debe permanecer intacta. Los entornos virtuales se crean de nuevo, no se trasladan ni se copian.
Conclusión: Una reconstrucción útil consta de una exportación de paquetes revisada, una plataforma documentada y pruebas satisfactorias de la aplicación. Esta combinación permite seguir los cambios de forma trazable, sin confundir una lista de paquetes con una garantía integral de reproducibilidad.