Closed figsoda closed 1 year ago
Initially, I was too lazy, especially since flakes make it really convenient to use it even outside nixpkgs.
And now we depend on naersk for the Rust part, which cannot be used in nixpkgs. It should be possible to use Nixpkgs’s Rust infrastructure in Nixpkgs but we would have to deal with plumbing it into the Python part and it is too much for me at the moment. (Porting the Python part to Rust would make it nicer.)
Also the project is currently not versioned.
And now we depend on naersk for the Rust part, which cannot be used in nixpkgs.
Somewhat off-topic question, but is there a technical reason why Naersk can't be used in Nixpkgs other than the fact that it's not used for any package in Nixpkgs? Like, could it theoretically be used if all packages were switched to it, or is there some limitation which prevents this? (I'm not proposing that we switch, I'm just curious if there's a reason we couldn't.)
@winterqt Naersk requires Cargo.lock
and Cargo.toml
files so we would either need to use IFD, which is currently not allowed in Nixpkgs, or copy the files into Nixpkgs.
@jtojnar Naersk promotes no IFD in its description, is that only true if you manually specify the Cargo.toml
and Cargo.lock
paths? (It would still be IFD if it's a local source (not a fetcher), but derivations like that aren't in Nixpkgs so... I guess it still has IFD?)
I skimmed the Naersk source and I don't see any (obvious) instances of IFD -- when would we use IFD, then? Either we use the Cargo.toml
and Cargo.lock
from the source, or we make our own and include it in Nixpkgs, the same as we currently do with Nixpkgs' Rust build infra. Or am I misunderstanding something?
I think that just refers to this: https://github.com/nix-community/naersk/pull/4 Before having TOML parser in Nix, you needed IFD even just to load the dependency data.
Accessing local files does not require a derivation so it does not constitute IFD. But if you only have the TOML files inside FOD, you obviously cannot get around IFD for this kind of builder. That’s why in Nixpkgs you either commit the lockfile or wrap the whole dependency tree in a FOD.
If you have more questions, moving to Discourse or Matrix would probably be more suitable.
Naersk usage was removed in #134. Is there a chance to revisit the topic?
I took a look at flake.nix
and looks like the only thing that wouldn't work in nixpkgs would be this
https://github.com/jtojnar/nixpkgs-hammering/blob/1b038ef38fececb39b65a4cdfa7273ed9d9359b4/flake.nix#L34-L37
We can either manually keep a list in nixpkgs or change the logic nixpkgs-hammer uses, e.g. have it read from its libexec and symlink ${rust-checks}/bin
to $out/libexec
That logic does not really need to be done in eval time. Converting it to bash would make it only slightly uglier.
If someone is up to packaging this, feel free.
Any reason this is not in nixpkgs?