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.

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

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

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 ☺️

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

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.

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.

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.

#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.

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?)

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.