Además del «detalle» observado y descrito en el post previo de esta serie, agrego las siguientes notas y consideraciones:
- La instalación que se hace con la distribución de extensión
.pkges con el usuarioroot. Todos los archivos quedan asignados aroot. Esto está bien si la instalación se hace a nivel sistema, instando para/Applications(o algún otro directorio en este mismo nivel conceptual). Si la instalación se hace a nivel de usuario (digamos en~/Applicationso a un nivel conceptual similar), el que quede todo conrootno está bien. Funcionará, pero en términos de seguridad, las cosas ya estarán quedando revueltas. - Al respecto del punto previo, si lo que se busca es instalar para un usuario en particular, la respuesta es proceder con el script BASH (la otra alternativa que se ofrece en la página de descargas de Miniconda), ejecutándolo en una sesión del usuario que hará uso de éste e instalando en
~/Applications(con el nombre que uno quiera para contener las aplicaciones deconda, e.g.miniconda3,MiniConda3oMiniconda3). Si se va a hacer uso del script para instalar a nivel de sistema debe usarsesudo(pero quizás para esto sea mejor el instalador de PKGs).
Por lo tanto, a modo de conclusiones, uno debe estar consciente de lo que quiere y para qué lo quiere. Personalmente, para alguien que se dedicará al desarrollo con Python, recurrir a Homebrew no es lo mejor (y quizás hasta sea algo que «habla de este desarrollador» 😕). Esta sería la opción para un usuario final al que se le obliga a contar con el intérprete del lenguaje para poder hacer uso de un producto, aplicación o servicio.
Sí hablamos de «un entorno separado de desarrollo con una versión específica de Python y las bibliotecas adecuadas y dependientes de dicha versión», un entorno en el que podamos agregar y quitar bibliotecas con la seguridad de que no afectaremos ese entorno del que y en el que sabemos corren nuestros desarrollos y aplicaciones en forma comprobada, valoraremos el tener dichos entornos «intocables.»
Dr. Edu 