Skip to content
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

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

Open
erantapaa opened this issue Dec 14, 2017 · 15 comments

Comments

Projects
None yet
5 participants
@erantapaa
Copy link

commented Dec 14, 2017

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

This comment has been minimized.

Copy link
Collaborator

commented Dec 14, 2017

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

This comment has been minimized.

Copy link

commented Feb 3, 2018

@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

This comment has been minimized.

Copy link
Collaborator

commented Feb 10, 2018

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

@raxod502

This comment has been minimized.

Copy link

commented Feb 10, 2018

@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

This comment has been minimized.

Copy link
Collaborator

commented Feb 10, 2018

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

This comment has been minimized.

Copy link

commented Feb 11, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Feb 11, 2018

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

2018-02-11_1413x276_scrot

mgsloan added a commit that referenced this issue Feb 11, 2018

@raxod502

This comment has been minimized.

Copy link

commented Feb 12, 2018

This is fantastic! Much clearer, thanks so much.

@chris-martin

This comment has been minimized.

Copy link
Contributor

commented Feb 24, 2018

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

This comment has been minimized.

Copy link

commented Feb 25, 2018

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

@mgsloan

This comment has been minimized.

Copy link
Collaborator

commented Feb 25, 2018

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

This comment has been minimized.

Copy link

commented Mar 7, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Mar 8, 2018

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

This comment has been minimized.

Copy link

commented Jun 30, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Jan 20, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.