bundle Cabal
mikelpr opened this issue · 10 comments
I can't get a working cabal version.
with all-hies.versions.ghc865 and nixos-20.03, it doesn't recognize Cabal_3_0_0_0.
[__0] rejecting: Cabal-2.4.0.1/installed-2.4... (constraint from user target
requires ==3.0.0.0)
with ghc882 and nixos-unstable fce7562cf46727fdaf801b232116bc9ce0512049, it won't take Cabal_3_2_0_0
[__0] rejecting: Cabal-3.0.1.0/installed-3.0.1.0 (constraint from user target
requires ==3.2.0.0)
with ghc882 and nixos-20.03, it does take Cabal_3_0_0_0 but I can't use it as it has persistent-2.9.2 with a base constraint of <= 4.13:
CallStack (from HasCallStack):
die', called at libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:1022:20 in Cabal-3.0.1.0:Distribution.Simple.Configure
configureFinalizedPackage, called at libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:475:12 in Cabal-3.0.1.0:Distribution.Simple.Configure
configure, called at libraries/Cabal/Cabal/Distribution/Simple.hs:625:20 in Cabal-3.0.1.0:Distribution.Simple
confHook, called at libraries/Cabal/Cabal/Distribution/Simple/UserHooks.hs:65:5 in Cabal-3.0.1.0:Distribution.Simple.UserHooks
configureAction, called at libraries/Cabal/Cabal/Distribution/Simple.hs:180:19 in Cabal-3.0.1.0:Distribution.Simple
defaultMainHelper, called at libraries/Cabal/Cabal/Distribution/Simple.hs:116:27 in Cabal-3.0.1.0:Distribution.Simple
defaultMain, called at Setup.lhs:7:10 in main:Main
Setup: Encountered missing or private dependencies:
base >=4.8 && <4.13
which I interpret as out of scope for this project, yet I can't use get away with newer nixos-unstables as they don't have Cabal_3_0_0_0 anymore but Cabal_3_2_0_0. a bundled Cabal would help immensely
and if someone could suggest me a good comptabile commit pin it'd be nice.
I am stuck and can't progress at all, if anyone has a pinned version who could share, please, I'm desperate
Indeed. Since with Cabal 3.2 in NixPkgs everything was evaluating and compiling the Haskell package set just fine without the need of Cabal 3.0, and between 3.2 and older Cabal 3.0 was some dependency issues. So Cabal 3.0 was no more.
Since Cabal 3.2 was released on 03-31.
And right on the next day (04-01) Nix Haskell set was updated to new LTS 15.10, and Cabal 3.2 got introduced.
#55 story was raiser on 04-05.
Try GitHub NixPkgs commit NixOS/nixpkgs@52e7e6d seems to be right where you need, right before 04-01 Nixpkgs Haskell changes.
If that commit does not work you always just can run git bisect on a range to find working commit. Like git bisect start 52e7e6d9e7441e2133997eae796cc172d400eefd 52e7e6d9e7441e2133997eae796cc172d400eefd~512
Or try Friday mornings before 03-31, NixPkgs Haskell changes are mostly merged during Fridays ~18:00-19:00 GMT.
If you succeed in your endeavors - please say to me - that info would may help me in return.
Thank you.
thanks @Anton-Latukha, I ended up randomly picking from march, ended up using NixOS/nixpkgs@6bba942 which works. the one you pinned seems to include Cabal 3.2 already tho
interesting those comments about haskell.nix, looking forward to it
Hm...
As I said, it was released on 03-31.
Well. At least I tried to help.
Learn to rely on bisects - they are simple and always useful - a universal method.
The problem thou that in nixpkgs there is a lot (everything) to compile in old check-outs, due to Hydra discarding old caches. And nixpkgs starts to get a pretty monstrous number of commits just in a week. It actually gets to the magnitude of the Linux Kernel, and with some work done on automating the nixpkgs processes, and some other things we have in the process - we can easily achieve that velocity of changes, becoming the fastest and biggest in the number of improvements made.
But the more there velocity of commits - the more stages to bisect, and so iterations to evaluate and compile.
you tried and I am thankful, specially for the bisecting advice. big thanks <3
now, I don't know whether to close this bug. is the haskell.nix branch going to fix the cabal mess?
Yes, I am sure that Infisil works on it.
He messaged in that thread just today.
Cabal:
I do not know if you about .2.4
In Nixpkgs - 3.0 was deleted completely.
3.2 works just fine in there. When all-hies solves stuff - it would work properly.
Why not. When people in Haskell work the stuff gets into the working state quickly.
And in fact somehow ghc865 you mentioned first - just suddenly started to work fine, thou I am having everything on nixos-unstable generation 2019-04-12 20:00:49. There seems to be no way to give you the commit.
I do not know. As you see from the date - I did not updated anything, I only Dev'ed inside the nix-shell, and HIE got up. Weird, IDK.
Of course everything would stabilize.
haskell.nix is a way. WAY better project then stack. With a WAY way more main contributors. With a very, VERY mature specialists.
haskell.nix is less then a year, and has 180.
stack2nix was around like 2-3 years, and it was a unique tool for its purpose. While it "allows" migration from stack to Nix - which is a major practice. Why it has would only have 90 stars, how do you think that happened. It basically was frequently or broken, or could not export something, or there was store NixVsStack dep issues, and at the same time its development was largely abandonned.
So yes, haskell.nix would work great, and very-very soon.
With #64 merged, there is now a set of templates showing how to get a working Cabal version: https://github.com/Infinisil/all-hies/tree/master/templates