Stack: Making stack live better with multiple external GHC installations

[Blaisorblade]

I found Simon Marlow's message on stack interesting:
https://mail.haskell.org/pipermail/haskell-community/2016-August/000159.html

I think stack could generally support better globally-installed GHC—we already have some issues on this (for instance about searching for system GHCs as ghc-7.10.3 instead of the path). This is a scenario for advanced users, but that includes me.
TODO: link here the existing issues and figure out whether they're sufficient.

[Blaisorblade]

Relevant issues include at least #2433 and #2430.

[Blaisorblade]

Quoting from the ML

I often get into a mess when it [stack] tries to download another GHC

@simonmar any clue when that happens? Stack usually doesn't do that on its own. Is it scripts using --install-ghc?

We might need a system-wide config setting to prevent that. If it needs to override --install-ghc it's unfortunate—we might end up needing --force-install-ghc O_O.

There are still a few scenarios where stack shouldn't install GHC, including not-yet-supported Linux distros and users of GHC on 7.8.4 on OS X—stack can't install a working GHC there (see #2558).

[simonmar]

I don't recall exactly, but doesn't stack try to download GHC if it decides that it requires a different version than the one you have installed? I would like it to just fail and tell me why, and I'd like an option to use a specific GHC binary (last time I checked it could only use whatever was ghc on your PATH).

[harendra-kumar]

AFAIK stack never installs ghc unless --install-ghc is specified on the command line or you use stack setup. It just fails asking you to do so.

[harendra-kumar]

I think one of the problems is that different projects will invariably have a different resolver set in their stack.yaml which could mean requiring a different compiler. If I want to use one specific compiler for everything I will have to go and change the resolver before building a project and then potentially use stack solver to add correct extra-deps. This is inconvenient.

EDIT: I am talking about third party code here. Of course if it is your own project you would always use a resolver matching your compiler in the stack.yaml.

If I want to use just one system compiler I would like everything to compile with that one compiler without me explicitly having to change configs every time. Maybe we should provide a global config option to pin the preferred compiler. Then we can either use a global option or command line option to ask stack to automatically create/update a stack.yaml, if needed, to use a resolver which matches the preferred compiler.

[harendra-kumar]

last time I checked it could only use whatever was ghc on your PATH

I am not sure if there are any other ways to specify the GHC binary (ping @mgsloan, @borsboom) but you could use a wrapper script around stack to specify your preferred GHC at the front of the PATH to make it choose what you want e.g.

env PATH=/path/to/your/preferred/ghc:$PATH stack

[harendra-kumar]

Some related issues:

• #1590 - stack init should use a user configurable snapshot setting as a default
• #1675 - stack init --constraint

[Blaisorblade]

I've checked again and the PATH seems the only option. So you'd want a with-ghc option, similar to with-gcc?
https://github.com/commercialhaskell/stack/blob/master/doc/yaml_configuration.md#with-gcc

Would you be happier if Stack called ghc-7.10.3 rather than GHC (by default)? Would it address your use case, or make things worse?

[Blaisorblade]

To clarify: with-ghc and calling GHC by version are not alternative proposals. The latter would support better multiple GHCs on the path.

[simonmar]

Yes, ideally we would have both: with-ghc to specify a particular GHC (e.g. a local build) and looking for ghc-<version> to find a particular version automatically (falling back to ghc and checking the version if ghc-<version> is not found).

[mgsloan]

Certainly good ideas! It'd be great to make it as easy as possible to easily develop ghc while using stack.

There is already an issue for finding the system GHC by looking for executables named ghc-<version>, though it is initially framed as an optimization: https://github.com/commercialhaskell/stack/issues/2433

I have also opened this issue, tracking optimizing the workflow for developing ghc and using the development version with stack: https://github.com/commercialhaskell/stack/issues/2633

I think between those two issues, we have this topic covered well. Please comment or re-open if there is more to be discussed!