You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I agree with the comments on #3751 – cabal2nix shouldn’t keep growing as new ways to produce a Cabal file appear. It makes sense that the Cabal file is central, and some tools can produce Cabal files while others consume them. So I’m proposing the opposite.
There are two paths here, I think:
remove all “feature creep” (fetching from git, etc.), such that hpack - | cabal2nix (or hpack && cabal2nix) is sufficient for “hpack support”; or
keep those other pieces, and provide a generic preprocessor hook to run an arbitrary process, like cabal2nix --pre hpack or cabal2nix --pre dhall-hpack-cabal.
While the first option is ultimately simpler, I think it involves larger changes in downstream projects, so the second option seems much more practical.
I agree with the comments on #3751 – cabal2nix shouldn’t keep growing as new ways to produce a Cabal file appear. It makes sense that the Cabal file is central, and some tools can produce Cabal files while others consume them. So I’m proposing the opposite.
There are two paths here, I think:
hpack - | cabal2nix
(orhpack && cabal2nix
) is sufficient for “hpack support”; orcabal2nix --pre hpack
orcabal2nix --pre dhall-hpack-cabal
.While the first option is ultimately simpler, I think it involves larger changes in downstream projects, so the second option seems much more practical.
Footnotes
https://github.com/NixOS/cabal2nix/pull/375#pullrequestreview-153642460 and https://github.com/NixOS/cabal2nix/pull/375#issuecomment-431089214 ↩
The text was updated successfully, but these errors were encountered: