Can you rebase this on the haskell-updates branch?

Argh, right. I forget this every time.

@erictapen Could you send a PR upstream fixing this? And then update this PR with a link to the upstream PR?

This is so that we (the nixpkg haskell maintainers) know when we can remove the doJailbreak call.

@cdepillabout Personally I think making an upstream PR every time a bound is broken is kind of a waste of time, as it takes a non-trivial amount of time to do, with not much of a benefit, especially with Haskell where in most cases you just get a compilation failure if it truly doesn't work with the version we have. I think in the future we should jailbreak all packages by default so we never have to worry about this kind of thing

@cdepillabout Normally I'd do an upstream PR, but as the latest commit is 5 years ago I'd rather not take the work of creating a bitbucket account and sending them my code, risking that they don't respond. Besides that I agree with what @infinisil said.

@infinisil I thought about this for a couple days. I think this is a tricky question.

To start off, I should say that I've been helping with the Haskell stuff for the last couple months, and my number one priority has been reducing the burden on @peti. I think he is the one that spends the most time fixing up stuff on the haskell-updates branch.

An easy way to reduce his burden is to get stuff fixed upstream, and put ample comments on stuff that is not (yet?) fixed upstream.

Also, if we get stuff fixed upstream, then it normally benefits all Haskell users, not just people using nixpkgs. Since most of the people that contribute Haskell-related fixes to nixpkgs are Haskellers, my guess is that most people want to fix contribute to and fix things for the entire Haskell community, not just nixpkgs.

I try to take this on a case-by-case basis though. For a contributor that is not a Haskeller and just wants to fix a bug in pandoc, for example, I'll sometimes do the upstreaming-fixes part myself.

As for whether or not fixing bounds is a waste of time, I'm not too sure.

In the Haskell community, there are many people who use overly-restrictive upper and lower bounds. However, there are also people who use bounds to mean, "My package really can't use this dependency of a given version".

Jailbreaking all Haskell packages would be nice for the first case, but would be actively harmful for the second case. Doubly so for cases where the package does compile cleanly, but it doesn't work right. Figuring out what is going wrong, and fixing it in those cases would be pretty difficult.

However, I'm not sure which strategy would lead to less work overall. The strategy of just jailbreaking everything could be less work. But we wouldn't be helping the wider Haskell community at all.

The big problem with nixpkgs is that we don't have anything like the cabal solver, which can sometimes find a valid build plan even with overly restrictive upper bounds. And even if we did have this, we don't have old versions of most packages that we could use.

Also, we currently have a large number of doJailbreak that no one has probably audited since it was initially added. I can't recall ever seeing someone submit an issue about any of these, so I think this is a point in favor of jailbreaking everything by default.

@erictapen

but as the latest commit is 5 years ago I'd rather not take the work of creating a bitbucket account and sending them my code

In this case, I definitely agree that trying to send a PR would be too much work.

Can you update this PR to resolve the merge conflict, and also add a comment explaining why this doJailbreak is needed, and why this hasn't been fixed upstream (no release in 5 years)?

@cdepillabout

Can you update this PR to resolve the merge conflict, and also add a comment explaining why this doJailbreak is needed, and why this hasn't been fixed upstream (no release in 5 years)?

Sure! It's done.

@erictapen Unfortunately, with the update to LTS-15 in #79819, it appears that hakyll itself no longer compiles:

$ nix-build -A haskellPackages.hakyll-contrib-hyphenation
these derivations will be built:
  /nix/store/ik6y09v9clpsbx2gycvmh8jyhd1cwm97-hakyll-4.13.0.1.drv
  /nix/store/24818kkzgv5zzfslk4g7h3p6fg3zl8h8-hakyll-contrib-hyphenation-0.1.0.3.drv
building '/nix/store/ik6y09v9clpsbx2gycvmh8jyhd1cwm97-hakyll-4.13.0.1.drv'...
setupCompilerEnvironmentPhase
Build with /nix/store/4azq68l84647ldzgb3626id89niaxmr3-ghc-8.8.2.
unpacking sources
unpacking source archive /nix/store/0avfsx2x9w4br7pgq5qk485yp3sdkncg-hakyll-4.13.0.1.tar.gz
source root is hakyll-4.13.0.1
setting SOURCE_DATE_EPOCH to timestamp 1568767371 of file hakyll-4.13.0.1/CHANGELOG.md
patching sources
compileBuildDriverPhase
setupCompileFlags: -package-db=/build/setup-package.conf.d -j4 -threaded
[1 of 1] Compiling Main             ( Setup.hs, /build/Main.o )
Linking Setup ...
configuring
configureFlags: --verbose --prefix=/nix/store/qx6ad8nclad2jb0hz6b0zdr2axzhza91-hakyll-4.13.0.1 --libdir=$prefix/lib/$compiler --libsubdir=$abi/$libname --datadir=/nix/store/h9cajgzz23g9ybvgpwvsp8sc869pp5qz-hakyll-4.13.0.1-data/share/ghc-8.8.2 --docdir=/nix/store/4a36f617f21bfk3yh20yyr3gzmra9qil-hakyll-4.13.0.1-doc/share/doc/hakyll-4.13.0.1 --with-gcc=gcc --package-db=/build/package.conf.d --ghc-option=-j4 --disable-split-objs --enable-library-profiling --profiling-detail=exported-functions --disable-profiling --enable-shared --disable-coverage --enable-static --disable-executable-dynamic --enable-tests --disable-benchmarks --enable-library-vanilla --disable-library-for-ghci --ghc-option=-split-sections --extra-lib-dirs=/nix/store/7yjv8l75a8b1x3vmmnbsdwd5b0gzngga-ncurses-6.1-20190112/lib --extra-lib-dirs=/nix/store/phwyg24nm8z4r91iyrhmdfljxpw1ihd5-libffi-3.3/lib --extra-lib-dirs=/nix/store/r05vk4zq34sps98izq4v4n9h7m1a6wgx-gmp-6.2.0/lib
Using Parsec parser
Configuring hakyll-4.13.0.1...
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.hs:2:8 in main:Main
Setup: Encountered missing or private dependencies:
optparse-applicative >=0.12 && <0.15,
regex-tdfa >=1.1 && <1.3,
template-haskell ==2.14.*

builder for '/nix/store/ik6y09v9clpsbx2gycvmh8jyhd1cwm97-hakyll-4.13.0.1.drv' failed with exit code 1

Would you be willing to fix the hakyll build as well?

Sorry to keep dragging on this PR.

This needs to be backported to release-20.03. Should I create a separate PR for that?

peti is planning on backporting this bump to LTS-15 to 20.03, so as long as this PR gets merged before then, you shouldn't need to explicitly backport it.

Mh, seems like the most important breakage comes from GHC 8.8: jaspervdj/hakyll#754

I already fixed some errors, but didn't come through (partly because of lack of time, mostly because I have no real idea what I'm doing here). My progress is here: https://github.com/erictapen/hakyll/tree/ghc-8.8

Hakyll 4.13.1.0 has the fix: jaspervdj/hakyll#754 (comment)

When this lands in haskell-updates, I'll rebase and we can attempt to merge this again.

@erictapen The new version of hakyll should be available now.

Andd it builds for me 👍

Looks good. I've confirmed it builds.

Thanks for sticking with this and figuring everything out.