Fix setup-depends dependencies

[hamishmack]

Needs input-output-hk/nix-tools#51

[Ericson2314]

BTW it's been my long-standing intention to make setup a proper component in Cabal/cabal-install too.

[angerman]

@Ericson2314 please be my guest! ;-) is be happy to see the Setup.hs being a component. You’ll end up with some minor bootstrapping issue though. You’ll need the Setup.hs to build the Setup component :-) Unless you go through cabal-install, but then how do you build cabal-install?

[Ericson2314]

@angerman setup components would be exe components without custom setups in practice, but yes the implementation would probably be able to deal with such a thing. It's not that different than setup-depends libraries having custom setups, which already works.

haskell/cabal#4047 was an issue made after I talked to ezyang. Wow that was a long time ago. I think after I'm with my current rummaging around in GHC I'll get back to Cabal so will still be a long ways off.

[hamishmack]

This PR had conflicts with the shellFor stuff that has now been merged into master. Mostly because the setup builder was moved into hspkg-builder.nix (from default.nix). I have rebased this PR so it now modifies hspkg-builder.nix.

[rvl]

Sorry about that, I had to move stuff.

[hamishmack]

Sorry about that, I had to move stuff.

No worries. Totally worth it, the shellFor stuff is awesome.

[angerman]

@hamishmack can we rebase this and get it ready for merging?

[angerman]

@hamishmack is this still a draft or is this ready?

[rvl]

Apologies for the late review.

Would it be possible to use the makeConfigFiles function in setup-builder.nix?

Because I see a chunk of hairy code which is duplicated here.

[rvl]

It looks better now. But I can still see make-config-files is imported twice. Would it be possible to define all the parts of the builder at the top-level builder/default.nix? This will untangle the dependencies a bit. I pushed a commit with this rearrangement, but didn't test that it works.

[angerman]

@hamishmack can we get this finished?

[rvl]

Looks good to me!

[hamishmack]

The test failure was related to cabal-doctest not being in the pkgs.nix for nix-tools. This is likely to be a common problem. The root cause is that plan.json output does not include the packages referenced in the setup-depends of packages it plans to get from hackage. In this case the distributive package is a needed by nix-tools and it wants cabal-doctest for its setup depends.

[rvl]

The test failure was related to cabal-doctest not being in the pkgs.nix for nix-tools.

Hmm, tricky. Rather than fiddling with the project package set, could we grab the setup depends out of a separate package set? (Like the haskellPackages top-level attribute of Haskell.nix)

[hamishmack]

It turns out that yesterday when I tested plan-to-nix I was inside a shell that had distributive in ghc-pkg list. As a result its setup depends (like cabal-doctest) were not included in plan.json.

I tried again with just ghc 8.6.5 in the shell and cabal new-configure included cabal-doctest in plan.json. I ran plan-to-nix and have committed the results to this PR.

I think we should be ok as long as people use callCabalProjectToNix or take care not to run plan-to-nix inside a shellFor.

[hamishmack]

take care not to run plan-to-nix inside a shellFor

I should have said: take care not to use plan-to-nix on a plan.json file generated inside a shellFor.

[rvl]

take care not to use plan-to-nix on a plan.json file generated inside a shellFor.

That's interesting. Maybe I should I document it? Or maybe there's some other way of avoiding this problem. Seems like something that users might hit every so often.

[ocharles]

I would note I made exactly the same mistake. We use the normal nixpkgs Haskell stuff and have a working shell, so when I ran plan-to-nix I ended up with something entirely wrong. It was only when I ran it in a pure shell that I got the correct plan. It's worth documenting this (though ideally one would use callCabalProjectToNix which avoids this problem, at the cost of IFD).

[rvl]

Just checking, are the latest commits necessary to fix setup-depends dependencies?

Could we merge a basic fix first, then address enabling tests and more cross-compilation fixes?

[hamishmack]

I am not sure they are necessary. I am worried that the setup-depends changes introduce new dependencies on buildPackages and may introduce regressions in cross compilation.

[angerman]

I agree with @rvl here. I think it would be good to have this one split, with the last two commits in a separate PR. We are going to squash this anyway, and I'm afraid we are conflating stuff here otherwise. Specifically as 8faff20 looks remarkably like #134. Also, CI was green at 2d2b4f9. So I think this should be fine to split.

[hamishmack]

Ok. I have removed the last two commits.

[angerman]

One more change and I think we are golden :-)

[angerman]

Suggested change

	{ stdenv, buildPackages, haskellLib, ghc, nonReinstallablePkgs, hsPkgs, makeConfigFiles }:
	{ buildPackages, stdenv, lib, haskellLib, ghc, nonReinstallablePkgs, hsPkgs, makeConfigFiles }:

[hamishmack]

This seems to be outdated.