<div dir="ltr"><br><br>On Tuesday, September 13, 2016 at 9:47:20 PM UTC+2, Richard Eisenberg wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style="word-wrap:break-word"><div>Thanks, many, for explaining better ways to interact directly with GHC after using a `stack setup`. Perhaps, then, all that’s stopping someone like me from liking the ease of `stack setup` is a little missing PR (as in, public relations). I understand that many people want to keep GHC cloistered away to ease version swapping, but others (like me) want GHC available front and center.</div><div><br></div><div>Other minor points:</div><div>`stack env` does not work for me: my version of stack does not know how to `env`.</div></div></blockquote><div><br>That's correct—stack env was a feature request.<br><br><span style="font-size: small; font-family: arial, sans-serif;">The warning on `stack ghci` doesn't happen usually, but I'd say that's a bug (probably because it's a new install)?<br></span><br><span style="font-family: arial, sans-serif; font-size: small;">I use stack (and have contributed a bit recently), but I agree there's a few things stack could do better for this workflow.<br><br>And the transition has a rather annoying learning curve—stack ghci and stack ghc are not the same as ghci/ghc. </span><span style="font-family: arial, sans-serif; font-size: small;">I think that's on purpose to support a project-based workflow, and it has upsides, but it's a transition pitfall. <br></span><span style="font-size: small; font-family: arial, sans-serif;"> Lots of things *are* explained in </span><font face="arial, sans-serif">https://docs.haskellstack.org/en/latest/faq/, but you do need learn a few things from scratch.<br></font><span style="font-family: arial, sans-serif; font-size: small;"><br>You want stack exec ghc and stack exec ghci, and arbitrary options require a double dash `--` — use `stack ghc -- --version` or `stack exec -- ghc --version`. And I'm afraid the command syntax is mostly frozen by now.</span><br style="font-family: arial, sans-serif; font-size: small;"><br style="font-family: arial, sans-serif; font-size: small;"><span style="font-family: arial, sans-serif; font-size: small;">To support a compiler-based workflow, there are a few things planned—I opened an issue to collect them, starting from Simon Marlow's recent email:</span><br style="font-family: arial, sans-serif; font-size: small;"><span style="font-family: arial, sans-serif; font-size: small;">https://github.com/commercialhaskell/stack/issues/2546</span><br style="font-family: arial, sans-serif; font-size: small;"><br style="font-family: arial, sans-serif; font-size: small;"><span style="font-family: arial, sans-serif; font-size: small;">BTW, a system-installed GHC already works if you stick to one (and only build projects that need that). But</span><span style="font-family: arial, sans-serif; font-size: small;"> I'd love to support multiple system-installed GHCs and being able to pick the one you need.<br><br>As others already explained, giving access to stack-installed GHCs can be problematic—they're going to work, in part, exactly because you can't install in their package database.<br><br>Having stack install system-wide GHCs would IMHO risk opening a can of worms—having working binaries for all Linux distros requires some work, system installers would be harder and most users would dislike them.</span></div></div>