Abstract:
Usar ‘sudo pip install’ siempre es mala idea, más aún si lo que queremos es instalar aplicaciones Python en nuestro ordenador. Te contaré como funcionan las dependencias en Python. Por qué es mala idea instalar cosas dentro del Python del sistema, en el entorno de tu propio usuario. Qué son y por que es mejor usar virtualenvs. Y de como puedes despreocuparte de lo anterior usando pipx.
Bio:
También conocido como tinproject, Agustín es Ingeniero Técnico en Telecomunicación, segoviano, y un enamorado de Python.
Actualmente va saltando entre Dev y Ops, gestionando infraestructuras y dando forma a plataformas, todo para facilitar que la gente se centre en aportar valor de manera continua.
Por si alguien tiene curiosidad, quien se encarga de cargar las carpetas de dependencias de terceros (site-packages) es el módulo site de la librería estándar que se llama implícitamente al iniciar Python.
En la documentación se explica como lo hace: https://docs.python.org/3/library/site.html
Yo uso conda env -n tools para tener herramientas en un entorno tools y luego creo ‘alias’ a las herramientas. En mi caso tengo un entorno windows corporativo muy limitado que no me permite instalar nada system-wide y que me obliga a hacer ese tipo de chapuzas. ¿Crees que pipx podría ayudar a tener un entorno más limpio?
P.D.: Otra ventaja que le veo a conda es que me permite intalar git, qgis o postgresql de forma sencilla y creo que con pipx no sería posible.
Pipx está pensado para instalar aplicaciones en tu usuario, no a nivel de sistema. En el fondo no es más que un wrapper para crear y gestionar virtualenvs de manera transparente.
Yo los despliegues en producción los suelo hacer con su virtualenv correspondiente, cuanta menos magia mejor.
Personalmente no me gusta el acercamiento que sigue, es tratar de seguir otras ‘formas’ que se usan con otros lenguajes y meterlo con calzador en Python. He usado rbenv, bundler, npm, composer, y en esos casos si tienen sentido los ficheros .lock, en Python creo que choca un poco contra la propia filosofía del lenguaje.
El no poder tener varias versiones de la misma dependencia, y el usar un único namespace plano, hace que fijar las dependencias concretas sea mucho más difícil en Python. La respuesta de la comunidad a esto ha sido hacer librerías donde se respeta el interfaz a lo largo de diferentes versiones, y usar ciclos de deprecación largos, por eso de la ‘una única manera obvia’.
Esto al final lleva a usar siempre la última versión, lo cual es una ventaja en términos de seguridad y mantenibilidad del código, pero tiene sus desventajas cuando uno se enfrenta a cambios que rompen la retrocompatibilidad.
Todavía queda mucho camino en la gestión de dependencias en Python. Yo creo que Poetry va más encaminado, aunque hace falta una definición estándar (están en ello).
Pipx hace básicamente lo mismo pero sin que tengas que dar tantos pasos. Internamente crea un venv por herramienta que instales.
Puedes instalar pipx en el entorno de conda e instalar las herramientas con pipx en otro nivel. Al final el objetivo es que sea transparente y que puedas usar tus herramientas sin preocuparte de como se han instalado.
.