Replace GHCUP_INSTALL_BASE_PREFIX with GHCUP_HOME

For those who move ~/.ghcup out of their home directories, having .ghcup be a hidden directory is pointless (eg I have GHCUP_INSTALL_BASE_PREFIX=~/.local/opt). It would be preferable to just be able to set GHCUP_HOME=~/.local/opt/ghcup.

A more ambitious version of this would be to XDGify ghcup, but that's much more effort than this itch warrants.

I specifically decided against that option, because it allows for more user errors.

If a user sets GHCUP_HOME=$HOME, then ghcup will think it is safe to mess around with files and directories inside $GHCUP_HOME... while it isn't.

The current design gives us this safety guarantee that .ghcup is managed by ghcup and nothing about the parent directories is known.

Fair. Can the ghcup directory at least not be hidden when the prefix isn't $HOME?

I think that's problematic and counter-intuitive... e.g. if someone moves the .ghcup folder from $HOME location somewhere else... it suddenly doesn't work anymore. I think a static subfolder name is important.

That's the behavior of dozens of programs

That might be true for XDG support (there are only two options). Arbitrary relocatable directory is something different. Yes, there could be a runtime check:

if [ $GHCUP_INSTALL_BASE_PREFIX = $HOME ] ; then
  use .ghcup
else
  use ghcup
fi

However, I'm still not sure that's intuitive. It will also be backwards-incompatible and may break existing installations. Now you need to support both formats for compatibility and pick an arbitrary one if both exist...

Which is why I suggested the GHCUP_HOME method to begin with.

• By changing the name, gives a clean break
• Has clear semantics
• Supports old workflows As to the point that a wrong setting can smash $HOME, the same could be said for pointing the data directories of any other program at $HOME. As long as the default is safe and the semantics are clear, I suspect this bug will never be triggered.

Alternatively, we could go the XDG route and use the logic

if [ -d "$XDG_DATA_HOME/ghcup" ] ; then
 GHCUP_HOME="$XDG_DATA_HOME/ghcup"
else
 GHCUP_HOME=~/.ghcup
fi

or something similar. We'd need to figure out the correct XDG semantics, but this has all of the benefits of the above, a savings of one envvar, and the idiotproofing of working within a subdirectory.

Which is why I suggested the GHCUP_HOME method to begin with.

Now both variables are set, what's the semantics?

As to the point that a wrong setting can smash $HOME, the same could be said for pointing the data directories of any other program at $HOME

I cannot follow this reasoning. As you can see with the link you just gave wrt XDG... the user does not have the control to choose the directory, only the base of it via XDG_ variables.

Not every ghcup user is a power user and I've seen people do weird things in the past. Until now, ghcup has not wiped anyone's home directory and I want to keep it that way.

---

Being xdg compliant is an idea. That can be done backwards-compatible like any other app. But it is still disruptive, because simple instructions like rm -rf ~/.ghcup don't work anymore, if the new location by default is XDG. I'm dealing with a lot of users that are novice on the command line and need help with understanding what the PATH variable is (which will now also need to account for multiple possible locations). If ghcup location depends on ghcup version, environment variables and runtime semantics, then it will most certainly increase my support burden.

What I could think of is a global switch that triggers xdg behavior. Then you could add to your bashrc/whatnot alias ghcup='ghcup --xdg' and it would use xdg directories only (and still not allow to choose the final directory component).

Now both variables are set, what's the semantics?

Hrm. You're referring to the potential that a user has both the old and the new environment variable lying around? My intuition would be that the newest way of referring to the data directory would take precedence.

I cannot follow this reasoning. As you can see with the link you just gave wrt XDG... the user does not have the control to choose the directory, only the base of it via XDG_ variables.

Fair if we're considering XDG support. However, programs have permitted setting the data directory directly, e.g. STACK_ROOT. Considering the user base, as you've pointed out, that would be a dangerous path to go down, though.

---

To recap, we have the following options:

method	logic	no bad configs	can be made visible	backwards-compatible	consistent with world
GHCUP_INSTALL_BASE_PREFIX (current)	${var:-$HOME}/.ghcup	yes (subdirectory)	no (subdir=.ghcup)	yes	no (cf STACK_ROOT)
GHCUP_HOME	${var:-$HOME/.ghcup}	no (GHCUP_HOME=HOME)	yes	yes (fallback)	yes (cf STACK_ROOT)
autohide (current w/ hiding logic)	$HOME/.ghcup:$var/ghcup	yes (subdirectory)	yes (move out)	no (when customized)	no, but emulates world behaviour. counterintuitive, though
XDG	`$XDG_DATA_HOME/ghcup	yes (subdirectory)	yes (by definition)	no* (see below)	yes

Notes:

• Moving dir without changing config breaks things, but presumably users moving directories around know to change config
• Consider userbase: we have novices, for whom things should Just Work™, and we have power users who might be trusted not to break things
• Re XDG option, have several options for how to maintain backwards compatibility:
  • fallback (e.g. look for $XDG_DATA_HOME/.ghcup, ~/.ghcup as well)
  • hide the behaviour behind a switch (e.g. --xdg)
  • fully convert to XDG behaviour, automatically moving ${GHCUP_INSTALL_BASE_PREFIX:-$HOME}/.ghcup to the XDG dir

Note that we install binaries, but xdg spec does not specify where they go. ~/.local/bin is not an XDG directory.

True. It is in https://www.freedesktop.org/software/systemd/man/file-hierarchy.html though, so that's something. PEP 370 also makes that choice

I neither like nor use systemd

But that doesn't matter. I'm just pointing out there will be decisions to make outside of the standard. Not sure if XDG compliance buys us much.

Sure. The standard gives us a nice way of making this arbitrary choice that follows the general current Linux trend, but as pointed out we will need a little more to buy backwards compatibility.

mentioned in commit 875b7236

mentioned in commit b52acfcc

PR is open. If you want this to get in for the next release, you can do some testing, otherwise I'll create a separate PR and give it low priority.

Sorry, had a mad couple of days. Will test tomorrow, though a cursory look at the code lgtm.

The usage message doesn't mention the xdg option, but apart from that a quick strace suggests all's well. My build environment doesn't complain either. A little annoying to have yet another envvar to carry around, but it is the best I could expect under the circumstances.

mentioned in commit aac8f760

closed

I made a pre-release with xdg support: https://gitlab.haskell.org/haskell/ghcup-hs/-/jobs/415743/artifacts/download

Can you give it another whirl?

Checked behaviour with and without `GHCUP_USE_XDG_DIRS, lgtm. However, still missing mention of that var in usage message. But that's my only problem with the patch.