"stack setup" output mentions "locally installed GHC" which is terribly confusing

[varosi]

on Windows 8, stack 1.1.2

There is no locally installed GHC:

ghc --version
'ghc' is not recognized as an internal or external command,
operable program or batch file.

stack setup --reinstall
stack will use a locally installed GHC
For more information on paths, see 'stack path' and 'stack exec env'
To use this GHC and packages outside of a project, consider using:
stack ghc, stack ghci, stack runghc, or stack exec

[mgsloan]

What about stack exec -- which ghc, stack exec -- ghc --version ?

Will re-open upon further details.

[varosi]

Running from cmd.exe (Windows Console) inside my project's folder where there is stack.yaml:

stack setup --reinstall
stack will use a locally installed GHC
For more information on paths, see 'stack path' and 'stack exec env'
To use this GHC and packages outside of a project, consider using:
stack ghc, stack ghci, stack runghc, or stack exec

stack exec -- which ghc
/c/Users/home/AppData/Local/Programs/stack/x86_64-windows/ghc-7.10.3/bin/ghc

stack exec -- ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.10.3

ghc --version
'ghc' is not recognized as an internal or external command,
operable program or batch file.

[varosi]

I couldn't not reopen it.

[sjakobi]

Is this a misunderstanding about the line "stack will use a locally installed GHC"?

It does appear as if the ghc in /c/Users/home/AppData/Local/Programs/stack/x86_64-windows/ghc-7.10.3/bin/ghc is present, right?

[mgsloan]

Hmm, yeah, it seems to think it is using a locally installed GHC, but the stack installed one is most immediately present on PATH

Does your PATH var contain that dir?

[sjakobi]

This is just bad wording: See Stack.SetupCmd and Stack.Setup.ensureCompiler.

Would something like this be clearer?

stack will use a sandboxed GHC that is separate from any local system installations

[varosi]

Yes, this is much more clear.

[varosi]

@mgsloan, nope, my PATH doesn't contain this directory.

[sjakobi]

stack will use a sandboxed GHC that is separate from any local system installations

Let's be cautious about the wording here. I'm worried that this message might be interpreted differently than what we intend and that the wrong impression might stick.

For example "separate from any local system installations" might be interpreted as "this ghc doesn't use system-installed libraries", which is wrong…

[Blaisorblade]

What about simply "stack will use a sandboxed GHC it installed"? The important bit is that stack installed this GHC, not the user, right?

[varosi]

@Blaisorblade, sounds good!

[CraigStuntz]

"stack will use a sandboxed GHC it installed" is a grammatical error. Should be "stack will use a sandboxed GHC if installed" ("it" -> "if")

[Blaisorblade]

It doesn't mean "if" (there's no if, this message does imply that a GHC was installed) but "it", and I'm not sure what's the error. It means "a sandboxed GHC that it [stack] installed". I'm not sure about "a GHC that", but is it an error?

Even if correct, if the message still sounds misleading it can be changed.

[CraigStuntz]

OK, I misunderstood the intent of the message (which is, of course, the point of this issue!). I agree it's not wrong, but the issue can't really be considered resolved.

Maybe we should ask, "What does the user really want to see when she types stack setup?" If I type it today, I get four lines of text that I personally find mostly not relevant to what I'm doing.

A similar example is homebrew. If I type brew update one of two things happen: Either homebrew will inform me that my packages index is out of date and show me what it updates or it will simply say, "Already up to date."

With stack, when I type stack setup, there are only two things I expect to happen. The most common is "nothing." In this case, an appropriate message might be, "Ready to build with stack sandboxed GHC" or "Ready to build with the GHCJS on your PATH" or something. Ideally it would also show the version, saving me the trouble of maybe typing stack ghc -- --version.

Alternately, if my system is not ready and stack needs to install a GHC it could tell me that: "Installing sandboxed GHC 7.10.3..." and then the message above when complete.

The remaining lines regarding path and the other subcommands just confuse me. Why do I need to see those every time I run setup?

I'm really interested in other people's opinions on this, though, since it's a matter of interpretation as well as some people might have a different use case.

[Blaisorblade]

@CraigStuntz Good point. I'm reopening, but don't have time to craft a good message. Can you take the lead on this?

The remaining lines regarding path and the other subcommands just confuse me. Why do I need to see those every time I run setup?

I think stack setup is trying to tell you how to find and run GHC. I suspect printing the path might mislead people into hardcoding it or adding it to their PATH, instead of using those commands, and saying nothing might leave some wondering "how do I use GHC" if you're getting started (which is a good moment to run stack setup)?

If I run stack setup the n-th time... I just remember to ignore most of the message. If you actually read it... it might be annoying. Maybe you want Stack to stop saying that? With a setting? Automatically somehow?

I suspect this is low-priority, but I don't think people would oppose it as long as it's low impact. But elsewhere we have no mechanism for "warn for this the first time".

[CraigStuntz]

I guess it would make sense to generally look at stack messages and review them for helpfulness and consistency as a whole. Looking at the code it seems the messages are distributed throughout (as opposed to, say, a localizable table), so it will take some time to assemble this. I can't promise any deadline, but I'll gather info as time permits. As you say, it's not a show stopper.

[CraigStuntz]

I've started collecting stack messages in this document and will grow it as I work. My first thought is that --verbose and --quiet should be options for nearly all subcommands, with the default being "just enough information to determine what stack just did."

[mgsloan]

That's a great idea! While looking at and improving messages, it would also be helpful to switch them to using pretty printing / colorization - #2650 . Some of this work has been done, but there's still quite a lot of stuff that isn't pretty printed.

[Blaisorblade]

I guess it would make sense to generally look at stack messages and review them for helpfulness and consistency as a whole.

Agreed. To the extent it's possible, you might want to tackle issues you find incrementally, both to get feedback and motivation, and to make progress. Or at least, file sub-issues for those.

My first thought is that --verbose and --quiet should be options for nearly all subcommands, with the default being "just enough information to determine what stack just did."

But we do have those options (ahem, we have --silent instead of --quiet), though I'm not sure they have ideal semantics. However, global options are not listed among command options, and that often confuses me: if I'm looking for an option, I often don't know if Stack considers it global or per-command (either because I'm not an expert on that feature, or because multiple answers are reasonable).

$ stack --help
stack - The Haskell Tool Stack

Usage: stack [--help] [--version] [--numeric-version] [--hpack-numeric-version]
             [--docker*] [--nix*] ([--verbosity VERBOSITY] | [-v|--verbose] |
             [--silent]) [--[no-]time-in-log] [--stack-root STACK-ROOT]
             [--work-dir WORK-DIR] [--[no-]system-ghc] [--[no-]install-ghc]
             [--arch ARCH] [--ghc-variant VARIANT] [--ghc-build BUILD]
             [-j|--jobs JOBS] [--extra-include-dirs DIR] [--extra-lib-dirs DIR]
             [--with-gcc PATH-TO-GCC] [--[no-]skip-ghc-check] [--[no-]skip-msys]
             [--local-bin-path DIR] [--[no-]modify-code-page]
             [--[no-]allow-different-user] [--[no-]dump-logs]
             [--resolver RESOLVER] [--compiler COMPILER] [--[no-]terminal]
             [--color WHEN] [--stack-yaml STACK-YAML] COMMAND|FILE

Available options:
  --help                   Show this help text
  --version                Show version
  --numeric-version        Show only version number
  --hpack-numeric-version  Show only hpack's version number
  --docker*                Run 'stack --docker-help' for details
  --nix*                   Run 'stack --nix-help' for details
  --verbosity VERBOSITY    Verbosity: silent, error, warn, info, debug
  -v,--verbose             Enable verbose mode: verbosity level "debug"
  --silent                 Enable silent mode: verbosity level "silent"

[ghost]

root@debian:/home/jacob/NemoChain# stack uninstall ghc-cabel
stack does not manage installations in global locations
The only global mutation stack performs is executable copying
For the default executable destination, please run 'stack path --local-bin-path'
root@debian:/home/jacob/NemoChain# stack uninstall ghc-cabel

Thanks bra............

[mgsloan]

@Gr1dd I have deleted one of your comments, please be constructive. Understand that there are technical issues here that make this nontrivial.

Also, you mispelled ghc-cabal, so that wouldn't have done anything even if the command worked. You probably want stack exec -- ghc-pkg unregister ghc-cabal. This does not delete the data, but will cause it to be reinstalled.