callCabal2nix: take "name" parameter as a function argument #22469
Conversation
The callCabal2nix function cannot reliably determine the appropriate "name" for
the package it's processing. Attempts to derive this information have led to
plenty of evaluation errors, and so I'd like to go for the obvious and reliable
solution now and let the caller specify that bit of information.
Here is an example that demonstrates how to use callCabal2nix.
let
pkgs = import <nixpkgs> {};
src = pkgs.fetchFromGitHub {
owner = "gtk2hs";
repo = "gtk2hs";
rev = "eee61d84edf1dd44f8d380d7d7cae2405de50124";
sha256 = "12i53grimni0dyjqjydl120z5amcn668w4pfhl8dxscjh4a0l5nb";
};
in
pkgs.haskellPackages.callCabal2nix "gtkhs-tools" "${src}/tools" {}
|
@peti another alternative here is just hardcoding the name to be Also, on a related note, I was about to send this a pull-request with this commit, which solves this issue and does some other things as well. What do you think? k0001@aaca094 |
I have mixed feelings about that. One one hand, I realize that the name is probably not very meaningful and that we can use any random string and it would make no difference for 99% of all cases. On the other hand, I am unhappy about using a generic, non-descript name for many store paths generated by that function, because there may be occasions where this limitation will cause headaches for people who have such a store path and want to figure out what it is and where it comes from (i.e. because they're debugging a broken store or they're looking at the contents of a closure or whatever other use-case that I can't think of right now). To me, it feels wrong to call these things "src". I can't quite pin-point why that is. The extra effort of specifying the derivation name explicitly seems well worth it if I get accurately named store paths out it. I also feel like there's a nice symmetry in the APIs and There's something that looks consistent about that API. |
|
@peti ok, sounds good, I agree with this. The similarity between |
|
Go for it. |
The callCabal2nix function cannot reliably determine the appropriate "name" for
the package it's processing. Attempts to derive this information have led to
plenty of evaluation errors, and so I'd like to go for the obvious and reliable
solution now and let the caller specify that bit of information.
Here is an example that demonstrates how to use callCabal2nix.