Could not load module/Cannot satisfy -package error for exe/test/bench component whose main lib doesn't build or was not built
#366
Labels
build tool: stack
component: hie-bios
multi-component
Issues relating to multi-component support
status: blocked
Not actionable, because blocked by upstream/GHC etc.
type: bug
Something isn't right: doesn't work as intended, documentation is missing/outdated, etc..
Comments
|
Does it emit the same error even on your master branch? More specifically, when you provide a |
|
With the Log from VSCode Output pane: |
|
Hm... the log looks innocent... |
|
Yes. I've run Are these log lines not an indication of something awry? |
jneira
added
status: needs repro
type: bug
No, it is a spurious error: #181 |
|
I see something that is weird: We see this line very often, but it should only occur once per component. |
Yes. When there is no
With Click to expand!Without Click to expand! |
|
Without which is definitely a bug and hints that each file is put into its own component. I still don't see the debug message I am interested in... |
|
Loading only the test suite in the REPL emits the error And loading both the library and test suite outputs the error that I'm interested in (in the file |
|
That this command: What is your stack version? We should probably report this issue/regression to upstream. |
|
After removing all errors and successfully building the test once, it looks like it works fine... |
|
All the above was run using stack 2.3.1 (Git revision de2a7b694f07de7e6cf17f8c92338c16286b2878). Upgrading to 2.3.3 the output of VSCode behaves the same as with stack 2.3.1, ie. fails with the following error:
Yes. In my experience the error appears when I change something in the library, and then open a source file from the test suite (which now fails to build). Then HLS fails with this error (missing either all test dependencies or the library dependency). However, fixing all errors in the test source files, and introducing a new error in one of the tests HLS works fine. I haven't figured out the exact conditions that cause this error, but I know it happens after refactoring the library and then navigating to a file in the test suite (which now fails to build). |
|
I have reported the failure of the |
Ailrun
added
status: blocked
Where should I report this bug? Is it a bug in |
@fendor could we add a workaround to |
|
What is the work-around you propose? |
|
@fendor Yes, exactly. In other words, always add the library component as a target to So, for all targets output by |
|
What if there are several libs, other components could depend on one and/or the other, do we should load all of them? |
Afaik It does for private libs, although through a workaround, creating fake packages for private libs. In fact we dont support them, although stack can build those packages with multiple (private) libs, due a that incomplete support: #114 What i wanted to mean is you can have multiple libraries, executables and test suites (definitely supported by stack) and they dont have to depend on the main lib: you can have executables not depending on it and test suites against those executables. Is not a common project layout but they exist in the wild. Or you can have a functional test suite that depends on the executable at runtime but not on compile time (neither the main lib of course) So if we load always the main lib and it has errors, that not may affect those executables/test suites, maybe that workaround could open new issues. Not sure, only wanted to note we will have to test those scenarios specifically and maybe complete that workaround to take them in account. |
|
I agree with with @jneira, there is no simple work-around. Introducing a work-around that breaks other projects seems like a rather bad solution, imo. Another user workaround could be, to use cabal for hls, not sure how viable that is in practice. |
jneira
changed the title
Could not load module/Cannot satisfy -package error for test/bench component whose main lib doesn't build or was not builtCould not load module/Cannot satisfy -package error for exe/test/bench component whose main lib doesn't build or was not built
This was referenced Oct 10, 2021
|
Would be great to have this fixed -> right now it makes hls unusable when writing tests! Not only does it make the whole process much slower (since I have to run Is there anything I can do to help in getting this fixed? I never contributed to hls or stack yet, but with some guidance I am happy to potentially give it a try. Or would it help to write more about this on the corresponding stack issue (haskell/hie-bios#269)? |
|
@Martinsos agree in to have to restart continuously is very disturbing for a smooth experience |
|
I agree with you.
Because of this bug I’ve had to switch from Stack to Cabal. It’s the only
workaround I know of. I recommend stack2cabal and ghcup, which should offer
a relatively smooth transition (an exception is having to manually install
the right GHC version).
…On Sun, 10 Oct 2021 at 12.23, Martin Šošić ***@***.***> wrote:
Would be great to have this fixed -> right now it makes hls unusable when
writing tests! Not only does it make the whole process much slower, but I
would also expect a lot of people will not figure out that they need to run stack
build and then restart the lsp server, but will instead just give up.
Is there anything I can do to help in getting this fixed? I never
contributed to hls or stack yet, but with some guidance I am happy to
potentially give it a try. Or would it help to write more about this on the
corresponding stack issue (haskell/hie-bios#269
<haskell/hie-bios#269>)?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#366 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIFBPYJ6CNJQC75W3SAYCLUGFSRRANCNFSM4QRMBN4Q>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Thanks, for some reason I haven't thought of cabal being a solution! I will look into this, sounds like probably the best solution, especially with being announced that stack will not be adding new features. (EDIT: this statement is not really correct, check #366 (comment) below). |
This is extremely off-topic, but I can't help but ask - where was this announcement made? |
I read about that here: https://www.snoyman.com/blog/babies-oss-maintenance/ . |
Well in this case there would be two way to fix this downstream: fix commercialhaskell/stack#5380 or add support for show-build-info (tracked somewhat in haskell/hie-bios#269). I think stack maintainers wants to improve support for hls (see #2151 f.e.). We also want to support stack in hls so i hope there will be a solution with the help of everybody. |
This was referenced Jan 31, 2022
|
In a similar issue @fendor found another stack bug:
it has not known upstream stack issue |
|
I frequently run into this issue: Working on tests, changing the codebase, encountering an error, and Haskell language server just won't work and help anymore. Are there new known workarounds? Is migrating to cabal a/the solution? |
Yes. I’ve switched to Cabal as a workaround and it solves the issue. |
gregorias
added a commit
to gregorias/findata-transcoder
that referenced
this issue
Apr 6, 2023
I've used stack2cabal to generate these files, so that I can safely run my build-test loop without haskell/haskell-language-server#366.
|
Oh boy, is there any progress on this? It really disincentivizes writing tests, so I'd like to fix it to have type errors in my editor. |
|
I'm running into this issue using Cabal with GHC 9.2.7: Here the language server complains that |
|
@mixphix Hi! Your issue is related to Any way, what you usually want is a trivial cabal cradle, like this: cradle:
cabal:which is the equivalent of running |
|
Thank you, @fendor! I can confirm this fix worked. |
marmitar
added a commit
to Problemas-de-Particao-de-Strings/MCSP-Algorithms
that referenced
this issue
Aug 31, 2023
Split 'hie.yaml' into multiple files, with specific configurations for tests and benchmarks. Fix for haskell/haskell-language-server#366
marmitar
added a commit
to Problemas-de-Particao-de-Strings/MCSP-Algorithms
that referenced
this issue
Aug 31, 2023
Split 'hie.yaml' into multiple files, with specific configurations for tests and benchmarks. Fix for haskell/haskell-language-server#366
marmitar
added a commit
to Problemas-de-Particao-de-Strings/MCSP-Algorithms
that referenced
this issue
Aug 31, 2023
Split 'hie.yaml' into multiple files, with specific configurations for tests and benchmarks. Fix for haskell/haskell-language-server#366
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Overview
Oftentimes I will change code in the library component of a project, and then fix the test suite by following compiler errors. However, this doesn't work for me with HLS, as the test suite not compiling causes VSCode to report the following type of errors for imports in the test suite that are dependencies of the test suite:
Reproducing
This should be reproducible with the following steps:
test/Spec.hsResult
Test dependency module imports report an error, e.g.:
Expected
VSCode highlights the errors that GHC prints in the
stack testbuild step.Versions
haskell.haskellVSCode plugin: 1.1.0Logs
Here's the full output of the VSCode Output pane:
Click to expand!
The text was updated successfully, but these errors were encountered: