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 does not recognise internal libraries #3926

Closed
dbaynard opened this issue Mar 15, 2018 · 17 comments
Closed

stack ghci does not recognise internal libraries #3926

dbaynard opened this issue Mar 15, 2018 · 17 comments

Comments

@dbaynard
Copy link
Contributor

Relates to #3795 (and #3791) and also #3288.

I suspect the fix is to reproduce whatever #3288 did for the build command but for ghci.

Steps to reproduce

Easiest to check out dbaynard/issues@2530d18 (internal-libraries branch) and run stack ghci.

Alternatively, create a package which has an internal library module and attempt to import that into that package's own library or an executable (they have the same outcome).

Expected

stack ghci loads the repl.

Actual

Error message, for internal library named internal

<command-line>: cannot satisfy -package internal

Note, stack build is successful. Also, stack exec -- ghci loads correctly (though doesn't load the packages).

The full output is in the readme in the internal-libries directory at the dbaynard/issues github repo, above.

Stack version

I merged fix-ghci-autogen-path-3791 (030a442) into master (
27894ff) for the test.

$ stack --version
Version 1.7.0, Git revision 06bc6937b5c6263e7da46bb18355c338ebee92a5 \(5723 commits\) x86_64 hpack-0.27.0 

Method of installation

From git repo — see above

@gbaz
Copy link

gbaz commented Mar 25, 2018

This comment looks like it is relevant:

HasLibraries _names -> [CLib]) ++ -- FIXME. This ignores sub libraries and foreign libraries. Is that OK?

@dbaynard
Copy link
Contributor Author

dbaynard commented Apr 14, 2018

I can confirm #3795 does not fix this (still broken in current master) and further to @gbaz's comment, it appears to be a more fundamental design issue.

(Also, I never new about the permalinks to code snippets — thanks! It doesn't really afford scrolling when it overflows, though, at least in chrome, as happens here.)

-- | A single, fully resolved component of a package
data NamedComponent
= CLib
| CExe !Text
| CTest !Text
| CBench !Text
deriving (Show, Eq, Ord)
renderComponent :: NamedComponent -> Text
renderComponent CLib = "lib"
renderComponent (CExe x) = "exe:" <> x
renderComponent (CTest x) = "test:" <> x
renderComponent (CBench x) = "bench:" <> x

@mihaimaruseac
Copy link
Contributor

I think #3955 can help here but didn't test yet.

@mihaimaruseac
Copy link
Contributor

I think #3955 can help here but didn't test yet.

I tested now and still gets the same error. I'll investigate more during this week.

@KaneTW
Copy link

KaneTW commented Apr 22, 2018

I managed to get rid of the cannot load package 'internal'-style messages, but then it can't find sublibraries at all.

@mihaimaruseac
Copy link
Contributor

I'm there too, hope to get some progress today or next weekend at BayHac.

@KaneTW
Copy link

KaneTW commented Apr 22, 2018

It seems that the difference between build and ghci is that build invokes Cabal while ghci invokes GHC directly. This complicates things quite a bit.

@KaneTW
Copy link

KaneTW commented Apr 22, 2018

I've compared command lines and this is what we need to pass:

-package-id godot-haskell-0.1.0.0-inplace-generate for loading internal library generate of package godot-haskell version 0.1.0.0

I've also seen -this-unit-id godot-haskell-0.1.0.0-inplace, but this doesn't seem to affect anything.

@KaneTW
Copy link

KaneTW commented Apr 23, 2018

Ugh. So after getting stack to output that, I find out that cabal new-build generates

./dist-newstyle/packagedb/ghc-8.4.2/godot-haskell-0.1.0.0-inplace.conf
./dist-newstyle/packagedb/ghc-8.4.2/godot-haskell-0.1.0.0-inplace-generate.conf

which are required. So that doesn't work. Going to take a look what stack does with sublibs.

E: ok, good, it does something similar

./install/x86_64-linux/lts-11.2/8.2.2/lib/x86_64-linux-ghc-8.2.2/godot-haskell-0.1.0.0-GzcDyMsWNwODJYNrSYTC5u-generate

@KaneTW
Copy link

KaneTW commented Apr 23, 2018

PR that fixes this is up. I need to write some test cases, though.

@mihaimaruseac
Copy link
Contributor

You got it ahead of me, but I see I was approaching it from a different angle, making more complex changes.

I'll get my PR submitted too as it also handles rebuilding from scratch and tracks changes in sublibraries. I'm testing now the integration tests but will have something up and running in a few hours.

@mihaimaruseac
Copy link
Contributor

This was done in #3982 but I forgot to close it.

@buggymcbugfix
Copy link

I'm still running into this issue:

$ stack repl app/Main.hs
[...]
Configuring GHCi with the following packages: foo
GHCi, version 8.6.5: http://www.haskell.org/ghc/  :? for help
<command line>: cannot satisfy -package foo-0.1.0.0
    (use -v for more information)
$ stack --version
Version 2.2.0, Git revision b8f8ec203209fccb1a86b9e8705f16125845254b PRE-RELEASE x86_64 hpack-0.31.2

@buggymcbugfix
Copy link

buggymcbugfix commented Sep 16, 2019

It seems to be an instance of #4564 / #4148, actually.

@mihaimaruseac
Copy link
Contributor

You mean #4564, the issue with all the updates?

@buggymcbugfix
Copy link

Yes, my bad, just updated it.

@mihaimaruseac
Copy link
Contributor

I need to find cycles to work on that :(

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

No branches or pull requests

5 participants