3.1 build is broken with Nix because the dependency on zip vanished

[peti]

af8c8f1 broke the build with Nix. Reading the commit message, I am slightly puzzled about what your motivation to make that change might have been.

[jgm]

I can put this back if there's a good reason. I reasoned as follows: cabal can't install 'zip' by itself anyway, so the only effect of having the custom build is that cabal gives an error message if 'zip' isn't present. Without the custom build, it's the same, except that the test suite gives the error message. So, simplify.

Does NiX detect that cabal requires zip, and install zip itself?

[peti]

The only effect of having the custom build is that cabal gives an error message if 'zip' isn't present.

I would argue that having a good error message early in the build, i.e. during configure, rather than a test suite failure at the end is quite a significant benefit.

Does Nix detect that cabal requires zip, and install zip itself?

Yes, it does.

[jgm]

If I recall correctly, I removed the custom setup because stackage was requiring that the package pass cabal check, and cabal check now fails for custom builds unless you have a setup-depends field, which then requires Cabal >= 1.23. I reasoned that it would be better to remove the custom build than to make the package unbuildable with anything but the most recent versions of cabal. Most build environments will have zip installed anyway. In the rare ones that don't, the build will still fail with an informative message, as I noted (of course, I agree that all things considered an earlier message would be better, but it's a matter of balancing considerations).

I tried just now reverting the change and adding the custom-setup stanza. But now, even with the custom setup, the build fails with the message setup: Unknown build tool zip. Of course, zip is not one of the officially recognized build tools. So this is not going to work anyway (I'm not sure how it worked before, but maybe using a recent cabal version made a difference?).

Any thoughts or suggestions? I guess the most promising idea I have is to remove the part of the test suite that runs the external zip program, and instead include an externally created zip file in the archive. Of course, that doesn't speak to the general issues raised by the above worries for other packages...

[jgm]

I've fixed this by including a pre-made zip in the test suite.

[peti]

cabal check fails for custom builds unless you have a setup-depends field, which then requires Cabal >= 1.23

I've found that requiring Cabal >= 1.10 is good enough with setup-depends. cabal check won't complain and that version of Cabal will interpret the Cabal file fine, syntactically, it just won't make any efforts to fulfill those requirements -- which isn't a problem in your case, because Setup.hs depends only on base and Cabal, and those dependencies are there anyway. As an example, check out https://github.com/peti/hsyslog/tree/t/cabal-doctest-support, which uses a sophisticated custom build to run doctests reliably.

[peti]

Also, even if you require Cabal >= 1.23, then this means just that people have to use a recent version of cabal-install to run the build, but the build will still succeed fine with older compilers. It's unpleasant, but IMHO expecting users to have a recent version of cabal-install is quite reasonable (whereas you cannot generally expect them to have the latest version of ghc).

[jgm]

I've found that requiring Cabal >= 1.10 is good enough with setup-depends.

That's good to know. I'll need the custom setup with pandoc, in any case.

Though I wonder if stackage will accept the package if it has setup-depends but no cabal >= 1.23.