Is it really necessary to require Cabal >= 2 for haddock-library?

[jgm]

When we do a static linux build of pandoc for our linux binary packages, we use an alpine docker image that only has ghc 8.0.2, so we need to use the lts-9 resolver for stack. This means we have Cabal < 2, so we can't include an up-to-date version of haddock-library. As a result, the pandoc binary we produce will not handle some of the newer haddock features, like tables.

If there is any way to avoid requiring Cabal > 2 for haddock-library, it would be a good thing.

[hvr]

Fwiw, the latest haddock-library versions are aimed at GHC 8.4.2 , so it would be perfectly fine to even use cabal-2.2 features (and for the record, haddock-library has been using cabal-2.0 features for almost a year already); It's really unfortunate that Stack and Stackage seems to repeatedly hold us back (we had a couple of such incidents in the last half year or so). Moreover, my understanding so far was that Stack developers would rather that Stack wasn't included in Linux distributions to avoid outdated buggy versions of Stack that can't be upgraded in a timely matter to be out there in the field. Consequently I'd rather suggest you avoid using Stack to build pandoc binaries and instead use cabal which I'm happy to help you with if you need assistance.

[harpocrates]

There isn't really a fundamental reason, beyond using shiny new features in the haddock-library.cabal. You can pretty easily rewrite that file to build haddock-library with Cabal 1.24 (I just did locally).

• replace uses of ^>= operator with the corresponding expansion
• get rid of the library attoparsec section and move those dependencies and source files directly into the library section

In short: handling the (IMO already gross) vendored attoparsec dependency would be grosser if the maintainers wanted to support Cabal < 2.

[hvr]

@harpocrates That's not the point. Obviously, this was possible in a hacky way; this is exactly how we had to do this before cabal 2.0; but which I cleaned up once we had cabal 2.0 which provided us a clean/proper way to vendor libs. ;-(

And I'm honestly quite annoyed that you use words like "gross" to describe something I considered rather elegant ;-((

[gbaz]

@hvr certainly the internal-lib version of the vendoring is much more elegant than the not internal lib version. However, I think that not vendoring is certainly the most elegant solution of all :-)

In any case, to answer @jgm's question in the way that might unblock the quickest -- can't you just tweak the extra-deps to bump the Cabal version in the snapshot as per https://docs.haskellstack.org/en/v1.0.2/faq/#i-need-to-use-a-different-version-of-a-package-than-what-is-provided-by-the-lts-haskell-snapshot-im-using-what-should-i-do ? Or is there some unanticipated problem with other deps when doing so? (Perhaps a few other things need bumping too in such a case).

@hvr I think the issue btw on why they are using stack is they are trying to build something fully-statically-linked and the best instructions around for doing so involve exactly that config (https://www.fpcomplete.com/blog/2016/10/static-compilation-with-stack). If there was a better way to do that with more modern tools, then that would be preferable -- but I confess I'm not wise enough to know of one :-)

[jgm]

Fwiw, the latest haddock-library versions are aimed at GHC 8.4.2

That's fine for haddock itself. But pandoc uses haddock-library to convert to and from haddock format, and pandoc can be built with much older ghc versions. It would be nice if this one piece of the ecosystem didn't force using more modern tools to build the project.

can't you just tweak the extra-deps to bump the Cabal version in the snapshot

I can look into this possibility. I can't remember whether I tried that.

Consequently I'd rather suggest you avoid using Stack to build pandoc binaries and instead use cabal which I'm happy to help you with if you need assistance.

I've tried every incantation I could think of to build a fully statically-linked pandoc using cabal, and so far I've failed. By fully static, I mean

/usr/bin/pandoc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped

No dynamic linking, even to basic system libraries. Passing cabal the same ghc-options and cabal flags that do the trick for stack does not work, for reasons I don't understand. Using stack also gives a guarantee that the same underlying libraries will be used for every package build, on every platform, which is helpful. (I know this can probably be done now with cabal freeze, though.)

[sjakobi]

In any case, to answer @jgm's question in the way that might unblock the quickest -- can't you just tweak the extra-deps to bump the Cabal version in the snapshot as per https://docs.haskellstack.org/en/v1.0.2/faq/#i-need-to-use-a-different-version-of-a-package-than-what-is-provided-by-the-lts-haskell-snapshot-im-using-what-should-i-do ? Or is there some unanticipated problem with other deps when doing so? (Perhaps a few other things need bumping too in such a case).

The extra-deps apparently don't affect the environment that stack uses to build the Setup.hs file.

What appears to work for me, is to run stack --resolver lts-9 setup --install-cabal 2.0.1.1. This command replaces Cabal-1.24.2.0 with Cabal-2.0.1.1 in the global setup environment for lts-9.

When I tried to install Cabal-2.2.0.1 first, I got an error about Control.Monad.State.Class not being available.

EDIT: I had totally forgotten that I myself had proposed the implementation of the --install-cabal flag in commercialhaskell/stack#2386. I had to google and lookup the flags for stack setup to find it. Oh my leaky brain! 😄

[jgm]

@sjakobi thanks a lot, that worked! This issue can be closed, as far as I'm concerned.