Any way to interoperate with cabal/cabal.project only users in haskell-template?

[ParetoOptimalDev]

RIght now if you have a cabal.project with a source-repository-package specified when using haskell-template you'll get an error about git not being found because cabal is trying to clone that source-repository-package as it doesn't have any mechanism to just trust Nix's.

One reason you might find yourself stuck interoperating with cabal.project is because you need to generate darwin binaries, which is not straight-forward to do on Nix at all because (it seems that) truly static binaries on OSX basically don't exist:

Back to cabal though, I believe the root of the issue is because of haskell/cabal#8434 (comment)

One workaround is to modify the cabal.project file and basically remove the source-repository-package before haskell Nix stuff starts like here:

input-output-hk/haskell.nix#1637 (comment)

Also related: input-output-hk/haskell.nix#1637

Edit: looks like I did a more in depth breakdown on this and survey of solutions at: haskell/cabal#8434 (comment)

[srid]

I think this can be done. It would involve finishing the cabal.project parser at https://github.com/srid/haskell-flake/tree/master/nix/haskell-parsers and then using that to parse and generate source overrides in Nix.

Is this additional feature/complexity worth adding to haskell-flake? That's the question to ask. Probably not, as I like to keep haskell-flake simple and as a thin module on top of what's in nixpkgs. People can just specify these sources as flake inputs and use them.

[ParetoOptimalDev]

Is this additional feature/complexity worth adding to haskell-flake? That's the question to ask. Probably not, as I like to keep haskell-flake simple and as a thin module on top of what's in nixpkgs. People can just specify these sources as flake inputs and use them.

That is what I was doing, until distributing a static OSX binary became necessary on systems where the user doesn't have Nix installed.

Maybe it's not worth it. The best counter-argument is you can't progressively adopt haskell-flake on a codebase because of this, you have to get buy-in for a full switch to nix flakes.

Whereas if you could adopt it progressively, you could be the guinea pig and work thorugh inevitable pain points you enounter moving over a complex code-base.

That said the cabal parser seems like a good amount of work and interoperating with cabal.project adds a good amount of complexity. I think it depends on whether you believe cabal.project should be the source of truth or flake.nix. If you believe cabal.project should be the source of truth then the added complexity is considered essential complexity.