Autonomía digital y tecnológica

Código e ideas para una internet distribuida

Cómo usar entornos virtuales en Python en un sistema Linux Debian y no morir en el intento

Imago voragine.net
[actualizado el ]

TLDR: Lo que hace confuso el uso de entornos virtuales es el jaleo de versiones de python que conviven en un sistema, no los entornos en sí que conceptualmente son muy sencillos. Las herramientas para gestionar entornos virtuales son módulos de python en su mayoría. Para evitar que python se líe como un ovillo mal enrollado y evitar pasar un día desenredándolo a mí me funcionan tres reglas: no instalar módulos usando sudo, instalar módulos usando pip y no apt (a excepción de python-env), usar python -m pip en lugar de pip.

Los entornos virtuales de Python son algo maravilloso. De esas cosas que descubres y no sabes cómo has hecho hasta ese momento para funcionar sin ellas. Pero también son un maldito rompecabezas, un laberinto en el que se puede uno perder y echar todo un día para salir de él. Diría con mi corta experiencia usando Python que el laberinto lo forman las versiones de python que cohabitan en el sistema.

Últimamente uso virtualenv para crear y activar entornos virtuales. Tras la última actualización del sistema, en la que venía python 3.9.1, virtualenv dejó de funcionar. Cuando lo invocaba, independientemente de la versión del intérprete, me decía que no existía el módulo:

skotperez@lee:~$ python3 -m virtualenv --version
/usr/bin/python3: No module named virtualenv
skotperez@lee:~$ virtualenv --version
/usr/bin/python3: No module named virtualenv
skotperez@lee:~$ python -m virtualenv --version
/usr/bin/python3: No module named virtualenv

Sin embargo el programa estaba instalado en mi sistema:

skotperez@lee:~$ which virtualenv
/usr/local/bin/virtualenv

Tardé varias horas en caer en que mi yo del pasado había instalado virtualenv usando el intérprete python3.8. Mal. Para eso están los alias python3 y python, supongo: para que módulos como virtualenv no queden anclados en una versión que dura unos meses. Además lo había instalado, por alguna razón que no recuerdo, para todo el sistema y no únicamente en el entorno de mi usuario (de ahí que haga falta usar sudo para desinstalar). Una vez que me di cuenta la cosa tiene fácil arreglo:

skotperez@lee:~$ sudo python3.8 -m pip uninstall virtualenv
Found existing installation: virtualenv 20.0.16
Uninstalling virtualenv-20.0.16:
  Would remove:
    /usr/local/bin/virtualenv
    /usr/local/lib/python3.8/dist-packages/virtualenv-20.0.16.dist-info/*
    /usr/local/lib/python3.8/dist-packages/virtualenv/*
Proceed (y/n)? y
  Successfully uninstalled virtualenv-20.0.16

¡Uf!

Y después de desinstalar el virtualenv anclado a la versión 3.8 de python, instalar de nuevo, esta vez usando alias (y solo para el entorno de mi usuario):

skotperez@lee:~$ python3 -m pip install virtualenv
Collecting virtualenv
  Downloading virtualenv-20.2.2-py2.py3-none-any.whl (5.7 MB)
     |████████████████████████████████| 5.7 MB 477 kB/s 
Collecting filelock<4,>=3.0.0
  Downloading filelock-3.0.12-py3-none-any.whl (7.6 kB)
Collecting distlib<1,>=0.3.1
  Downloading distlib-0.3.1-py2.py3-none-any.whl (335 kB)
     |████████████████████████████████| 335 kB 1.1 MB/s 
Requirement already satisfied: six<2,>=1.9.0 in /usr/lib/python3/dist-packages (from virtualenv) (1.15.0)
Collecting appdirs<2,>=1.4.3
  Downloading appdirs-1.4.4-py2.py3-none-any.whl (9.6 kB)
Installing collected packages: filelock, distlib, appdirs, virtualenv
Successfully installed appdirs-1.4.4 distlib-0.3.1 filelock-3.0.12 virtualenv-20.2.2

También podría haberlo instalado usando el alias python en vez de python3:

skotperez@lee:~$ python -m pip install virtualenv

En mi sistema el resultado habría sido el mismo ya que:

skotperez@lee:~$ python --version
Python 3.9.1
skotperez@lee:~$ python3 --version
Python 3.9.1

Bonus: Qué usar para crear entornos virtuales

Para hacer más interesante el laberinto, igual que hay multitud de versiones de python, hay multitud de maneras de lidiar con entornos virtuales y cada una tiene su argumentario de por qué usarla. Este hilo de stackoverflow es un buen resumen de las diferencias entre algunas de ellas, las más usadas.

Yo uso virtualenv porque me gusta que la información del entorno virtual esté en la carpeta del proyecto, aunque entiendo que esto no tiene por qué ser lo mejor en desarrollos complejos y cumple mis necesidades básicas. Últimamente he visto muchos argumentos a favor de pipenv pero a mí se me queda grande ahora mismo.

Dejar un comentario

No hay comentarios en esta entrada.
*
*

 

No hay trackbacks