RFC: Requiring GHC 7.10 or higher

[quasicomputational]

As part of the move away from v1-style cabal-install usage, I'm looking at passing package environments around in the test suite. However, those were new with GHC 7.10, so tests would not be able to run on GHC 7.8 or 7.6 as they do today.

I'd rather not release code claiming compatibility that isn't being actively tested in CI, so I would also like to formally drop GHC 7.8 and 7.6 compatibility at the same time.

GHC 7.10.2 (IIRC, 7.10.1 had a serious bug) was released on 2015-07-22, more than five years ago; I think that's long enough for anyone to have upgraded.

Further, anyone who truly has to use such an old GHC can also use an old doctest release.

I do note that lens tests on GHC 7.8 at the moment, and it's one of the most prominent doctest consumers.

@phadej, @RyanGlScott: You two are responsible for a whole bunch of load-bearing packages. Would this be a problem for you if it happened in the near-ish future?

[RyanGlScott]

At first glance, I don't see any issue with dropping support for pre-7.10 GHCs. If someone wishes to continue using doctest with old GHCs, they can just use an old version of doctest, after all.

Out of curiosity, what are you planning to do with package environments in doctest? I ask since doctest deliberately ignores .ghc.environment files—see ulidtko/cabal-doctest#55. But then again, you are the person who made this change in cabal-doctest, so you are probably aware of this :)

[quasicomputational]

Out of curiosity, what are you planning to do with package environments in doctest?

Nothing exciting - just plumbing the information through about which packages to use and where to find them (most relevantly, QuickCheck), since the package DBs are no longer in well-known locations. Getting that information out of cabal-install requires either something shaped like cabal-doctest (i.e., collecting the package list & package DB locations at configure time with a custom setup, then deliberately ignoring package environments at runtime because all the relevant information is already known - hence the cabal-doctest PR you linked) or using the package environment that cabal-install writes.

cabal-doctest makes various assumptions about how doctest is going to be driven, entirely reasonably for downstrean consumers, but doctest's test suite needs a bit more flexibility in how it invokes doctest (e.g., cabal-doctest would really want every single invocation to have its own package, but there are literally hundreds of them). doctest proper is actually package environment agnostic; the GHC it invokes will look for them (or not look) depending on the options passed - so just letting GHC pick up cabal-install's package environments works like a charm. (And I think the same goes for Stack, though GHC learns about the package environment through a GHC_ENVIRONMENT env var rather than a magically-named file.)

[andreasabel]

In the project I am using doctest, https://github.com/BNFC/bnfc, I now only support GHC >= 7.10. So dropping 7.8 and 7.6 is fine for me.

[andreasabel]

In the meantime, support has been dropped for GHC 7.

doctest/package.yaml

Line 41 in 6bb14c4

- ghc >= 8.0 && < 9.10