Jesper Agdakx 🔸

For Haskell packages published on Hackage, do you prefer version bounds on dependencies to be narrower or wider?

narrow ~ “We have tested that the package builds with dependencies that fall in this range”

wide ~ “Things are very likely to break if you use a version outside of this range, but we haven’t necessarily tested every version in it”

Case in point, I’m considering for agda2hs whether to bump the bound on base to only include the versions we actually test on CI, or to also include older versions that might still work but aren’t currently tested.

#Haskell #hackage #packages #agda

Sep 24, 2024 at 1:14pmWeb
Show threadAtamert ÖlçgenSep 24, 2024
@jesper I'm reading your definition of `wide` and it's like the maintainer doesn't make any promises whatsoever.
Show threadJesper Agdakx 🔸Sep 24, 2024
@muhuk I mean, in this case the maintainer would make a *negative* promise that your build would not work if you go outside of the version bounds. It sounds like a weird thing to do, but in practice testing capacity is limited so it's simply not possible to test with every possible version of every dependency. So narrowing the bounds to only include tested versions might lead to some very awkward constraints downstream.
Show threadtrystimuliSep 24, 2024
@jesper if it is found non-working with an older version of base, would you accept a patch/push an update that would make it work?
Show threadJesper Agdakx 🔸Sep 24, 2024
@tryst It depends, if it's a simple fix I might but if it adds a lot of complexity then I'd rather just ask people to upgrade their GHC.
Show threadMartin EscardoSep 24, 2024

@jesper

Both?

If I have the versions you tested, I'll go with that.

If not, I'll try my luck.

Show threadJesper Agdakx 🔸Sep 24, 2024
@MartinEscardo Well I have to put a single range in the .cabal file, so the question is: do I keep a bound of base >= 4.13 even if CI is no longer testing that version, or do I update it to base >= 4.17?
Show threadMartin EscardoSep 24, 2024

@jesper

42.

Show threadJesper Agdakx 🔸Sep 24, 2024
@MartinEscardo Cabal has an option --allow-newer but not --allow-older afaik, so if I put the version bounds too high then I’m forcing people to either upgrade their GHC or manually edit the .cabal file, even if it’s very likely that the build would just work.
Show threadJaro ReindersSep 24, 2024
@jesper @MartinEscardo Apparently `--allow-older` does exist: https://cabal.readthedocs.io/en/3.4/cabal-project.html#cfg-field-allow-older
8. cabal.project Reference — Cabal 3.4.0.0 User's Guide

Show threadJesper Agdakx 🔸Sep 24, 2024
@jaror @MartinEscardo Okay that's actually a good argument for me to bump the bounds.
Show threadJoshua MoermanSep 24, 2024
@jesper Base also goes together with the GHC compiler itself. In this case 4.13 was shipped with GHC 8.8.1. If you know that you cannot support GHC 8.8.1 (maybe because of some extensions), you can maybe assume that the user has a more recent base.
Show threadJesper Agdakx 🔸Sep 24, 2024
@Joshua The problem is not that compilation with GHC 8.8.1 is broken, it's just that having CI running for every GHC version from 8.8 to 9.10 seems like overkill so we're just not testing it anymore.
Show threadsoaprootSep 24, 2024
@jesper @Joshua Maybe run CI on the oldest and newest versions that you think would work?
Show threadAnthony CowleySep 24, 2024
@jesper I prefer wide. I find patches or build modifiers needed to allow a working build to be frustrating barnacles on a project.
Show threadJoshua MoermanSep 24, 2024

@jesper I recently had a case of a package with too narrow bounds. Changing the cabal file of that package to widen the bounds, resolved the issue. (So they were narrow for no reason.) This frustrated me and now I'm inclined to prefer wider ranges.

In this case, it was actually about the upper bounds, i.e., the package didn't want to be build with a recent base. But my GHC did not support an older base.