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 · 12 comments

Comments

Projects
None yet
4 participants
@dbaynard
Contributor

dbaynard commented Mar 15, 2018

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

This comment has been minimized.

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

mihaimaruseac commented Apr 15, 2018

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

@mihaimaruseac

This comment has been minimized.

Contributor

mihaimaruseac commented Apr 17, 2018

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

This comment has been minimized.

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

This comment has been minimized.

Contributor

mihaimaruseac commented Apr 22, 2018

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

@KaneTW

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

KaneTW commented Apr 23, 2018

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

@mihaimaruseac

This comment has been minimized.

Contributor

mihaimaruseac commented Apr 23, 2018

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 mihaimaruseac referenced this issue Apr 23, 2018

Merged

Handle internal libraries in GHCi. #3982

2 of 2 tasks complete
@mihaimaruseac

This comment has been minimized.

Contributor

mihaimaruseac commented Jun 21, 2018

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

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