Closed quasicomputational closed 4 years ago
Well, that's an interesting error in CI:
Documentation created: dist/doc/html/Cabal/index.html,
dist/doc/html/Cabal/Cabal.txt
installing
Installing library in /nix/store/qinkj8nlpl8v2qcca7102gq2vc5yq1j2-Cabal-3.0.0.0/lib/ghc-8.2.2/Cabal-3.0.0.0
mv: target 'Cabal-3.0.0.0-AnMVl2OC2rpCXB4gHSOdtG.conf' is not a directory
builder for '/nix/store/vy61359zhwfldw9a3spvxhnsv3ymzj30-Cabal-3.0.0.0.drv' failed with exit code 1
My best guess at what's going on: the generic builder is using Cabal
3.0.0.0 to build the setup
component, and something in how that operates has changed that's confusing the generic builder.
Looking at the generic builder's code, which features a 'scary sed expression', it's not entirely surprising that it's been broken and will need porting.
@Gabriel439 - you know the most about Nix out of the lot of us, I think. Is that plausible? And, if you figure that's the cause, is there a way to get the Cabal
package to use version 2.4.1.0 (or whatever version is handy) to build setup:Cabal
while having 3.0.0.0 for dhall-to-cabal
?
@quasicomputational: Usually for this sort of thing it's easiest to upgrade to a newer version of Nixpkgs (analogous to upgrading to a newer stack
resolver) assuming that the default than to try to selectively use a newer
Cabal`
This is the part that is responsible for selecting the revision of Nixpkgs:
You can simplify it a little bit by using the updated instructions here:
https://nixos.wiki/wiki/How_to_fetch_Nixpkgs_with_an_empty_NIX_PATH
... so that you can use builtins.fetchgit
.
The current tip of master
for Nixpkgs (https://github.com/NixOS/nixpkgs/commit/6576162fe9e6ddaf1df95429b8462e84a2ef1c06) has ghc 8.8 available with Cabal 3.0:
When upgrading to a newer revision of Nixpkgs you may need to unpin or update the pinned *.nix
packages in the root of this repository (analogous to having to rediscover the correct extra-deps
when upgrading to a newer stack
resolver).
Upgrading the pinned nixpkgs seems to do the trick - at least, now I have Cabal
3.0.0.0 sitting in my local Nix store.
The next blockage is ghc-paths
: the released version doesn't work with 3.0.0.0 (simonmar/ghc-paths#18); however, it's only used in a setup component, so theoretically this is solvable if I had the flexibility to constrain them separately. I might be able to hack around this under my own steam...
stack test
should be happy now. AFAIK there are no blockers left to merge, so I'll do that in a few days unless someone speaks up.
stack build
is broken and so this probably shouldn't be merged yet.Things I'm not quite sure about:
Should we put in some new convenience functions for depending on only the main library? There's a lot of
[ types.LibraryName.main-library ]
.Should the
Text
inPkgconfigVersionRange
be abstracted into aPkgconfigVersion
, like howVersion
is?Naming bikeshedding welcome.