-
Notifications
You must be signed in to change notification settings - Fork 1
Missing dependencies for adjunctions #2
Comments
So something seems to have gone wrong in that the With a fresh checkout of your repository, running
Another thing that needs to be automated is special handling of The main thing to understand about what cabbage is trying to do is that it freezes the downstream package (the thing you're trying to build), then intersects that build plan with frozen build plans of every upstream package you depend on. This results in a build plan for each upstream package that is consistent with the one needed for the downstream package, but restricted to the transitive dependencies of the upstream package. This build plan is part of the hash for the upstream package, so we can pull it out of the Nix store if we've built it before. When things go wrong, it is either on the Nix side, or the Cabal side. If it's on the Cabal side, you can look at the
The bash is just madness to make all that happen while only using |
First of all, thank you for your detailed explanation.
the cabbage.config file looks like this
Interestingly I still get the message that zlib might require a system package
The output of |
Hm, we need to figure out why some dependencies aren't getting included there. Could they be globally installed? It's surprising that |
Ah of course, I have quite a lot in my global database as I am using ghcWithPackages for binaries (e.g. ghc-mod). I guess I should either remove all of them (which I don't really want to do) or not use cabbage? This is the complete list
|
(Skip to the last paragraph if you don't want the background.) Right, so that is the problem. First off, you can absolutely use executables like ghc-mod, I certainly do. With regard to your setup, maybe this could be made to work, but it's not easy. A tricky issue that cabbage has to work around is that Cabal and GHC don't do a good job at package management. Specifically, the dependencies any package is built against make up part of its identity; name and version number are not enough. Even worse, GHC can be a bit funny about global packages in that hiding them is buggy (this may be improved in 7.10), so cabbage works around them. What cabbage does, is if a globally installed package is being updated, then it instead uses so-called "cabbage patched" versions of globally-installed packages to ensure that the full dependency chain is consistent. This will be visible in the build plan as versions of packages with a 4552 suffix on their version numbers. If you need a newer version of If, however, all dependencies available in the global DB are the right versions, then they will be used. So what's happening, it seems, is that those packages are getting picked up when doing the cabbage preparation, but are not getting picked up when we're running the build in the Nix store. Interestingly, Cabbage works in NixOS and Darwin with global package databases as come with GHC, but perhaps the haskell-ng infrastructure is doing something with package databases that is giving us these conflicting reports of the global DB. It is probably because we are running |
You are excellent at providing explanations, thanks! I set up a clean environment and everything is working just fine. I looked at what I had in ghcWithPackages and it turns out that I could remove almost everything. However (at least to my knowledge) ghc-mod should stay in there as it uses the ghc api and will break otherwise because ghc can update without a ghc-mod rebuild. Sadly putting ghc-mod in there already pulls in a long list of dependencies which results in the same problem as I had previously. |
For myself, I built I feel like there should be a pretty lightweight way to address this, but I haven't put my finger on it yet. |
When I try to build a toyproject I'm getting the following error on
nix-shell --command 'sh $setup'
. I runcabbage -a
before. I also tried deleting.cabbages
,cabal.config
,cabal clean
andcabal sandbox delete
but sadly with no effect. Generating a shell.nix usingcabal2nix --shell . > shell.nix
and then runningnix-shell --command 'cabal build'
works just fine. Sadly I don't really know what I am doing and this bash script is scaring me so I'm a bit lost. I'd be happy to provide more information if needed.Not quite sure which files are relevant so here is a selection :)
cabal.config
default.nix
The text was updated successfully, but these errors were encountered: