Cualquier desarrollo en Python requerirá con seguridad del uso de un conjunto de módulos y, dado que, generalmente no tendremos control sobre cómo ni cuándo evolucionará cada uno de estos módulos, nuestro desarrollo quedará restringido para operar sólo con versiones específicas de los módulos de los cuales dependa. Si seguimos las normas especificadas para el empaquetado, estas dependencias estarán claramente determinadas en los paquetes generados. Y, si hemos respetado las versiones por defecto existentes en nuestro entorno de producción, estas dependencias no deberían suponer mayores inconvenientes a la hora de instalar o actualizar nuestros desarrollos.
Pero en nuestro entorno de desarrollo el tema puede no ser tan sencillo. En cualquier momento podremos encontrarnos que, mientras estamos trabajando en un nuevo desarrollo que requiere de la versión Y del módulo A, debemos realizar un parche o actualización de otro proyecto que también utiliza el módulo A pero que se ha desarrollado para la versión X. O podría darse el caso de tener que entregar versiones de un mismo desarrollo para ser utilizado en plataformas distintas en las que las versiones de los módulos difieren. Y a esto le podríamos sumar la complejidad adicional de estar utilizando diferentes versiones de Python.
Todos estos escenarios pueden resolverse con alguna solución de virtualización que nos permita generar entornos de desarrollo aislados y específicos a cada proyecto particular. Y cada solución tendrá sus ventajas e inconvenientes en temas como la posibilidad de aislarse o integrarse con el resto del sistema, espacio ocupado o inclusión de herramientas adicionales.
Con independencia de las opciones de virtualización que puedan implementarse a nivel del sistema operativo, en el caso particular de Python, existe una alternativa adicional denominada virtualenv en la cual se genera un entorno virtual exclusivamente para la ejecución del intérprete de Python y que utiliza recursos del sistema operativo anfitrión para cualquier otra actividad.
Instalación de virtualenv
En sistemas basados en Debian, la instalación de virtualenv se reduce a la instalación del paquete específico más el paquete asociado a la versión del intérprete Python que estemos utilizando. En sistemas donde tanto Python2 como Python3 se encuentren disponibles el comando de instalación será:
# aptitude install virtualenv python-virtualenv python3-virtualenv
Creación de un entorno virtualenv
Para crear un entorno denominado env1 para trabajar en un desarrollo basado en Python3, nos ubicamos en el directorio a partir del cual se creará el entorno y ejecutamos:
$ virtualenv env1 --always-copy --python=python3 Already using interpreter /usr/bin/python3 Using base prefix '/usr' New python executable in /home/user/Work/env1/bin/python3 Also creating executable in /home/user/Work/env1/bin/python Installing setuptools, pkg_resources, pip, wheel...done.
Si en cambio el desarrollo fuera en Python2, el comando correspondiente es virtualenv env1 ‑‑always‑copy ‑‑python=python2.
Estructura de los entornos virtualenv
Los entornos creados tendrán la siguiente estructura básica:
env1
├── bin
├── include
│ └── python3.5m
├── lib
│ └── python3.5
└── share
└── python-wheels
Como puede observarse, el entorno se compone de un directorio /bin donde se aloja una copia del intérprete Python a utilizar más los ejecutables de activación y desactivación y del entorno y de gestión de paquetes Python y, adicionalmente, los directorios de librerías donde se alojarán los módulos que incluyamos en el entorno.
Activación de un entorno virtualenv
Para activar el entorno se deberá ejecutar el script activate que se encuentra dentro del directorio /bin del entorno que se desea activar utilizando el comando source para incorporar los ajustes en las variables de ambiente en nuestra shell.
$ source env1/bin/activate (env1) $
Uso del entorno virtualenv
Mientras nos encontremos dentro de la shell que cuenta con el entorno activado, los comandos de gestión de paquetes (easy_install, pip y wheel) afectarán sólo al contenido del entorno, así como la ejecución del intérprete de Python sólo invocará al intérprete definido en el entorno.
Para el resto de comandos, el sistema recurrirá a lo que se encuentre instalado dentro del anfitrión.
Nótese que la la ubicación de nuestros fuentes es irrelevante pero, para simplificar la gestión, sería recomendable ubicar nuestros proyectos dentro de la estructura del entorno que utilizan, en un directorio con el nombre del proyecto o denominado /src.
Desactivación de un entorno virtualenv
Una vez que hayamos terminado de operar con el entorno, si queremos recuperar el funcionamiento normal de nuestra shell, ejecutaremos el comando deactivate. En este caso no hace falta especificar el directorio ya que, mientras nos encontremos con el entorno activado, los ejecutables que se encuentran dentro del directorio /bin de nuestro entorno tienen prioridad por sobre el resto de ejecutables del sistema.
(env1) $ deactivate $
