New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
varosi opened this Issue Jun 30, 2016 · 21 comments

Comments

Projects
None yet
7 participants
@varosi

varosi commented Jun 30, 2016

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

This comment has been minimized.

Collaborator

mgsloan commented Jul 19, 2016

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

Will re-open upon further details.

@varosi

This comment has been minimized.

varosi commented Jul 20, 2016

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

This comment has been minimized.

varosi commented Jul 20, 2016

I couldn't not reopen it.

@sjakobi sjakobi reopened this Jul 20, 2016

@sjakobi

This comment has been minimized.

Contributor

sjakobi commented Jul 20, 2016

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

This comment has been minimized.

Collaborator

mgsloan commented Jul 21, 2016

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 comment has been minimized.

Contributor

sjakobi commented Jul 21, 2016

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

This comment has been minimized.

varosi commented Jul 21, 2016

Yes, this is much more clear.

@varosi

This comment has been minimized.

varosi commented Jul 21, 2016

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

@sjakobi

This comment has been minimized.

Contributor

sjakobi commented Jul 21, 2016

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

This comment has been minimized.

Collaborator

Blaisorblade commented Aug 3, 2016

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

@Blaisorblade Blaisorblade changed the title from "stack setup" give me that it'll use locally installed GHC which is not present at all to "stack setup" output mentions "locally installed GHC" which is terribly confusing Aug 3, 2016

@varosi

This comment has been minimized.

varosi commented Aug 3, 2016

@Blaisorblade, sounds good!

Blaisorblade added a commit that referenced this issue Aug 4, 2016

setup output: "locally installed" -> "sandboxed"
Fix #2314: Clarify output from stack setup, since it confused both a
user and stack developers for a while in that issue.

Also update references in other code and in the guide.

@borsboom borsboom added the in progress label Aug 4, 2016

@Blaisorblade Blaisorblade modified the milestones: P2: Should, Support Aug 4, 2016

@borsboom borsboom removed the in progress label Aug 4, 2016

@snoyberg snoyberg removed the in progress label Aug 4, 2016

@CraigStuntz

This comment has been minimized.

CraigStuntz commented Oct 19, 2017

"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

This comment has been minimized.

Collaborator

Blaisorblade commented Oct 19, 2017

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

This comment has been minimized.

CraigStuntz commented Oct 19, 2017

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 Blaisorblade removed their assignment Oct 19, 2017

@Blaisorblade

This comment has been minimized.

Collaborator

Blaisorblade commented Oct 19, 2017

@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".

@Blaisorblade Blaisorblade reopened this Oct 19, 2017

@CraigStuntz

This comment has been minimized.

CraigStuntz commented Oct 20, 2017

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

This comment has been minimized.

CraigStuntz commented Oct 20, 2017

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

This comment has been minimized.

Collaborator

mgsloan commented Oct 20, 2017

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

This comment has been minimized.

Collaborator

Blaisorblade commented Oct 22, 2017

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

This comment has been minimized.

ghost commented Nov 25, 2017

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............

@commercialhaskell commercialhaskell deleted a comment Nov 25, 2017

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Nov 25, 2017

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment