Show resolver being used when stack ghci is invoked outside of a project directory

[erantapaa]

When I run stack ghci outside of a project directory I get output like:

bash$ stack ghci
everything-0.0.1: initial-build-steps (lib)
Configuring GHCi with the following packages: everything
GHCi, version 8.0.2: http://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /Users/erantapaa/.ghc/ghci.conf
Loaded GHCi configuration from /private/var/folders/.../ghci-script
Prelude>

It would be very helpful to display the resolver being used in this scenario.

[mgsloan]

Makes sense! It should also probably say something like "Using global project ..." which would at least make it clear where it was getting the config.

If you update to 1.6.1 and have a normal global project, you'll at least get:

mgsloan@computer:~$ stack ghci

Warning: No local targets specified, so ghci will not use any options from your package.yaml / *.cabal files.
         
         Potential ways to resolve this:
         * If you want to use the package.yaml / *.cabal package in the current directory, use stack init to create a new stack.yaml.
         * Add to the 'packages' field of /home/mgsloan/.stack/global-project/stack.yaml

[raxod502]

@mgsloan I am getting the warning you quoted above. How do I get rid of it? I don't want to use a package.yaml or *.cabal file from the current directory, and I don't understand what I should add to the 'packages' field in the global stack.yaml. All I want is a GHCI REPL (and the one I get works fine, just with this warning).

[mgsloan]

@raxod502 Hmm, why does getting the warning matter? Perhaps I should turn it into an Info:?

[raxod502]

@mgsloan If I get a warning, then it means I need to fix something. If there's nothing wrong, then what is there to "warn" about?

But perhaps using stack ghci outside the context of a project is not a supported use case?

[mgsloan]

I guess it's a difference of semantics. A warning does not mean there is something you need to fix - an error does. For example, an identifier aliasing or unused identifier warning from GHC does not mean there is something that needs to be fixed. It just so happens that most GHC warnings are resolvable while retaining semantics. In this case there is no direct way to make the warning go away.

I would be fine with making it an "Note: " instead of "Warning: ", I can understand how this would be confusing.

[raxod502]

The primary reason the message was confusing to me was that it says ghci will not use any options from your package.yaml / *.cabal files but I don't have any such files. Maybe only print it if there are such files? As a naive user who only wants a REPL, I have no idea why package.yaml / *.cabal files would be relevant.

[mgsloan]

I see, thanks for the feedback about clarity. I've updated the message:

[raxod502]

This is fantastic! Much clearer, thanks so much.

[chris-martin]

Yes, thank you! It's a bit embarrassing when I'm trying to show off a fancy tool and it's printing warnings while nothing is wrong, it makes the experience look unpolished.

[raxod502]

By the way, is there any command-line option or other configuration change that would prevent the message from being printed at all?

[mgsloan]

There isn't a good way to silence these hints / warnings without also silencing other things. Could be added, but not sure what to call it. You could do --verbosity error, but that wouldn't display anything but errors. --verbosity silent would have even less output, probably only showing ghci.

[raxod502]

Now that I have some more experience with Haskell, I think that what I should have been doing was

$ stack exec -- ghci

rather than

$ stack ghci

because all I wanted was a plain GHCI in the global project. It's not entirely clear to me what the difference between the two commands is, but I can understand if one produces a warning when used in this way, if indeed I should have been using a different command in the first place. Perhaps this information could be added to the hint, unless I'm totally off the mark here.

[mgsloan]

If your global project has no packages (and it probably shouldn't), then stack exec -- ghci is very similar to stack ghci. If you want to avoid this notice, then sure, use stack exec -- ghci.

If I run stack ghci -v then there is a log line like this:

 Run process: /home/mgsloan/.stack/programs/x86_64-linux/ghc-8.2.2/bin/ghc --interactive -odir=/home/mgsloan/.stack/global-project/.stack-work/odir -hidir=/home/mgsloan/.stack/global-project/.stack-work/odir -ghci-script=/tmp/haskell-stack-ghci/2a3bbd58/ghci-script

I don't think the -odir / -hidir settings matter much for this use, and the ghci-script file just contains

:module +

Which doesn't do anything. So yeah, they're very similar.

[EdmundsEcho]

Is there a way to fire up ghci within a project in a way that provides it access to the global imports? Re-installing packages (e.g., hscolour) for each project that are only used to debut using ghci seems less than ideal. Otherwise, any quick explanation as to why this is not possible will help. Thank you in advance.

[mgsloan]

@EdmundsEcho There's sharing for packages that are included in the stackage snapshot, so you should only need to build hscolour once per ghc version. So, after building once stack build hscolour should either add it to the appropriate package DB or do nothing if it's already there.

Perhaps that could be streamlined by eagerly populating the package DBs with everything that's precompiled, but it doesn't seem worth it. Every build of a snapshot package would need to check every snapshot DB to see if the package can also be added to it.. Would slow things down quite a bit for a fairly unusual usecase.

[mpilgrem]

I am going to close this issue as, with Stack 2.15.5, the snapshot is reported.