Add support for overriding variables such as `INSTALL_BASE`

I notice global vars such as

INSTALL_BASE="$HOME/.ghcup"
GHC_LOCATION="$INSTALL_BASE/ghc"
BIN_LOCATION="$INSTALL_BASE/bin"

which would be desirable to allow to be customized in a way that survives self-update; I can think of two common options, either

1. have vars such as INSTALL_BASE default to set the value of e.g. a GHCUP_INSTALL_BASE env-var if it's set and non-empty (useful for export GHCUP_INSTALL_BASE=... in your .profile script), or
2. simply add a couple long-opts, --install-base=, --ghc-location=... etc (this however requires using an alias in your .profile scripts if it's supposed to be a persistent setting)

I think that's tricky. Overwriting INSTALL_BASE (if done wrong) might result in very unexpected and dangerous behavior when we recursively remove ghc versions:

https://github.com/hasufell/ghcup/blob/644a2829e4fc24d752ec370f27bf1a6f89c4a68f/ghcup#L770-L785

It will make validation more complicated. Did the user do something weird or funny? The only thing that should be supported here, imo is changing HOME, which ofc is already possible, but not really an option to control this script behavior.

So, controlling the <something> directory of <something>/.ghcup is quite possible and safe. Would that suffice? I would simply exchange that for an environment variable that defaults to HOME.

@hasufell Well, the motivation is that a very common layout (mostly because I made it popular :-) ) is to install into /opt/ghc/<ver>/ and put symlinks into /opt/ghc/bin. This is e.g. what my PPA does as well as what https://haskell.futurice.com/ does; and even when I manually install ghc from bindists on non-Debian/Ubuntu, I manually set-up that fs-layout for consistency.

Add this point I think we should have a config file that is just sourced and implement https://github.com/haskell/ghcup/issues/18 which would allow to be less conservative about locations

Created by: Franciman

Hi I'm using ghcup in my project, and I'm really interested in this feature, could you give me some more details that you think are important, so that I could implement it?

What is the use case? I really don't like the idea of configurable directories. It's hard to make assumptions in the script. The configured directory may be a file, missing, point to / accidentally or other funny things. Then users will report "your script wiped my whole home directory", because although we require user interaction on rm -rf, people may just hit enter anyway or miss the message.

ghcup is not a package manager and has no knowledge of installed files. I would rather keep it simple, unless we have good reasons to complicate it.

Created by: Franciman

It's hard to make assumptions in the script. The configured directory may be a file, missing, point to / accidentally or other funny things. Then users will report "your script wiped my whole home directory"

If you only customized where the .ghcup dir would be created, i.e. if you had a customizable variable INSTALL_BASE_PREFIX and defined:

INSTALL_BASE="${INSTALL_BASE_PREFIX}/.ghcup"

that wouldn't be an issue, because ghcup only works inside INSTALL_BASE and at most deletes INSTALL_BASE, which was created by ghcup, anyways. Also, if you mistakenly assign INSTALL_BASE_PREFIX to a file, then the mkdir at https://github.com/haskell/ghcup/blob/master/ghcup#L1709 fails. Otherwise, if you assign INSTALL_BASE_PREFIX to a missing directory, the mkdir -p at that line will create it (this may be problematic, maybe).

Although, now I see that this wouldn't be sufficient to support hvr's layout. To support that, the first thing that comes to my mind is that you could change the directory structure, and have $INSTALL_BASE/.ghcup/ghc contain both the version directories and the bin directory with the symlink to the active ghc. In this way other layouts could be obtained with symlink. E.g. hvr's layout is simply a ln -s "$INSTALL_BASE/.ghcup/ghc" /opt/ghc And you can also have two separate symlinks, one to versions and one to $INSTALL_BASE/.ghcup/ghc/bin with the active version.

As far as the use case is concerned, if it doesn't pose many issues, it seems like a cool flexibility to have.

that wouldn't be an issue, because ghcup only works inside INSTALL_BASE and at most deletes INSTALL_BASE, which was created by ghcup, anyways. Also, if you mistakenly assign INSTALL_BASE_PREFIX to a file, then the mkdir at https://github.com/haskell/ghcup/blob/master/ghcup#L1709 fails. Otherwise, if you assign INSTALL_BASE_PREFIX to a missing directory, the mkdir -p at that line will create it (this may be problematic, maybe).

That sounds possible.

Although, now I see that this wouldn't be sufficient to support hvr's layout.

That's a different question and I don't see any use for that currently. Changing layout is also quite intrusive, requires more code change and may break assumptions of users.

GHCUP_INSTALL_BASE_PREFIX is overwritable

closed