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.

[gbaz]

See my comment commercialhaskell/stack#1714 (comment) -- the msys bin folder will always be in a consistent place with regards to the ghc binary, so a little logic in stack to search for it via this convention wouldn't have to bake in any knowledge of HP as such or of cabal config files. That would avoid the command line issue and also mean everyone could use the same consistent stack binaries.

[snoyberg]

I'll have to defer to the current Stack maintainers on whether that will work. Any recent patches I've sent to Stack have only made things worse, so I'm taking a break in hacking on it.

[jmchapman]

I cannot even find stack on my windows install of HP minimal 8.0.1. Other things are in my path, ghc, cabal, cabal installed binaries etc. Where is it installed?

[gbaz]

%APPDATA%\local\bin (which translates often to AppData\Roaming\local\bin).

It's a good observation that we may want to auto-add this to the system path as well. (The stack installer doesn't, not sure why). Opening a separate ticket for that.

[jmchapman]

I don't have %APPDATA%\local\bin.

My %APPDATA% points to a network drive. I have %APPDATA%\cabal and %APPDATA%\ghc but no local

[gbaz]

The ticket for this is #252 now -- just created. Note that that folder will translate (As per https://docs.haskellstack.org/en/stable/install_and_upgrade/#path) into something like "c:\Users\YOURNAME\AppData\Roaming\local\bin""

[bitemyapp]

I've commented on the downloads page issue, haskell-infra/hl#176 (comment)

I think it would better serve users if Stack wasn't packaged with HP at all. If they don't reach Stack via the Stack documentation, it's just a waste of disk space as they will not know it's there or how to use it.

Not that Haskell.org currently explains cabal-install either, but it cleans things up and reduces the number of possible failure modes for the HP install.

[acfoltzer]

I think it would better serve users if Stack wasn't packaged with HP at all. If they don't reach Stack via the Stack documentation, it's just a waste of disk space as they will not know it's there or how to use it.

This is not universally true. Even with this Stack bug that causes problems on Windows, it has been extremely useful for us to have all the tools in one installer. And to the extent that everyone agrees there should be one unambiguous choice to highlight on the download page, removing Stack from HP would make this impossible because we'd be left needing to highlight at least two choices.

[randen]

If wasting disk space is concerning (installed, it takes up 41,095,168 bytes on my 64-bit Windows 7 system), the HP UI has a checkbox (defaulted to "checked" meaning "yes, install") in order to allow the user a choice to not install stack. We incorporated stack since that was the specification/requirement as agreed upon (in the "Improving the "Get Haskell Experience""). We chose to make it an option in the UI. We chose the default to be "yes, install" to align with the "Improving" proposal.

[gbaz]

I think the original issue described can be resolved by commercialhaskell/stack#2552

[gbaz]

should be fixed in 8.0.2 release.

[alemonmk]

Sorry for necro, but I'm sad to notify that with Haskell Platform 8.0.2-a on Windows and manually added extra-prog-path/extra-lib-dirs/extra-include-dirs into cabal config, stack install still fails with same Continuing despite missing tool: msys2 and ./configure script nonsense on e.g. stylish-haskell and ghc-mod. Tried upgrade stack to 1.4.0, still fails.

Maybe I miss something? In specific I'm installing those to ide-haskell from Atom, from the ground up.

Or I can just let stack install another copy of msys2 and GHC ...

[gbaz]

Yes, the recommended approach is to let stack install its own msys.

…

On Sun, Jun 18, 2017 at 10:53 AM Lemon Lam ***@***.***> wrote: Sorry for necro, but I'm sad to notify that with Haskell Platform 8.0.2-a on Windows and manually added extra-prog-path/extra-lib-dirs/ extra-include-dirs into cabal config, stack install still fails with same Continuing despite missing tool: msys2 and ./configure script nonsense on e.g. stylish-haskell and ghc-mod. Tried upgrade stack to 1.4.0, still fails. Maybe I miss something? In specific I'm installing those to ide-haskell from Atom <https://atom.io/packages/ide-haskell>, from the ground up. Or I can just let stack install another copy of msys2 and GHC ... — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#251 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABEt2foIqK9APShP5MGrkQmttq_zE5-1ks5sFTndgaJpZM4JwInx> .