fix(install): instalar en $HOME/.local/bin sin necesidad de root (#33)

[gtrabanco]

Goal

Resuelve la issue #33: el instalador requería porque instalaba en /usr/local/bin.

Changes

• Default de INSTALL_DIR: cambia de /usr/local/bin a $HOME/.local/bin
• Creación del directorio: se hace mkdir -p $INSTALL_DIR antes de instalar
• PATH: si $HOME/.local/bin no estaba en el PATH, se añade al proceso actual Y se escribe en ~/.profile para que persista

Testing

El script se puede testear con:

# Simular con HOME temporal
HOME=/tmp/testuser bash scripts/install.sh VERSION=v0.1.21

Verificar que:

1. El binario se instala en ~/.local/bin/nan
2. ~/.profile contiene la línea del PATH
3. No se requiere contraseña de root

[gtrabanco]

Encontré un bug ahora mismo, dame un minuto

[gtrabanco]

ya

[borjaperfra]

Gracias, Gabriel. Estoy de acuerdo en que el instalador no debería pedir root por defecto, pero tal como está el cambio hay cosas que lo rompen:

1. Rompe las actualizaciones de quien ya lo tiene instalado. Quien instaló antes tiene nan en /usr/local/bin, que va antes en el PATH. El binario nuevo se queda en ~/.local/bin y se sigue ejecutando el viejo sin que nadie se entere. Si ya hay un nan en /usr/local/bin, habría que actualizar ese o, como mínimo, avisar claramente.
2. El PATH no queda resuelto:
   • El export PATH dentro del script no afecta a la shell del usuario, porque curl | bash corre en un proceso hijo.
   • ~/.profile no lo lee zsh (la shell por defecto en macOS), y bash lo ignora si existe ~/.bash_profile. Habría que escoger el fichero según $SHELL (.zshrc, .bashrc/.bash_profile, config.fish…).
   • La línea añade el directorio al final del PATH, así que cualquier nan anterior gana.
   • La línea escrita siempre dice ${HOME}/.local/bin, aunque se haya cambiado INSTALL_DIR. En ese caso no habría que tocar ningún profile.
3. Mensajes contradictorios: dice "added it" y justo después "add this to your shell profile".
4. mkdir -p sobra: install_bin ya hace install -d.
5. Faltan actualizaciones: el README, CONTRIBUTING y los comentarios de .github/workflows/ci.yml siguen diciendo /usr/local/bin. La CI de instalación (Install from the published release) tampoco ha corrido en esta PR.

¿Te animas a ajustarlo? Si no, lo retomamos nosotros a partir de la #33.

[gtrabanco]

¡Gracias por el repaso, Borja! Todo lo que señalaste era abordable desde el propio instalador. Va punto por punto, con las pruebas al final.

1. Actualizaciones que se rompían

Antes de instalar se captura type -P nan. Si ya hay un nan en otro directorio del PATH se avisa claramente de que seguirá ganando hasta recargar el PATH, y cuando es /usr/local/bin/nan se da la orden exacta para quitarlo:

⚠ another nan at /usr/local/bin/nan is earlier in PATH and will run until PATH is fixed
⚠ remove the old one: sudo rm /usr/local/bin/nan

No actualizamos /usr/local/bin por nuestra cuenta porque volvería a pedir root, que es justo lo que la issue quería evitar. Con el PATH ya antepuesto, al abrir una terminal nueva gana el binario nuevo.

2. PATH

• Fichero según $SHELL: ~/.zshrc para zsh, ~/.bashrc/~/.bash_profile para bash, config.fish para fish y ~/.profile como último recurso. Fuera el ~/.profile fijo.
• Se antepone, no se añade al final: export PATH="$dir:$PATH", para que un nan anterior no siga ganando.
• INSTALL_DIR real: si es personalizado no se toca ningún perfil, solo se imprime la línea para añadir a mano.
• Se elimina el export PATH del proceso hijo, que no llegaba a la shell que lanza curl | bash.

3. Mensajes contradictorios

Fuera el "added it" + "add this to your shell profile". Ahora queda una sola frase: se añadió al perfil X y hay que source X o abrir otra terminal.

Caveat del PATH (lo que no se puede hacer inline)

El proceso del instalador no puede modificar la shell que lo lanzó, así que no hay forma de dejarlo listo en la sesión actual. La mitigación es ese mensaje explícito de source <perfil> / abrir terminal nueva, que ahora sale siempre que tocamos un perfil.

4. mkdir -p redundante

Eliminado; install_bin ya hace install -d.

5. Docs y CI

• README, CONTRIBUTING, el comentario del instalador de Windows y los comentarios de ci.yml ya no dicen /usr/local/bin.
• El job Install from the published release se ha adaptado al nuevo default ($HOME/.local/bin + $GITHUB_PATH) y se ha añadido un paso que verifica sin red, haciendo source del instalador, que: el fichero elegido es el correcto para zsh/bash/fish, el directorio se antepone, es idempotente, un INSTALL_DIR propio no toca perfiles y se avisa de un nan que hace sombra.

Pruebas

• 28/28 comprobaciones de un arnés local independiente (selección de perfil por shell, prepend, caveat, idempotencia, INSTALL_DIR propio sin perfil, aviso de sombra, y E2E real).
• Instalación real por pipe (cat scripts/install.sh | bash, release v0.1.23): binario en $HOME/.local/bin, PATH escrito en ~/.bashrc, nan --version correcto.
• El paso nuevo de CI pasa; al mutarlo a propósito (añadir en vez de anteponer) falla como debe.
• gofmt, go vet y go test ./... en verde.

Un apunte sobre la CI: los runs de este PR salen action_required (GitHub exige aprobar los workflows de PRs de fork), por eso no se veía correr. En cuanto se apruebe, el job correrá con estos cambios.

Mil gracias otra vez por el repaso; el instalador queda bastante más sólido. Cualquier cosa que veas, lo ajusto.

[gtrabanco]

Añadido también a la documentación (README y CONTRIBUTING) que se puede instalar para todos los usuarios con permisos de root/sudo, pasando INSTALL_DIR=/usr/local/bin:

curl -fsSL https://nan.builders/install | sudo INSTALL_DIR=/usr/local/bin bash

Como /usr/local/bin ya está en el PATH de root, no toca ningún perfil.