Me topé con algo curioso al instalar Conda 4.11 en macOS «Big Sur«. He instalado este administrador de paquetes y entornos virtuales de Python desde hace tiempo y, según yo, aunque sí había reparado en algunas anomalías, no eran tan problemáticas. Ciertamente, no me había puesto a verlas con detalle hasta ahora y que, a raíz de irlas escribiendo, caigo en cuenta que son más bien un problema del instalador y no de Conda en sí.

Para el caso de macOS se ofrecen dos alternativas de instalación (sin tomar en cuenta la opción para Apple Silicon): mediante un script BASH y la otra para ser usada con el instalador de paquetes de macOS (archivos .pkg).

La idea de hacer uso de un script de un shell de unix no siempre resulta atractiva y uno tiende a irse por los instaladores que hacen uso de la GUI. Sin embargo esta vez se han presentado se presentaron inconvenientes que me llevaron a revisar el asunto.

Cuando uno hace uso del instalador de paquetes de macOS, después de aceptar el Software License Agreement, uno llega a esto:

El mensaje de error desaparecerá si uno selecciona algunas de las opciones habilitadas (aunque parezca que la opción ya indicada por defecto (Install only for me) dé lugar a dicho error.

Desaparecido el error, se habilitarán los botones y dando click en Continue y posteriormente en Install (ver imagen más abajo), el proceso de instalación iniciará y sólo requerirá acceso al directorio donde se descargó el archivo .pkg (al menos eso ocurre en macOS «Big Sur» en un equipo «Intel inside«) al final del proceso. El resultado es la instalación de Miniconda3 en la ruta $HOME/opt, más la creación o modificación de algunos archivos ocultos (de configuración y profiles) en $HOME.

Por otra parte, si en esta pantalla de selección de ruta de instalación se opta por seleccionar un disco y en éste un folder donde instalar Conda, el resultado será la instalación de Conda en la ruta indicada, bajo propiedad del usuario con el que se hace la instalación (aunque bajo el grupo wheel) con la posible creación (bajo propiedad de root) o modificación de archivos ocultos en $HOME.

Ahora bien, si en un intento se cancela la instalación al momento de pedir credenciales administrativas (lo que hace sospechar que por aquí hay un problema de seguridad), que ocurre cuando se selecciona la opción de indicar el disco donde instalar (aunque sea al final la misma ruta que para Install only for me)

en el siguiente intento, se llegará a la pantalla de instalación. Si desde ésta, y sin hacer ningún cambio, se procede con la instalación, el resultado será que se hace en /opt y la posible creación de archivos ocultos en $HOME bajo propiedad de root.

El punto y problema aquí son esos archivos bajo propiedad de root que pueden quedar. Si uno no tiene acceso a alguna cuenta administrativa para ajustarlos en propiedad o permisos, se vuelven un dolor de cabeza después.

Finalmente, haciendo uso del script BASH no presenta esos problemas. La ruta de instalación se respeta y es posible modificar también el nombre del directorio con el que quedará el directorio de miniconda3 (para aquellos que deban seguir alguna política o simplemente no les gusta ver nombres de directorios en minúsculas). Todos los archivos y directorios quedan bajo propiedad del usuario con el que se hace la instalación^*.

Conclusiones

Aun cuando el equipo tenga un único usuario (incluso si éste tiene acceso administrativo al equipo) resulta conveniente instalar software para dicho usuario, es decir en el directorio $HOME/Applications de la cuenta de éste. Claro, esto dependerá de que el software lo permita (que no requiera ser instalado en /Applications y que sea sólo usado por dicho usuario). Hay que tener presente el tamaño de la aplicación. No resultaría muy práctico tener una aplicación de 10GB instalada en dos o más cuentas de usuarios, más si se trata de una aplicación de uso general, como puede ser la suite de MS Office. Pero, para una utileria, que no requiera más que algunos megas cuando mucho y que puede ser usado por algunos pero no todos los usuarios de un equipo, puede ser una opción práctica y adecuada (en términos de seguridad).

Adicionalmente, la distinción entre el Applications general y el del usuario ayuda también a determinar qué software fue requerido adicionalmente al provisto por el sistema operativo. Ayuda a perfilar roles y usuarios.

Finalmente, si bien lo descrito aquí puede ser un problema muy específico del instalador de macOS en «Big Sur«, debe tenerse en cuenta no confiarse ciegamente de lo que éste hace. Considerar los instaladores basados en shell script es importante también, especialmente si se busca una mayor flexibilidad para instalar algo (claro, depende del script, pero a diferencia del instalador de paquetes, un script puede ser inspeccionado e incluso modificado… si, ya sé, este último punto puede ser un problema pero no hay soluciones perfectas, sólo voluntades honestas y malvadas).

*Mientras se tenga acceso a la ruta seleccionada, por supuesto.