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

stack ghci usability #1517

Closed
alexanderkjeldaas opened this issue Dec 15, 2015 · 2 comments
Closed

stack ghci usability #1517

alexanderkjeldaas opened this issue Dec 15, 2015 · 2 comments

Comments

@alexanderkjeldaas
Copy link
Contributor

stack ghci should not leave a user with no "next step" when trying to invoke ghci when the build is broken.

In this example, stack refuses to start ghci because it cannot satisfy -package new-template. That might not be the most important aspect of starting ghci for the user, and there seems to be no way out of this, at least not as documented in --help.

$ stack ghci
Configuring GHCi with the following packages: new-template
GHCi, version 7.10.2: http://www.haskell.org/ghc/  :? for help
<command line>: cannot satisfy -package new-template
    (use -v for more information)
$ stack ghci --help
Usage: stack ghci [TARGET] [--ghc-options OPTION] [--with-ghc GHC] [--no-load]
  Run ghci in the context of project(s)

Available options:
  TARGET                   If none specified, use all packages defined in
                           current directory
  --ghc-options OPTION     Additional options passed to GHCi
  --with-ghc GHC           Use this command for the GHC to run
  --no-load                Don't load modules on start-up
$ stack ghci --no-load
Configuring GHCi with the following packages: new-template
GHCi, version 7.10.2: http://www.haskell.org/ghc/  :? for help
<command line>: cannot satisfy -package new-template
    (use -v for more information)
$ ghci
GHCi, version 7.10.1: http://www.haskell.org/ghc/  :? for help
Prelude>
@mgsloan
Copy link
Contributor

mgsloan commented Dec 16, 2015

We can't easily do anything about this, because when we invoke ghci, we pass over control of stdout and stderr. So, we have no idea if ghci initialized successfully. Moreover, when it fails, we have no way to know what the message is. Even if we did intercept stdout / stderr, we wouldn't know if the ghci process is failing immediately or due to some user interaction.

It also doesn't make much sense to allow ghci to attempt to load code if a -package is unsatisfiable. In this case, either the code won't load due to missing imports, or that package isn't necessary and should be removed from your cabal file.

How are you getting this error? Do you have a recent version of stack? stack ghci on the new template works fine. Maybe you want stack exec ghci, which runs ghci in the environment without setting any flags, controlling the package environment, or loading code.

I could imagine adding a --no-package-hiding, or some similar flag. This would omit the -package flags, which might help here. It would also be useful for the circumstance where you want to import modules that aren't dependencies of any of the targets.

@mgsloan
Copy link
Contributor

mgsloan commented Dec 16, 2015

I've gone ahead and added --no-package-hiding to stack ghci, since it's something I've wanted in the past, for other reasons.

Feel free to reopen if this explanation / flag addition doesn't resolve the issue.

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

No branches or pull requests

2 participants