Stack in HP does not find installed msys when using system ghc

[snoyberg]

Actions:

1. Install HP Minimal on a Windows system (I did it without any prior GHC or Stack install, Windows 10)
2. Open up a normal command prompt (cmd)
3. Run stack --resolver ghc-8.0.1 build network

Expected: installation succeeds

Actual: fails since the ./configure script cannot be run, since stack cannot find the sh command

[snoyberg]

It installs its own GHC instead of using a system installed GHC. When using its own GHC, it installs msys alongside it. I think I discussed this with Mark eons ago as an issue that needed to be looked out for.

Thanks for the prompt response.

[gbaz]

ah, so the "stack setup" process would have solved this then, i see. and because there is an installed ghc, stack setup is bypassed. this is definitely worth fixing.

[snoyberg]

Note that this could be resolved by changing the default from --system-ghc to --no-system-ghc. But that is just admitting that there's no practical advantage to users of having the system installed GHC. We had similar issues with MinGHC.

[snoyberg]

Relevant Stack discussion, since broken system-wide installations have been a perennial problem (affects things like docs and profiling libs too, for instance): commercialhaskell/stack#2537

[gbaz]

So we do install an msys with the minimal hp windows installer. Stack doesn't know how to find it though. I'd like to find the lowest-impact way to make it possible for this to happen.

[snoyberg]

I haven't hacked on Stack in a while, so my ideas may be out of date. Perhaps Stack could be taught to respect an environment variable specifying an msys location on the system. MinGHC solved this by just putting the msys tools on the PATH, but I believe there was resistance to doing that in HP.

Note though that this change may just push problems downstream: Stack is tested with specific msys versions, and if the msys shipped with HP mismatches significantly, there's potential for different failure modes. That may not be a major concern, I'm not sure how much msys has moved recently. The msys 1 to msys 2 move though would be an example of a major issue.

[gbaz]

Ah this is unfortunate. Stack takes --extra-include-dirs and --extra-lib-dirs but not --extra-prog-path. Arguably, it should just for symmetry's sake, regardless of how this issue ends up getting resolved.

It also seems that stack has already merged the no-system-ghc by default for the next release? so any solution here will be over the lifespan of whenever a new stack comes out and a new platform includes it...

[snoyberg]

That PR is still open, unless you're looking at a different commit that I'm not aware of. I just looked at open PRs and found the one I referenced above.

[gbaz]

ah you're right i misread

[snoyberg]

Just for the record, I raised this in the initial issue about adding MSYS to HP: #207.

[gbaz]

Ah found the appropriate issue on the stack tracker.

commercialhaskell/stack#1714

It seems pretty straightforward that if we can point stack to a system ghc, we should also be able to point it to a system msys.

Shame that some poking didn't let me find any real workaround outside of --no-system-ghc

[snoyberg]

I really am not trying to start a new fight, just prevent a lot of wasted time by users and Stack maintainers. Do we really have to devolve to title edits and shifting blame here? Issue #207 clearly stated changes that needed to be made to HP, cabal-install, and Stack. The changes were made to HP and cabal-install, and the issue closed before making the changes to Stack. That's clearly where the problem is coming from.

[gbaz]

I don't want to start a fight, honest. The title edit was purely for clarity. I'm not interested in shifting blame -- I spent about an hour seeing if I could work around this without needing to ask stack for any changes and I can't find a way, and then I hunted down the ticket for reference. I certainly treated #207 as mainly about solving the HP side of this, and understood that stack would just pull its own msys if it couldn't find a system one. I was obviously mistaken in that regard, and as we were testing with ghc 8 but against a stack resolver with ghc 7, the stack setup always took care of this for us and we didn't see the issue. I honestly don't care about blame at all and I'm happy to attribute it to whatever.

And I agree we should get it fixed, regardless, though I do think directing people to use --no-system-ghc for the time being is an adequate, if suboptimal workaround.

[snoyberg]

That's a command line argument that needs to be passed on every single invocation. It's not a real solution. Honestly, just having a patched version of Stack in HP that changes the default would be a better solution.