Open shlevy opened 6 years ago
@peti I'm happy to take a look if you'd be interested in this? Do you know where the right place to look would be?
@peti ping
Well, I'd be perfectly happy to add support for non-Hackage packages into the generation process. I'm not sure how to accomplish that best. hackage2nix
needs
src
attribute to put into the generated Nix expression to fetch the sources during the buildto operate. So I reckon it's not just a matter of extending configuration-hackage2nix.yaml
since that can't contain the Cabal file. It could probably contain an URL from which the Cabal file can be downloaded, but that approach might complicate matters a bit since we have no control over those external resources and therefore might lose the ability to re-produce an older state.
For future reference: https://github.com/simonmar/ecosystem-proposals/blob/slurp/proposals/0000-slurp.rst
Hmm, seems like a git repo + rev could evaluate to effectively the same thing as callCabal2nix called on fetchFromGitHub, no? That would make the generated nix expressions reproducible as long as the git repo stays up (which is true for a large number of other packages).
It could. I am not particularly crazy about having to download a bunch of git repos when running hackage2nix
, though, especially since the program doesn't need any of those files other than the Cabal file. If those files live on Github (or some other gitweb-like thing), then we can download the Cabal file in a reliably versioned fashion ... but still, downloading things from the Internet to run that tool is not something I fancy.
Ah, fair point. I guess ultimately we'd want something like the hackage package index, that you only need to re-update when some new revision you haven't previously fetched is needed?
This would make packaging non-hackage packages, like haskell-ide-engine, easier, as well as preparing us for the not-impossible future where stackage itself contains non-hackage deps.