`stack ghci` does not recognise internal libraries

[dbaynard]

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 looks like it is relevant:

stack/src/Stack/Ghci.hs

Line 592 in d1c40ae

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

[dbaynard]

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

stack/src/Stack/Types/NamedComponent.hs

Lines 22 to 34 in 979e613

	-- | 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]

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

[mihaimaruseac]

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]

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

[mihaimaruseac]

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

[KaneTW]

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]

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]

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]

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

[mihaimaruseac]

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.