De Python y sus demonios (3)

El tema de esta entrada, me temo, deberá ser dividido entre dos posts. Aquí registro lo que se ha convertido en otro problema (y para algunos, dolor de cabeza) y en el otro dejaré lo técnico.

Si bien en otra serie revisaba los permenores y consideraciones sobre las distintas formas en que podemos instalar Python (junto con las posteriores implicaciones para su uso) y, mucho de ello puede resolverse usando un administrador de entornos virtuales (para algunos de los cuales ya he dedicado alguna página de apuntes), lo cierto es que esta solución trae consigo también una curva de aprendizaje y algunas molestias (o problemas, según como quiera verse).

Por una parte, ocurre algo similar a lo que se revisaba anteriormente; la obsolescencia de estas soluciones llega a hacerse patente también, especialmente cuando ya se nota una determinada falta de soporte, actualización o conflictos con bibliotecas o versiones de Python. Cuando ello ocurre, el problema que surge (ante la necesidad del cambio) es sobre una nueva curva de aprendizaje y la posible migración de cosas ya desarrolladas.

Esto es un precio que muchos no consideran, pero que todos los que usamos productos de open source debemos estar preparados para pagar (de la misma forma en que sabemos que no pagamos una licencia, pero ante un problema debemos buscar en Internet una posible solución que nosotros— y nadie más —debemos aplicar).

¿Cuáles serían las recomendaciones del caso? Bueno, se me ocurren las siguientes:

  • No existe producto perfecto. Algunos nos darán esa impresión, pero es algo acotado a un contexto y momento determinados. El tiempo se encargará de mostrarnos después de que ya no lo es.
  • Por lo anterior, si bien mejor antes, debemos prever algún momento en el que nos veremos obligados a abandonar lo que adoptamos fervientemente, buscar algo nuevo (o vigente) y aprender a usarlo.
  • Así, posiblemente, una buena práctica sea el adoptar dos administradores de entornos virtuales en lugar de uno sólo. Lo más natural será que uno haya adoptado alguno que es popular (u obligado) en el entorno en el que se desenvuelve (que puede sugerir que se trata de un producto estable, maduro y con al menos una vigencia aceptable). A la par uno podrá ir «coqueteando» con algún otro, novedoso o popular también.

Referencias

  1. Sudhanva Narayana, «conda vs poetry vs uv vs pip«, blog. Visited: 2025.09.09. URL: https://sudhanva.me/conda-vs-poetry-vs-uv-vs-pip/.
  2. Alan Jones, «UV or Conda for Virtual Environments«, medium.com, web. Published: 2025.01.24; visited: 2025.09.09. URL: https://medium.com/codefile/uv-or-conda-for-virtual-environments-7372a258c7d5.
  3. Yash Jain, «Anaconda vs. uv: Which Python Environment Tool Should You Use?«, medium.com, web. Published: 2025.06.09; visited: 2025.09.09. URL: https://medium.com/algomart/anaconda-vs-uv-which-python-environment-tool-should-you-use-38b041215a06.
  4. Bex Tuychiev, «Python UV: The Ultimate Guide to the Fastest Python Package Manager«, datacamp.com, web. Published: 2025.01.09; visited: 2025.09.09. URL: https://www.datacamp.com/tutorial/python-uv.

Deja un comentario

Este sitio utiliza Akismet para reducir el spam. Conoce cómo se procesan los datos de tus comentarios.