There is at least one

I understand @peti’s concern and to be fair, adding a line to preConfigure and creating a helper in lib sounds like a sensible idea.

The reason it's exposed as a flag to the generic builder is that cabal2nix (or any other tool using generic builder) could support hpack detection and enable the switch for packages that use hpack (for haksell development).

If we use the combinator approach we lose composability due to stringly-typed abstraction of preConfigure, etc.

This change adds two lines and introduces no recompilations.

This change adds two lines and introduces no recompilations.

Yes, it is true that the implementation is very straightforward. I'm not so much concerned by code complexity here but rather by "featureritis", i.e. we're adding specialized capabilities to our generic builder here that (a) Nixpkgs doesn't need and that (b) can be easily accomplished by other means. Therefore, I'd I would prefer not to commit to this API. It's just not necessary.

@domenkozar You are not the first to propose this change. :P

@domenkozar you are not the first to propose this change. :P

@domenkozar you are not the first to propose this change, I think I did at least once. :)

Huh, I seem to have made the last one (three) comments on a flaky internet connection. :)

I'd like to add how this is biting me, in slight hope that it changes our minds.

1. I'm using stack2nix which generates src = ./cachix/cachix-api;
2. I'm using stack for development, which when switching git branches, results into different cabal files
3. When using generated Nix expressions, Nix bails out with cachix-api.cabal was modified manually, please use --force to overwrite.

Probably best to discuss in cabal2nix.