Ya que hemos entrado en el tema de los administradores de paquetes y entornos (posponiendo otro tema del que comencé a escribir antes pero que no se me ha olvidado), hay otro administrador que ha llamado mi atención por tanta alharaca que se ha dado a su alrededor: uv. Revisé algunos artículos y opiniones al respecto de uv, así como comparaciones con otros administradores (especialmente su comparación con Conda).
Si bien mucho de lo que llegué a leer inicialmente (y muy someramente) me sugirió que podría ser la solución a mi única molestia con conda, lo que ya he leído con detenimiento no me lo confirma 🫤. Sí, tiene sus ventajas, aparentemente, y requerirá una revisión más a fondo para determinar si cumple para ser aquello sobre lo que escribí por ahí.
Como cualquier podrá leer en este blog, soy un convencido usuario de conda. Muchas entradas así lo demuestran. Para mí cumple lo necesario sin demasiadas complicaciones (o eso pensaba, ya elaboraré sobre esto) y se integra bien con el ecosistema de Python. Mi única queja es que con el tiempo, olvido el propósito y estado de los entornos que creo; problema que usualmente soluciono eliminándolos y creándolos nuevamente* (al final, para eso son).
Tenía la impresión de que uv podría ser una alternativa considerando esta molestia, pero por lo que leo, parece que me traerá otras. Curiosamente, en mi revisión de uv, me he encontrado con un par de soluciones a lo que he indicado arriba (y que es un problema compartido por mucha más gente). La solución que yo pensé haber visto era sobre ya no tener que activar el entorno de virtual explícitamente y que esto fuera automático, basado en el directorio donde uno estuviera trabajando.
La primer alternativa consiste en agregar una función a mi archivo de arranque, como la siguiente:
cd() { builtin cd "$@" &&
if [ "$1" == "pytorch-lightning/" ]; then
conda activate pl
fi
if [ "$1" == "" ]; then
conda deactivate
fi }
La idea detrás es crear un sinónimo (o reemplazo) del comando cd, en donde uno registraría los proyectos vigentes y su asociación con un entorno de conda. Claro que esta solución conlleva una labor de mantenimiento (en la creación y eliminación de los entornos), pero me ha parecido aceptable porque puede servir para documentar de alguna forma cada entorno.
Otra solución es hacer uso de una de las utilerías direnv y autoenv pero esto lleva a una nueva dependencia y con ello a otro demonio. Tienen sus ventajas, no hay duda de ello (y por lo que leo, direnv es la más robusta pero con las asociadas complicaciones). Creo que es una alternativa que vale la pena considerar, pero quizás antes deba probar la mencionada en los párrafos previos.
Y, por ahí creí que habría una tercera posibilidad, pero resultó un «alucine» de ChatGPT 🙄.
* No, el nombre del entorno no ayuda mucho. Dado que este se agrega al prompt del shell, y no me gustan los prompts muy largos, tiendo a crear identificadores cortos, de nomás de cinco caracteres por lo regular.
Siguiente
Dr. Edu 