Feature request: like "system-ghc" but for multiple preinstalled versions of ghc

[DanBurton]

For context, see: https://www.reddit.com/r/haskell/comments/85abjj/why_does_stack_install_its_own_version_of_ghc_and/dvy3lsu/?context=3

Example usage:

stack setup ghc-8.4.1 --ghc-path /opt/ghc/8.4.1

Desired behavior: inspect the given --ghc-path to ensure that a GHC with the correct version exists at this location. Whenever compiler: ghc-8.4.1 is required, use this particular ghc.

In contrast with system-ghc: true, this allows the "system" in question to have multiple custom versions of ghc installed, and for stack to automatically select the correct one, without needing the assistance of nix, docker, or manual path mangling.

Something like this can currently be accomplished in a hacky way by manually making symlinks, but there should be a nicer interface for this workflow.

[ygale]

TBD (asked by Dan on the reddit thread, and I'm expanding a bit): How do we handle compiler attributes like arch and variant? Do we just use defaults? Do we provide additional optional parameters to specify these? Or do we use a special fixed "variant" to indicate that this is a manually installed compiler?

[ygale]

@DanBurton said we would look at the compiler at the specified path to verify it. Would that detect arch and variant? If so, the previous TBD is moot.

[borsboom]

I think overall I like #3935 better if you're using stack setup (please comment if your approach has advantages I'm not thinking of), but --system-ghc support for multiple system installed GHCs would be a nice addition.

In addition to be able to specify the potential GHC paths, it could look on the PATH for ghc-X.Y.Z, ghc-pkg-X.Y.Z, since GHC's make install will support multiple versions that way (and, theoretically, system package managers could also support that, although I'm not aware of any that do).

Also possible, although I'm not sure if it's a great idea, would be automatically looking for some common paths like /opt/ghc-X.Y.Z/bin as used by hvr's bindists.

@ygale I don't think --system-ghc can do anything with the compiler builds/variants, so your #3935 is a nicer approach there.

[ygale]

@borsboom This issue and #3935 are orthogonal.

This issue is to support multiple pre-installed GHCs, not just the one on the PATH, without requiring shell-script/environment-variable hackery.

#3935 is to allow a GHC - whether installed by stack or otherwise - to be shared by multiple users on a server.

Do you have a different idea about how to implement this issue? I think my proposal is dead simple to implement.

[ygale]

OK never mind the arch/variant stuff. I blew the scope. Let's keep it simple - I'll amend the proposal to exclude that. It can be added later if people want it.

EDIT: Oops, @DanBurton proposed it, so I can't amend it. Well, just add this:

The arch and variant is exactly the same as what it would be if you install a GHC without --ghc-path.

[snoyberg]

This will be addressed by #2433

[ygale]

This issue is for people with multiple non-stack-installed GHC's on their system that are not on the PATH. I don't see how #2433 helps that.

It is bad practice to have multiple versions of GHC (or any large system) on the PATH. Modern OSes have various methods for managing multiple versions of things. Stack shouldn't be opinionated about that, and certainly shouldn't require using the "put it all on the PATH and pray" method.

If the decision is to close this issue as "won't fix", then so be it. But I hope that means that the .stack/programs symlink hack will continue to be supported, at least unofficially.

[Blaisorblade]

You seem to view modifying PATH as some undocumented feature, while that seems a standard way of doing things. I only see one objection: then users have to use Unix features and Unix has bad usability/it's hard to learn to use Unix correctly. But this is an advanced feature, and it seems the target audience of this feature doesn't have this problem.

Last, keep in mind that resources to develop and maintain Stack are limited - #2433 took quite a while, and this is more complex.

It is bad practice to have multiple versions of GHC (or any large system) on the PATH.

Why? Citation needed?

Modern OSes have various methods for managing multiple versions of things.

Which? I can only think of language-specific ones (e.g. rbenv/RVM for Ruby), not from OSes, or of Docker — which the original requester doesn't want. Oh, and modifying PATH.

Stack shouldn't be opinionated about that, and certainly shouldn't require using the "put it all on the PATH and pray" method.

I mean, the ghc from the later versions will be ignored, and only ghc-X.Y.Z used. Semantics of PATH are standardized, no praying seems involved. Last, I understand that config is used by GHC developers using cabal — and the only option when Stack gets GHC from the OS.