Esta entrada no está del todo relacionada con «Sequoia» pero es la versión del sistema operativo en la que está «sucediendo el asunto». De no encontrar otro título o lugar, se quedará en esta serie.

Lo anterior no debería ser problema. Después de todo, lo que Homebrew se encarga de instalar y la administración de dependencias de bibliotecas o programas que se necesitan es una enorme ayuda. Sin embargo, el problema se presenta cuando la gente se abandona a dicha facilidad, cuando se abandonan a este administrador y se olvidan de hacer lo propio: administrar lo que instalan en su equipo. Desafortunadamente, cuando los errores empiezan a surgir es ya indicio de alguna complicación que puede estar más allá de una solución simple, implicando tener que borrar y reinstalar algo (el paquete descargado por Homebrew, el paquete o aplicación con la que se choca o al Homebrew mismo).

En un inicio, me pareció un poco extraño lo anterior pues mi percepción es más de hacer uso de Homebrew para instalar utilerías o bibliotecas de soporte y no tanto el objetivo de la instalación. Sí, estoy consciente que, por ejemplo en el caso de Python, uno puede recurrir a Homebrew para instalar Python (que sería el objetivo del asunto) pero en este caso, además de la instalación vía Homebrew, hay opciones de descarga y de compilación del producto en cuestión. Me llamó la atención que para el caso de Apache Spark, desde la página del proyecto mismo se diera este curso de acción como principal opción de instalación.

Adicionalmente algunas preguntas surgieron. ¿Realmente conviene o es necesario recurrir al Homebrew para esto? ¿No sería más conveniente hacer una instalación nativa (descargado un binario o compilando) el objeto de la instalación? ¿Habrá diferencias de desempeño entre estas opciones? Al respecto de esto último, mi primer pensamiento fue sobre un «sí», y supuse que Homebrew debe instalar un binario genérico, en el mejor de los casos, que puede no sacar todo el provecho de alguna característica del equipo (sobre todo el que se instale un «binario universal», que por razones de «universalidad»– aunque no puedo asegurarlo –implique un performance menor).

Para el caso de Scala, por ejemplo, la instalación de éste (del intérprete, procesador o compilador del lenguaje) se puede hacer por Homebrew o a través de su propio administrador de paquetes (o «artefactos», como parece que así es la terminología del entorno de Scala): Coursier. Lo curioso aquí es que Coursier puede ser también instalado por medio de Homebrew. Tal vez algunos de quienes lean esto, y sean también usuarios de Homebrew no vean problema en esto, pero en lo particular, a mi me causa cierta aprehensión. No veo muy positivo una excesiva dependencia sobre Homebrew. ¿Qué pasa si algo corrompe archivos de control o estructuras de directorios de Homebrew? No es común pero me ha pasado, y he optado por eliminar y reinstalar Homebrew. Teniendo pocas bibliotecas u utilerías instaladas a través de éste, es sencillo recuperarse de algo así, pero ello se va complicando conforme vamos dependiendo más y más de este administrador de paquetes. Personalmente yo prefiero que cada cosa tenga sus propios espacios de almacenamiento, así como procesos de instalación y eliminación que me den la seguridad que puedo eliminar completamente todo el paquete.