Internal library component not available for REPL
rikvdkleij opened this issue · comments
Cabal 2 support internal libraries and as I understand Stack version 1.9.3 also.
I expect that that stack ide targets gives all components but the internal libraries are not mentioned.
Also stack repl [name of lib] does not work.
Steps to reproduce
Create cabal file packagename.cabal which contains components:
library
library libname
Expected
To work:
stack repl packagename:lib:libname
REPL is started.
Actual
What actually happened.
Error parsing targets: Directory not found: packagename:lib:libname
Also when I start a REPL with a component which depends on the internal library, the internal modules can not be loaded.
Stack version
1.9.3
@mihaimaruseac Would you take a look, please?
@rikvdkleij Thanks for the report. Would you please indicate which platform you are on, paste the output of stack --version, and also paste the verbose logs corresponding to the error messages (you can wrap the log in <details></details> tags)?
Platform is macOS.
stack --version
Version 1.9.3, Git revision 40cf7b37526b86d1676da82167ea8758a854953b (6211 commits) x86_64 hpack-0.31.1
What do you mean with the details tags? I can can run the command with the --verbose flag and then?
See also #4148, unfortunately until March I don't really have time to look into this due to personal reasons. Hopefully after March I can get back to making internal libraries work as they should everywhere in Stack.
@rikvdkleij, you can copy the output of --verbose and paste it in a comment here, between
<details> ` ` `
and
` ` `</details>
(just make sure you remove the spaces between the ` characters). The output would look like
@mihaimaruseac Thanks for your reply! Great that you will solve this issue! Currently this is a blocker to use internal libraries. Also for IDE support.
Verbose log in which did some renaming:
Version 1.9.3, Git revision 40cf7b37526b86d1676da82167ea8758a854953b (6211 commits) x86_64 hpack-0.31.1
2019-02-05 15:23:05.618589: [debug] Checking for project config at: rik/app/stack.yaml
2019-02-05 15:23:05.618954: [debug] Loading project config file stack.yaml
2019-02-05 15:23:05.620342: [debug] Decoding build plan from: /Users/rik/.stack/build-plan/lts-12.26.yaml
2019-02-05 15:23:05.620396: [debug] Trying to decode /Users/rik/.stack/build-plan-cache/lts-12.26.cache
2019-02-05 15:23:05.622568: [debug] Success decoding /Users/rik/.stack/build-plan-cache/lts-12.26.cache
2019-02-05 15:23:05.625808: [debug] Potential GHC builds: standard
2019-02-05 15:23:05.625887: [debug] Found already installed GHC builds: standard
2019-02-05 15:23:05.626380: [debug] Getting global package database location
2019-02-05 15:23:05.626609: [debug] Getting Cabal package version
2019-02-05 15:23:05.626657: [debug] Asking GHC for its version
2019-02-05 15:23:05.626771: [debug] Run process: /Users/rik/.stack/programs/x86_64-osx/ghc-8.4.4/bin/ghc-pkg --no-user-package-db list --global
2019-02-05 15:23:05.627500: [debug] Run process: /Users/rik/.stack/programs/x86_64-osx/ghc-8.4.4/bin/ghc-pkg --no-user-package-db field --simple-output Cabal version
2019-02-05 15:23:05.628207: [debug] Run process: /Users/rik/.stack/programs/x86_64-osx/ghc-8.4.4/bin/ghc --numeric-version
2019-02-05 15:23:05.718585: [debug] Process finished in 91ms: /Users/rik/.stack/programs/x86_64-osx/ghc-8.4.4/bin/ghc-pkg --no-user-package-db field --simple-output Cabal version
2019-02-05 15:23:05.718777: [debug] Process finished in 92ms: /Users/rik/.stack/programs/x86_64-osx/ghc-8.4.4/bin/ghc-pkg --no-user-package-db list --global
2019-02-05 15:23:05.731800: [debug] Process finished in 103ms: /Users/rik/.stack/programs/x86_64-osx/ghc-8.4.4/bin/ghc --numeric-version
2019-02-05 15:23:05.731908: [debug] GHC version is: ghc-8.4.4
2019-02-05 15:23:05.731987: [debug] Resolving package entries
2019-02-05 15:23:05.732114: [debug] Trying to decode /Users/rik/.stack/loaded-snapshot-cache/x86_64-osx/ghc-8.4.4/lts-12.26.cache
2019-02-05 15:23:05.769709: [debug] Success decoding /Users/rik/.stack/loaded-snapshot-cache/x86_64-osx/ghc-8.4.4/lts-12.26.cache
2019-02-05 15:23:05.770064: [debug] Starting to execute command inside EnvConfig
2019-02-05 15:23:05.770115: [debug] Parsing the targets
2019-02-05 15:23:05.792059: [debug] Trying to decode /Users/rik/.stack/indices/Hackage/01-index.cache
2019-02-05 15:23:06.004836: [debug] Success decoding /Users/rik/.stack/indices/Hackage/01-index.cache
2019-02-05 15:23:06.026014: [debug] Start: getPackageFiles rik/tensorflow-haskell/tensorflow/tensorflow.cabal
2019-02-05 15:23:06.051028: [debug] Finished in 25ms: getPackageFiles rik/tensorflow-haskell/tensorflow/tensorflow.cabal
2019-02-05 15:23:06.052236: [debug] Start: getPackageFiles rik/tensorflow-haskell/tensorflow-core-ops/tensorflow-core-ops.cabal
2019-02-05 15:23:06.053083: [debug] Finished in 1ms: getPackageFiles rik/tensorflow-haskell/tensorflow-core-ops/tensorflow-core-ops.cabal
2019-02-05 15:23:06.053873: [debug] Start: getPackageFiles rik/tensorflow-haskell/tensorflow-logging/tensorflow-logging.cabal
2019-02-05 15:23:06.061639: [debug] Finished in 8ms: getPackageFiles rik/tensorflow-haskell/tensorflow-logging/tensorflow-logging.cabal
2019-02-05 15:23:06.062817: [debug] Start: getPackageFiles rik/tensorflow-haskell/tensorflow-mnist/tensorflow-mnist.cabal
2019-02-05 15:23:06.078738: [debug] Finished in 16ms: getPackageFiles rik/tensorflow-haskell/tensorflow-mnist/tensorflow-mnist.cabal
2019-02-05 15:23:06.080513: [debug] Start: getPackageFiles rik/tensorflow-haskell/tensorflow-mnist-input-data/tensorflow-mnist-input-data.cabal
2019-02-05 15:23:06.084524: [debug] Finished in 4ms: getPackageFiles rik/tensorflow-haskell/tensorflow-mnist-input-data/tensorflow-mnist-input-data.cabal
2019-02-05 15:23:06.085547: [debug] Start: getPackageFiles rik/tensorflow-haskell/tensorflow-opgen/tensorflow-opgen.cabal
2019-02-05 15:23:06.089598: [debug] Finished in 4ms: getPackageFiles rik/tensorflow-haskell/tensorflow-opgen/tensorflow-opgen.cabal
2019-02-05 15:23:06.090695: [debug] Start: getPackageFiles rik/tensorflow-haskell/tensorflow-ops/tensorflow-ops.cabal
2019-02-05 15:23:06.197660: [debug] Finished in 107ms: getPackageFiles rik/tensorflow-haskell/tensorflow-ops/tensorflow-ops.cabal
2019-02-05 15:23:06.198739: [debug] Start: getPackageFiles rik/tensorflow-haskell/tensorflow-proto/tensorflow-proto.cabal
2019-02-05 15:23:06.251441: [debug] Finished in 53ms: getPackageFiles rik/tensorflow-haskell/tensorflow-proto/tensorflow-proto.cabal
2019-02-05 15:23:06.254476: [debug] Start: getPackageFiles rik/tensorflow-haskell/tensorflow-records/tensorflow-records.cabal
2019-02-05 15:23:06.258472: [debug] Finished in 4ms: getPackageFiles rik/tensorflow-haskell/tensorflow-records/tensorflow-records.cabal
2019-02-05 15:23:06.259349: [debug] Start: getPackageFiles rik/tensorflow-haskell/tensorflow-records-conduit/tensorflow-records-conduit.cabal
2019-02-05 15:23:06.261253: [debug] Finished in 2ms: getPackageFiles rik/tensorflow-haskell/tensorflow-records-conduit/tensorflow-records-conduit.cabal
2019-02-05 15:23:06.262226: [debug] Start: getPackageFiles rik/app/app.cabal
2019-02-05 15:23:06.276925: [debug] Finished in 15ms: getPackageFiles rik/app/app.cabal
2019-02-05 15:23:06.281968: [debug] Parsing the targets
Error parsing targets: Directory not found: app:lib:detection
Note that to specify options to be passed to GHCi, use the --ghci-options flag
@mihaimaruseac Later on I added spaces between the ` but did not see a difference in output Also noticed that you have changed the content.
I tried to get the formatting fixed but failed. It's ok though, the log is readable. Thank you for it
You need a blank line between the html tags and the backticks 👍.
Do the other commands work, e.g. build?
Yes, stack build works.
And to be clear, this is different to #4148 (i.e. it still doesn't work after running stack build)?
Yes, that's right. Even after a build it does not work.
Also when I do stack repl without mentioning a component and select a component which depends on an internal library, it takes the language extensions from other components in scope (defined in cabal file).
I think #4148 is no longer valid, the last comment there says that ghci after build no longer works (so probably we had a regression there, though since internal libraries support needs to be redone I don't think we should bother bisecting and reverting)
Also when I do
stack replwithout mentioning a component and select a component which depends on an internal library, it takes the language extensions from other components in scope (defined in cabal file).
Can you open another issue for that, please? And assign to me too, I'll take care of it too next month (or earlier if I get time)
Can you open another issue for that, please? And assign to me too, I'll take care of it too next month (or earlier if I get time)
Isn't this the same issue only it appears differently?
I also am facing this issue. Is there any workaround that could be used while the issue is not fixed? See my details below:
OS - Ubuntu 18.04, stack --version:
Version 2.1.1, Git revision f612ea85316bbc327a64e4ad8d9f0b150dc12d4b (7648 commits) x86_64 hpack-0.31.2
Even after stack build runs successfully, this happens. Also, I have the letter z inserted into the package names, similar to #4148
This issue affects me a lot, as my readers are not able to use stack for exploring the code in the hid-examples package which contains many executables and internal libraries.
It may not be the same problem, but also in my environment launching stack repl and stack ghci failed in a project that includes an internal library.
The same error occurred when used stack version 1.9.3 and 2.1.1.
The error is below.
[debug] Run process: /opt/ghc/8.6.4/bin/ghc --interactive -i -odir=/home/user/workspace/haskell/experiment1/.stack-work/odir -hidir=/home/user/workspace/haskell/experiment1/.stack-work/odir -hide-all-packages -i/home/user/workspace/haskell/experiment1/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build -i/home/user/workspace/haskell/experiment1/src -i/home/user/workspace/haskell/experiment1/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/autogen -i/home/user/workspace/haskell/experiment1/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/global-autogen -stubdir=/home/user/workspace/haskell/experiment1/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build -package=z-experiment1-z-experiment1-lib -package-id=base-4.12.0.0 -i/home/user/workspace/haskell/experiment1/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/experiment1-lib -i/home/user/workspace/haskell/experiment1/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/experiment1-lib/autogen -i/home/user/workspace/haskell/experiment1/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/experiment1-lib/experiment1-lib-tmp -i/home/user/workspace/haskell/experiment1/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/experiment1-exe -i/home/user/workspace/haskell/experiment1/app -i/home/user/workspace/haskell/experiment1/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/experiment1-exe/autogen -i/home/user/workspace/haskell/experiment1/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/experiment1-exe/experiment1-exe-tmp -rtsopts -with-rtsopts=-N -optP-include -optP/home/user/workspace/haskell/experiment1/.stack-work/ghci/6c66921b/cabal_macros.h -ghci-script=/tmp/haskell-stack-ghci/83e92d34/ghci-script
GHCi, version 8.6.4: http://www.haskell.org/ghc/ :? for help
<command line>: cannot satisfy -package z-experiment1-z-experiment1-lib
(use -v for more information)
I do not know how it works, but with the option of --no-package-hiding I was able to start ghci.
The error message I got was almost the same as yours @tkaaad97. The --no-package-hiding option also solved it for me, so thanks for that suggestion. Would be good to know why that fixed it
Hi, I have this issue:
$ stack ghci foo:bar
<command line>: cannot satisfy -package z-foo-z-foo-lib
(use -v for more information)
I also have the letter "z" appended.
If I run with --no-package-hiding:
$ stack ghci foo:bar --no-package-hiding
<no location info>: error:
module ‘main:Main’ is defined in multiple files: /home/me/foo/bar/Main.hs
/home/me/foo/bar/Main.hs
GHCi complains that there is two Main.hs (twice the same). My version of stack is 2.1.3.
Hi! I think we are running into the same problem in mpickering/haskell-ide-engine#87.
I'm able to get this running, though I haven't figured out what's going on.
stack --verbose ghci(or equivalent)- Copy ghci command (
stack exec -- ghc-* --interactive) - Remove the entries between the language extensions and the start of the package ids corresponding to any submodules, and replace with
-package-id=<identifier>, where the identifier comes fromls $(stack path --local-install-root)/lib/*/ | grep '^<package>' - Remove any
-package=z-*-z-*lines. - Use the resulting command to load the repl. The output of step 3 is relatively stable.
Given the mandatory lockdown we have here due to the coronavirus I think i can finally get to this.
@mihaimaruseac Thanks a lot for digging into this. I'm running into the #4148 regression (stack repl only works after a successful stack build).
I managed to dedicate a few hours to get to the root cause. Hopefully I'll get a few more hours soon and solve
Hi, a bit of a newbie when it comes to stack internals but I'm wondering if there's anything I can do to help with resolving this?
Failing that does anyone have a sneaky workaround for hie? My hie install stopped working when I switched to a newer snapshot so I tried to upgrade hie and got a nasty surprise. I'm not especially keen to split my internal libraries up into separate packages. I tried building stack with the latest hpack which has support for public internal libraries with cabal 3.0 but seem to be getting the same issue.
@edwardb96 recently I added a minor fix for REPL which could be related - #5306
I'm not sure it will play well with components but maybe it improves the situation, testing out master version and giving a repro could help (though I'm not sure that I myself will have much time to dig into this)
BTW I think this is a duplicate of #2790
So after playing around with some minimal (non) working examples I have established the following two things about both
Version 2.3.1, Git revision de2a7b694f07de7e6cf17f8c92338c16286b2878 (8103 commits) x86_64 hpack-0.33.0
and recent stack from master which includes #5306 and a bumped version of hpack Version 2.4.0, Git revision b5d30906ebee25df1f2532255e245d329083b623 (dirty) (8168 commits) PRE-RELEASE x86_64 hpack-0.34.2.
When running stack repl without first completing a successful stack build in a project using internal-libraries you get an error message of the form below. This is as described in #2790 and for the moment is avoided by completing stack build before stack repl.
<command line>: cannot satisfy -package z-stack-internal-libs-z-alib
(use -v for more information)
b) Further to this however, if the package.yaml includes an executable target(s), and an internal-library but no root library: component then this error does not go away after completing a successful stack build.
I attach zipped project which can (hopefully) be used to reproduce this.
I assume this is a bug in stack and that a root library: should not be required? If this were not the case then I would expect stack build to have failed or at least to get a clearer error message from stack repl.
The good news is that in the short term an easy fix to b) is to simply add a root library component with an empty module.
I had another look into this and it appears that it's another example of a problem appearing because we don't have yet component-based builds (i.e. #4745) implemented. Currently Stack only has some special handling for "ordinary" components, i.e. executables, benchmarks and tests and internal libraries are handled as an extra step of building a package library. And as I've said in #5342 I don't think I myself can find enough time to implement that ticket.
Any updates on this? It would be a great feature to have.
It seems last stack version does not have a fix for this. Let me know if we can help in some way to make progress.
I'm making slow but steady progresses, I havn't looked at the GHCi related stuff yet. I have a component based builds branch (comp/package-refactoring) but it doesn't pass all the tests yet.
We got another issue about this in hls. I am afraid users are avoiding internal libraries to get projects work in the ide.
We've had to just rip out a number of internal libraries in order to be able to get haskell-language-server to work. Took us a longwhile to understand why the production builds were working but a developer couldn't get anywhere locally with their IDE. I'm not hugely fussed about "internal libraries" so we're getting rid of them, but it was a head scratcher, that's for sure.
Any updates on this?
Seeking to consolidate open issues, I am going to close this issue: in respect of stack ghci/repl and internal sublibraries, there is #4148 (only works after stack build); and in respect of Stack's support for public sublibraries, there is #5256 (public sublibraries) and #4745 (component-based builds).