`stack install --compiler-specific

[mgsloan]

I am splitting this issue off from #1796, because the discussion there got long and so potentially also intimidating. I think this is a very important feature that will be great for intero and similar tools. The idea is simple:

stack install --compiler-specific will be a magical incantation that installs tools directly to the compiler bin directory. It is easy to implement, and an important enhancement, so I am marking this P1.

For global installs of GHC, it should warn that it might not have the intended semantics. Like if ghc is in /usr/local/bin, we may well be overwriting intero compiled against a different ghc, and that might not be expected.

[mgsloan]

I think it would be good to implement this before the next release. My current thoughts on this feature are:

1. Have stack path --compiler-tool-bin, yielding a path to the dir compiler-specific tools are installed to
2. Have stack build --copy-compiler-tool, which causes executables for target packages to get copied to the compiler-specific dir.
3. Have this compiler-specific dir always included on the PATH.

At first I thought it would make sense to put these within the programs directory tree. For example, $STACK_ROOT/programs/x86_64-linux/ghc-7.10.3/bin would be alongside $STACK_ROOT/programs/x86_64-linux/ghc-7.10.3/stack-tools-bin.

However, this doesn't properly handle the case of having a tool associated with a globally installed ghc. A few options come to mind:

1. Simply disallow using this feature with a global install of GHC

2. Have the tools folder be located in the ghc bin dir, possibly under the name bin/stack-tools/.

3. Default, and warn about it, and just do the install to the normal location when used with the global GHC (~/.local/bin)

I'm leaning towards doing the 3rd option. What do folks think?

[Blaisorblade]

Caveat: I have only read this issue, so might miss info from #1796.

• Option 3 (of the 2nd list) would currently break at least intero if the global install coexists with stack-managed installs: the intero Emacs mode doesn't install the intero binary if there's one on the PATH. I once installed intero in ~/.local/bin and was told that's an invalid configuration. If intero was enhanced to use this feature, it'd have to either show the warning to the user, or simply pay attention to never use it.

In other words: compiler-specific tools can't be accessible on the default PATH. Failing that, they shouldn't be accessible via stack exec for other compilers.
stack exec --package intero intero wouldn't take advantage of this option, unless we also support --compiler-specific for stack exec.

• Viceversa, with option 1, intero could just fall back to its current handling, and the same for stack users who install tools by hand (I do that with intero out of precaution, and I suppose that might be needed for some other tools).
• Option 2 might be even better, as long as the bin/stack-tools folder is inside $STACK_ROOT (and versioned by GHC version) to avoid having to write to a possibly-readonly global installation.

[Blaisorblade]

Also, pinging @chrisdone regarding intero needs.

[mgsloan]

unless we also support --compiler-specific for stack exec.

These tools would always be available on the PATH when used with a configuration that includes that particular compiler. I'm not thinking very hard about the specifics of intero, because this is a very general feature.

Option 2 might be even better, as long as the bin/stack-tools folder is inside $STACK_ROOT (and versioned by GHC version) to avoid having to write to a possibly-readonly global installation.

Yeah, it may be reasonable to have a whole new directory structure for this stuff. like $STACK_ROOT/compiler-specific-tools/$ARCH/$COMPILER/bin orso

[kadoban]

Is this blocked by anything in particular? I ask because I'd be willing to help if I'm able, if there's tasks that need to be done. I see the PR and it seemed to work based on a very minimal test.

I really like this idea, the lack of something-like-this is a lot of why I stopped bothering with fancy things like ghc-mod way back when I switched to stack, and it seems like such a nice clean way to fix.

[mgsloan]

@kadoban I wasn't 100% certain it'd solve things nicely for intero, see commercialhaskell/intero#324 . Looking back at it, this seems like a pretty good step in the direction of improving how intero works, and would be helpful for other tools.

So I think this just needs to be rebased. Probably lots of conflicts. If you're up to it, would be appreciated!

[kadoban]

@mgsloan sure, I'll certainly give it a try, should be able to manage.

Edit: working on it done, comment/progress in #2812

[mgsloan]

Got merged, so closing