A2A.
¿Cuál es tu crítica de Homebrew (software)?
Esta es difícil de responder para mí. Realmente quiero que me guste, pero tiene un montón de cosas que yo consideraría como defectos fatales.
Daos cuenta de que un software como Homebrew está destinado principalmente a los desarrolladores de software de línea de comandos, y por lo tanto está pensado principalmente como un medio para ampliar el entorno de desarrollo de un desarrollador de software.
Está bien para hacer eso. Incluso hace algunas cosas bien que otras cosas (por ejemplo, MacPorts) se equivocan, tales como envolver los paquetes en una jerarquía de instalación, y luego instalarlos mediante enlaces simbólicos, en lugar de instalarlos directamente.
Por qué este ejemplo...
Escogí este ejemplo en particular, ya que recientemente escribí una respuesta que trata de cómo configuro el modo de desarrollador de los sistemas Mac OS X que yo personalmente uso para desarrollar software. Una de las grandes cosas es que tengo una partición de datos separada en la que vive mi cuenta de usuario, y tiendo a instalar mis Aplicaciones allí, en lugar de instalarlas en la partición de arranque del SO, porque tiendo a llevar un par de particiones de arranque al mismo tiempo.
En realidad, llevo 4 o más particiones de arranque cuando estoy trabajando en el kernel, lo que hacía sobre todo cuando trabajaba en Apple, ya que tenía que tener una partición para la versión actual, una para la próxima versión (que es en la que trabajaba principalmente todo el tiempo), y una para la versión posterior a la actual, para poder corregir los errores del kernel y de seguridad (para la próxima actualización del software). También podría llevar un par más para una comparación A/B sobre "arrancar esta partición para obtener el kernel con la corrección"/"arrancar esa partición para obtener el kernel sin la corrección".
Usando el enfoque de los enlaces simbólicos, en realidad es posible poner todo en la partición de datos, y luego enlazarlo simbólicamente en cada una de las particiones de arranque.
¿Pero sabes qué? También puedes hacer eso con MacPorts. Porque /usr/local no existe por defecto, así que bien podría ser un enlace simbólico a un directorio en la partición de datos, y entonces no estoy copiando por ahí árboles de enlaces simbólicos de Homebrew a un /usr/local en cada partición de arranque.
Entonces, ¿qué quise decir exactamente con "hace algunas cosas bien"?
Principalmente, consigue el número de versión en el directorio en el que se construye la imagen, así que tengo el número de versión de la cosa que estoy usando, y puedo elegir entre versiones.
Al añadir esta capa de abstracción, Homebrew me protege de cosas que podrían confundirse basándose en el número de versión.
Por ejemplo, usando MacPorts, podría incluir los archivos de cabecera de una biblioteca de la versión 1.5.11 cuando construyo algo, y luego algún otro paquete instala la biblioteca de la versión 1.7.2, y entonces termino usando la biblioteca equivocada con los archivos de cabecera equivocados.
Esto no sucede con Homebrew.
Suponiendo que la "receta" para la biblioteca en ambos casos es correcta, y la "receta" para las cosas que usan la biblioteca también son suficientemente detalladas. Y la "receta" para la cosa en sí o bien se salta o parchea el GNU configure para la cosa que se está construyendo, de tal manera que todas las referencias a la biblioteca y a las cabeceras están relativamente arraigadas, y puede especificar los números de versión.
Esto es mucho suponer, pero cuando funciona, es una cosa de belleza espectacular.
A la inversa, cuando no lo hace, también es bastante espectacular. No en el buen sentido.
Pero me gusta la abstracción, que hace que lo aparentemente instalado sea una visión más pequeña sobre lo que realmente se ha construido o no. La vista puede coincidir exactamente con ella, o la vista puede ser una ventana mucho más pequeña en una cosa mucho más grande.
Homebrew también tiene un par de fallos bastante malos.
Si quiero desarrollar un software que se basa en una serie de componentes de código abierto, Homebrew prácticamente no me ayudará con eso. Puedo desarrollarlo dentro de la jerarquía, y hacer un enlace simbólico para acceder a él, pero realmente no es algo que vaya a, por ejemplo, integrar en un proyecto de XCode.
Ironicamente: MacPorts es más ayuda ahí... a su manera... pero en ambos casos, estoy atascado enlazando estáticamente las librerías en un enorme binario.
Homebrew acaba siendo útil para conseguir herramientas para un desarrollador, pero no es genial en ningún otro sentido, y en su mayoría no necesito las herramientas que Homebrew consigue para mí, a menos que ya sea adicto a ellas.
Si vienes de un entorno Linux, y estás haciendo un proyecto puntual o dos en Mac OS X, y no estás usando el IDE que viene con XCode para hacer la mayor parte de tu trabajo, entonces Homebrew es probablemente un buen camino para conseguir las herramientas de línea de comandos que estás acostumbrado a usar en Linux. O BSD, si eres del tipo que instala un montón de puertos en un sistema BSD.
O simplemente podrías hacer un enlace simbólico a /usr/local en un subdirectorio en algún lugar, y utilizar MacPorts. Cualquiera de los dos.
¿Cuál creo que es el problema sin resolver?
Lo que falta en casi todo el código abierto es un gestor de componentes.
Acabas con cosas como MacPorts y Homebrew cuando intentas implementar un gestor de paquetes.
Aunque un gestor de paquetes puede instalar un componente (o incluso construir el componente - la mayoría de los gestores de paquetes son también gestores de configuración), es bastante malo para gestionar componentes.
Si se consigue algo como el sistema de puertos de FreeBSD, que es una extensión del sistema de compilación de FreeBSD, entonces se acaba consiguiendo un gestor de paquetes, un gestor de configuración y un entorno de compilación cruzada.
Linux es bastante pobre a la hora de proporcionar un entorno de compilación cruzada, lo cual es importante, si se quiere, por ejemplo, compilar en Linux, pero apuntando a ARM. Es posible hacerlo, pero gran parte de la configuración de GNU utiliza productos de compilación para procesar el código fuente en otros productos de compilación (el árbol de dispositivos del kernel para los sistemas ARM/PPC, y para el propio kernel, pero también - por separado, sin una buena razón - para CoreBoot, es un buen ejemplo aquí).
Nadie proporciona un gestor de componentes.
XCode más o menos lo hace. Eclipse puede, si usted encuentra un montón de plugins oscuros - y luego renunciar a usar algunos plugins realmente útiles que no pueden cross-target (suponiendo que usted está usando un lenguaje que compila a una arquitectura específica o microarquitectura, en lugar de Bytecode, como Java). Microsoft Visual Studio también puede, pero la mayoría de los componentes de terceros no vienen como fuente, y no han sido compilados para ARM u otras arquitecturas.
Arreglar esto requeriría tomar una gran cantidad de proyectos de código abierto, y si no exactamente bifurcarlos, llegar lo suficientemente profundo como para que te permitan poner tus partes del gestor de componentes en ellos como parte del proyecto propiamente dicho.
Si quiero configurar un entorno de desarrollo, y le faltan piezas? Yo personalmente solo arreglo los 4 o 5 errores de portabilidad en bsd.ports.mk, y ya está. Sólo hay unas pocas herramientas que uso además de las que se instalan por defecto cuando instalo XCode y las herramientas de línea de comandos de XCode.
Si tengo a alguien que viene de Linux, y quiere un montón de herramientas (pero está dispuesto a trabajar con las bibliotecas - ¡incluso las de código abierto! - desde el IDE de XCode entonces le recomiendo Homebrew. Es como "apt" para Linux.
Si van a insistir en enlazar estáticamente un montón de cosas, y están dispuestos a construir las bibliotecas en su entorno de construcción (y nunca, nunca recomiendo hacer esto: hace que sus construcciones sean tan reproducibles byte por byte como, por ejemplo, Debian Linux con reintento de paquetes, en lugar de dependencias correctamente especificadas), entonces yo levanto mis manos y sugiero ir con MacPorts.
En general?
Si usted es un desarrollador que viene de Linux y quiere un montón de herramientas, como (por ejemplo) la última versión de Emacs, y si utiliza componentes de código abierto en su proyecto, pero gestiona sus construcciones dentro de XCode - entonces Homebrew es probablemente para usted.