Support LTS-23.1 more cleanly

[hseg]

Tested both stack and cabal find build plans, both chosen build plans pass
tests. To support lts-23.1, I ended up bumping the upper bounds for a couple
dependencies:

• bytestring < 0.13
• megaparsec < 9.8
• optparse-applicative < 0.19 (see below)
• time < 1.13
• zip < 2.2.0
  I toyed with bumping generic-arbitrary too to support 1.0.1, but that gave
  me an ambiguous instance bug that I couldn't figure out in time. I am leaving
  in my rewrite of its bounds using ^>=, though.

The extra-deps I left in stack.yaml are only those I needed after nuking the
rest. There may be a more optimal selection there, but I went with stack's
recommendations.

To support optparse-applicative 0.18.*, I needed to add a shim
Options.Applicative.Pretty.Shim. This is because it has moved away from the
deprecated ansi-wl-pprint to prettyprinter, and in the process replaced the
monomorphic prettyprinters like text :: String -> Doc with the polymorphic
pretty :: Pretty a => a -> Doc ann. I opted for writing a shim to concentrate
the CPP code in one place, and because the coding style of GHCUp.OptParse
would make redefining text = pretty in each module cause ambiguity problems in
Main.hs. Of course, we could instead just bump the lower bound of
optparse-applicative.

I have merely checked that stack test and cabal test pass with this
configuration using ghc 9.8.4. If we need a wider test matrix, please let me
know (I tried checking docs/dev.md for instructions on building on other
GHCs, but the per-ghc project files seem to have been deleted?)

[hasufell]

I'm a bit confused... I think we already support building with GHC 9.8.4, no?

Is this about bumping dependencies?

[hasufell]

There are legit failures on 8.10.7: https://github.com/haskell/ghcup-hs/actions/runs/12471541117/job/34821579458#step:4:1

[hseg]

Sorry, yes - this is about finding a build plan compatible with `LTS 23.1`. My motivation here is to cut down the number of ghcs I need to have insalled t io build the programs I use - at the moment, ghcup is the only one for whom my usual strategy of bumping the resolver and adding the necessary extra-deps doesn't work, due to these restrictive upper bounds. I'm afk, will check the logs later to see what I broke. 24 dic 2024 08:02:58 Julian Ospald ***@***.***>:

…

There are legit failures on 8.10.7: https://github.com/haskell/ghcup-hs/actions/runs/12471541117/job/34821579458#step:4:1 — Reply to this email directly, view it on GitHub[#1182 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AAJTW5OUU5YVGTC6DV42XML2HD2JFAVCNFSM6AAAAABUDQKQPWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRQGY4TONBVGQ]. You are receiving this because you authored the thread. [Imagen de rastreo][https://github.com/notifications/beacon/AAJTW5KFZKPJAKHPS5S5T4D2HD2JFA5CNFSM6AAAAABUDQKQPWWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUYUESG4.gif]

[hseg]

huh, that's a very weird breakage, especially considering chs-cabal seems to be a transitive dependency (at least, git grep chs-cabal doesn't show it)

[hseg]

As far as I can tell, the problem is because the ubuntu and mac runs install cabal-install-3.14.0.0, whereas the windows run installs cabal-install-3.12.1.0 (the executable, not the library).
This means that Setup.hs for chs-cabal is given different and incompatible versions of Distribution.Simple to build with. I have no idea why I triggered this, though.
(this was joint detective work with @int-e on IRC)

[hseg]

I've been trying to write a bug report on this for cabal-install, but unfortunately I can't reproduce the working case -- building with ghc-9.8.4 and either cabal-install 3.10.3.0 or cabal-install 3.14.1.0 I still get the error. I've tried downgrading ghc, but I can't go all the way down to the 8.10.7 you use, because that doesn't yet have the LD fix. (Update: just setting LD=ld.bfd worked for that, might be able to make some progress)

[hseg]

🤦 think I've found the issue -- the revision putting an upper bound on chs-cabal was only posted on 2024-12-03T03:14:47Z, two days after the last index freeze on cabal.project

[hseg]

Am guessing there's no bug to report upstream

[hseg]

BTW, I incidentally bumped into https://discourse.haskell.org/t/don-t-edit-dependency-bounds-manually-with-this-ci-setup/5539 in investigating this, perhaps it's tooling that may be useful here?

[hseg]

Not sure what caused the segfault, and it lacks enough context to show me if I need to change something

[hasufell]

Not sure what caused the segfault, and it lacks enough context to show me if I need to change something

Armv7 is semi-busted and sometimes segfaults.

Need to consider dropping support. It's unlikely to be revived.

Anyhow, just restarting sometimes works.

[hseg]

I updated the description in view of the correct pushback that we already support ghc-9.8.4, and that this is more a PR to relax bounds to allow building under LTS-23.1