¿Alguna idea de qué diablos está haciendo Microsoft con esta instalación de preparación?

Encontré este script de instalación msodbcsqlen odbc-driver-13-1-for-macos-released

Los contenidos relevantes son:

/usr/bin/ruby -e “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)“
brew tap microsoft/msodbcsql https://github.com/Microsoft/homebrew-mssql-release
brew update
brew install msodbcsql
#for silent install ACCEPT_EULA=y brew install msodbcsql

La parte que me confunde es la primera línea. Cuando lo ejecuto da esta salida:

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
==> This script will install:
/usr/local/bin/brew
/usr/local/share/doc/homebrew
/usr/local/share/man/man1/brew.1
/usr/local/share/zsh/site-functions/_brew
/usr/local/etc/bash_completion.d/brew
/usr/local/Homebrew
==> The following existing directories will be made group writable:
/usr/local/bin
/usr/local/include

La forma en que leo esto es que sus instrucciones de instalación no son solo para msodbcsql usando homebrew, sino que están orientadas a instalar homebrew primero, luego msodbsql.

¿Es esta una práctica común o simplemente una falta de idea de la EM?

Nota: Usualmente lo uso macports, así que me encargué de instalar homebrew en mi homedirectorio, por lo que quizás una instalación estándar de homebrew no hubiera resultado en que su script quisiera pisotear todo mi sistema.

Respuestas (1)

Esa es la forma estándar de instalar Homebrew. Microsoft parece haber escrito un instalador que se basa en la instalación de Homebrew, por lo que tiene sentido instalarlo primero.

Sí, me dio la impresión de que homebrew está instalado de esa manera, y está bien. Pero, ¿no sería más común asumir que homebrew está instalado y luego quizás tener instrucciones para la instalación en caso de que no se encuentre? En lugar de incrustar primero una instalación del administrador de paquetes. es decir, todos los demás parecen estar bien con brew install xxx. Eso sí, he visto scripts de instalación que toman cosas de github, pero generalmente porque el paquete de destino no reside en las ubicaciones de repositorio habituales. No porque el administrador de paquetes necesite instalarse.
@JLPeyret, pero entonces Microsoft tendría que soportar los problemas que se originan en las instalaciones de preparación personalizada. Al realizar la instalación de forma fija, simplemente pueden responder a los demás "¡no modifiquen el script de instalación!"