Add --allow-newer/older to Cabal / Setup.hs

[fgaz]

(move it from ConfigExFlags to ConfigFlags and use it both in Cabal and cabal-install)

This would make it easier for downstream distributions to surgically override the constraints in case they want to widen the bounds, eg. if they move faster than upstream

Originally from #7444 (comment)

Currently in nixpkgs, where we use Setup.hs for every package, we have only to option to ignore all or none of the bounds. More granularity would be great.

/cc @maralorn

[ulysses4ever]

The flags used to be with Setup but were removed, see #3581 #4527. The main argument was: "because stack doesn't need it (anymore)", which is far underwhelming in my opinion. It was requested several times since: #5407 #7859 (including for the sake of nix). Also, quoting Mikhail (in #3581):

I don't think removing it buys us that much. #3165 added ~100 lines total, and more than half of those were comments and tests.

I'd be in favor of reverting that decision.

[Mikolaj]

If it's needed, let the interested parties add and maintain it. Any objections?

[ulysses4ever]

Based on incoming PR #9016, I optimistically add this to the 3.12 project. Please, review the PR!

[andreabedini]

I wasn't aware of this discussion and I know I am late to the party. Since nixpkgs is mentioned as a usecase, I wonder if this is really necessary. @maralorn following on your comment linked above, could nixpkgs use --exact-configuration instead? or that does version range check anyway?

IMHO, I'd find it more natural if --exact-configuration would skip checking version ranges entirely ("do what you are told!").

A bit physosofically perhaps but I consider allow-newer and allow-older as options to influence the solver and there's no solver in Cabal, so I find it a bit unnatural to see those options in there.

Just my 2c, feel free to disagree with me ☺️

[ulysses4ever]

It is confusing to hear about (seemingly) solver-related options inside Cabal, when you think about it. I didn't think about it before…

[maralorn]

In Cabal allow-newer is not a solver option but a check option. Cabal does not do package resolution. It simply discovers present needed packages and passes them on to ghc. (It maybe be a bit smarter than that when there are multiple versions of the same dependency available. That I don't know. I guess it simply picks the first dependency which fulfills the version bounds.) In this step it checks whether the found configuration conforms with version bounds. We rely very much on that check step in nixpkgs. ~~and using exact-configuration would prevent the check from happening at all.~~ But we want to only opt-out of the check for specific bounds and not all of them. Am 13. Juni 2023 04:51:06 MESZ schrieb Artem Pelenitsyn ***@***.***>:

…

It _is_ confusing to hear about (seemingly) solver-related options inside `Cabal`, when you think about it. I didn't think about it before… -- Reply to this email directly or view it on GitHub: #7445 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[maralorn]

Wait, I mixed that up a little. I don't know whether exact-configuration performs the check, but we don't use it and it would not solve our problem.

[maralorn]

As a service to the reader here the documentation:

--exact-configuration

This changes Cabal to require every dependency be explicitly specified using --dependency, rather than use Cabal’s (very simple) dependency solver. This is useful for programmatic use of Cabal’s API, where you want to error if you didn’t specify enough --dependency flags.

[maralorn]

So yeah, I assume using that flag would disable the check.

So theoretically Cabal has a very simple solver, but in practice that is more or less simply a check whether installed packages match.

[chreekat]

#5407 (comment)

--exact-configuration seems to not be quite right here if as angerman notes in his link that automatic flag configuration is not performed when it is turned on.

The reason why this ticket [#5407] exists is that jailbreaking on nixos doesn't remove bounds on dependencies in conditionals because it can break automatic flag configuration.

[andreabedini]

I feel we are solving a haskell4nix problem here, but I have nothing against a flag to tell Cabal to not check dependency versions, if anything I am a bit hesitant about calling it with the same name as the cabal-install option.

(Off topic: I am bit puzzled, how is the install plan determined in haskell4nix?)

[maralorn]

I feel we are solving a haskell4nix problem here

Hard to argue with that, as this is obviously why I am investing the time to work on this. Nevertheless, even without Nix as a motivation, this seems like a sensible feature request. Also, Cabal is a library to support different Haskell build systems and Nix is the third most used Haskell build system in the community. (https://taylor.fausak.me/2022/11/18/haskell-survey-results/#s3q0)

if anything I am a bit hesitant about calling it with the same name as the cabal-install option.

Well, the way it is implemented in this PR, it is really the same option. It has the same behaviour. cabal-install exposes quite a few Cabal flags directly, this will just be another example of that. But maybe there is a good argument against this sharing, that I am not aware of?

(Off topic: I am bit puzzled, how is the install plan determined in haskell4nix?)

See the (short) subsections "Available package versions" and "Dependency resolution" in https://nixos.org/manual/nixpkgs/unstable/#haskell-available-packages.