Unable to build with backpack modules from unpacked-containers package #6835
Comments
|
This has stalled my work, I would like to know if there is a workaround, how can I use unpacked-containers in my project? |
|
I agree this looks pretty similar to #6317 but given the cabal and ghc versions quoted in this ticket you should have this fix already. |
|
@harendra-kumar do you think you would have time to do a bisect for this problem? |
|
@ezyang I can try, what do you suggest? Maybe, I can try running cabal at the commit right after that fix. |
|
I built cabal at the commit in that PR and it still fails with the same error. I tried with ghc-8.6.5 as well, but no luck. The example I am building is exactly copied from the unpacked-containers package. Surprisingly, when I build unpacked-containers package itself which contains this example, it builds perfectly well. But this example which uses unpacked-containers as a dependency does not build. Based on the above, I guessed that if I add |
|
Yeah, sounds like I didn't manage to completely nail it in that PR then. Please use this workaround for now, I'll take a look this weekend. |
|
@harendra-kumar: thank you again for reporting this; just in case: does the bug persist? [edit: and with which cabal version?] |
|
I've encountered the same problem with my moo-nad package. To reproduce: The code that emits the error is in
So it seems that the graph is made of already compiled and installed external packages (from the store?) or In my case, the "keys" in the graph, along with their dependencies, are: In particular, the "fully instantiated" Also, in the full entry for
So it seems the bug happens earlier. Perhaps the graph should have an entry for |
|
@danidiaz: thank you for the report. I see GHC is 9.0. Is cabal 3.4? Do you get the same error with current master branch of cabal? Could anybody reproduce, please? |
|
I'm using GHC 9.0.1 and cabal 3.4. I'm having trouble compiling the current |
|
Thank you for the details. Master branch should compile fine, so feel free to open an issue if it doesn't. Or if I can help otherwise, please elaborate here. |
|
@Mikolaj the original example I gave above is pretty simple and quick to reproduce. I tried it again with cabal built from the master branch but it failed with the same message. |
|
@harendra-kumar: thank you very much for reproducing (again). This seems serious to me. It may be a trivial problem only triggered by contrived examples or a jarring hole that's just waiting for favourable conditions to break many packages at once. I couldn't find any related open issues, so we only have the two examples here to run with. |
|
The problem seems to happen when
When both the indefinite component and the implementation are local, the problem doesn't seem to happen. I have inspected the execution of the function The function receives as parameter a |
|
My config flags for the "happy" scenario (both the indefinite component and the implementation library are local) are: and for the buggy one are: In particular, the It includes the local package db. But the same field in the buggy scenario doesn't include the local pacakge db: I made the experiment of hardwiring my project's local package db in the cabal code. The good news is that it compiled! The bad news is that the compilation outputs were put in the Cabal store, instead of the project's local package db, corrupting the Cabal store in the process (to repair the store, it was enough to delete the created folders). So my hypothesis is that, when a external indefinite package is instantiated with a local library, it's mistakenly assumed to have purely "external" ingredients. And because of that, Cabal doesn't bother including the package database of the local project, and also wants to put the compilation products in the wrong place. They should be put in the project's local package db. |
|
Going upwards in the call chain, it seems as if the The command-line arguments received in the "happy" scenario are: The command-line arguments received in the buggy scenario are: The |
|
So it seems that cabal-install generates a nice |
|
Indeed, Perhaps it would make sense to add it, e.g., wherever 'build plan' appears in docs: Regarding |
|
Judging from comments in the code, an "improved" plan is one for which package references have info about the actual locations in the store:
I don't think plan.json is faulty, it's just that it doesn't show everything I need. I (hackishly) tweaked the Then I searched in the generated For my buggy case, I have: So it seems that the package db stacks are set up incorrectly, there's no local package database. The instantiation with For my happy case, I have: |
|
The function
For example, in my case the verbose log output shows the lines: If we move the logging statement to before the call to The problem seems to be that |
|
Thanks for this work, @danidiaz, I think I agree with your diagnosis of the situation. Need to adjust instantiateInstallPlan to turn instantiated packages into local ones if any of the packages it is instantiated with is local. Might require some surgery at the code here though... |
|
Here is a crappy patch which makes moo-nad-x successfully compile. However, it does so by ALWAYS putting instantiated packages in the inplace store. |
|
I have a substantially working patch but it is somewhat involved, will submit soon. |
Fixes the bug by accurately tracking when instantiations refer to inplace packages, and adjusting previously non-inplace packages to be inplace when this occurs. See comment in ProjectPlanning.hs for more details. Signed-off-by: Edward Z. Yang <[email protected]>
|
@ezyang Thanks! If you don't mind, I have a few questions about the fields
|
As a reminder, here are the types of the two fields in question: Module are modules that are fully instantiated and thus opaque, whereas OpenModules maintain the inner structure of instantiations and so you can substitute over them when you instantiate them. So, the data flow here, is elabLinkedInstantiatedWith is initially populated after mix-in linking (e.g., we've resolved a plain old As an example, suppose you have a unit Note that, somewhat confusingly, elabLinkedInstantiatedWith isn't really used in any really serious way; it's only nontrivial use is This is because the instantiation of a unit can be inferred from its contextual use, as any reference to a unit is obligated to list all the things it depends on. In other words, pay attention to compLinkedLibDependencies, that's the important field from mixin linking!
Yes, they have to be. There is only one place elabLinkedInstantiatedWith is filled and But remember what I said above, which is that we aren't really using the structure of elabLinkedInstantiatedWith in a nontrivial way.
Yes. |
Fix #6835 (instantiating a Hackage indefinite package with an inplace package doesn't work)
|
I am able to compile my example successfully. Thanks everyone! |
Fixes the bug by accurately tracking when instantiations refer to inplace packages, and adjusting previously non-inplace packages to be inplace when this occurs. See comment in ProjectPlanning.hs for more details. Signed-off-by: Edward Z. Yang <[email protected]> (cherry picked from commit 823e894)
Fixes the bug by accurately tracking when instantiations refer to inplace packages, and adjusting previously non-inplace packages to be inplace when this occurs. See comment in ProjectPlanning.hs for more details. Signed-off-by: Edward Z. Yang <[email protected]> (cherry picked from commit 823e894)
Describe the bug
I have the following cabal file:
And the following source files:
I can't build it and cannot figure out what is wrong. Here is the cabal build message:
To Reproduce
Steps to reproduce the behavior:
Run
cabal v2-buildwith above configuration.Expected behavior
cabal build should succeed or print a message which can clearly pinpoint what is wrong. I tried going through the docs as well, but could not figure out what is wrong here. Did many trial and errors as well, but no luck with compiling this example.
System information
The text was updated successfully, but these errors were encountered: