Presence of zip build-tools requirement causes Stackage breakage
Closed this issue · 6 comments
I'm not sure what the correct solution here is, whether to modify zip-archive.cabal or change Stackage semantics. Currently, Stackage uses the build-tools fields to force the correct ordering of building Haskell packages. For example, to make sure alex and happy are built before things that depend on them.
The addition of the zip requirement to the zip-archive test suite causes confusion here, since there is no executable zip provided by any Haskell packages, which causes your test suite to be listed as failing. Like I said above, I'm not sure what the correct solution is. Temporarily, I can just disable the test suite for zip-archive, but that's a sub-optimal solution.
I was asked to add this by the people who do automatic package generation (NixOS, debian, etc.), so that their scripts will be able to pick up on the test suite's dependency on zip.
See #21. @peti, can you come in on this discussion? Both Stackage and packages are important. We need a solution that can work with both, if possible.
+++ Michael Snoyman [Jan 22 15 05:45 ]:
I'm not sure what the correct solution here is, whether to modify zip-archive.cabal or change Stackage semantics. Currently, Stackage uses the build-tools fields to force the correct ordering of building Haskell packages. For example, to make sure alex and happy are built before things that depend on them.
The addition of the
ziprequirement to the zip-archive test suite causes confusion here, since there is no executablezipprovided by any Haskell packages, which causes your test suite to be listed as failing. Like I said above, I'm not sure what the correct solution is. Temporarily, I can just disable the test suite for zip-archive, but that's a sub-optimal solution.
Reply to this email directly or view it on GitHub:
#23
@snoyberg, the assumption that build-tools contains only Haskell packages seems problematic. Cabal makes no such assumption: it allows people to list anything as a build tool for which a proper Program definition exists, and that's any program, really, it doesn't even have to be an executable. Both ArchLinux and NixOS use the build-tools stanza to identify build inputs that can be Haskell or system programs. I guess the Debian tool chain does the same thing, but I'm not sure.
Anyway, wouldn't it be sufficient if Stackage simply ignored all entries in build-tools that it doesn't know about?
To be clear: I'm not convinced that Stackage is doing things correctly here. Honestly, I think the real problem here is the complete lack of clarity from Cabal around build-tools. I'm going to explain my reasoning for things, but I'm not necessarily arguing for this interpretation.
If you look in the library, buildTools is of type [Dependency], which is defined as a product type including a PackageName. So AFAICT, build-tools is supposed to refer to Haskell package names. In practice, however, that's not respected universally.
I'm probably going to go with your idea of just ignoring a missing build tool, but I wanted to at least explain my reasoning.
@snoyberg, I completely agree that the ambivalence of build-tools is a problem in Cabal. In practice, the field may refer to a Haskell package or it may not, and there's no way to distinguish between the two cases. For libraries, there is a clear distinction between build-depends and extra-libraries, but build-tools doesn't follow the same scheme. cabal-install seems to have the same problem as it doesn't take the information from build-tools into account when constructing the install plan. Build descriptions are a complicated subject, and Cabal has gotten it mostly right, IMHO, but not entirely.
OK, I'm just going to go ahead with commenting out the build tools check. That means I'll continue using it as I am now to set up the dependencies between Haskell executables and libraries, but nothing else. Thanks for the feedback guys.
@jgm Feel free to close this issue, I'm only leaving it open in case you still have some thoughts on it.