jtojnar / nixpkgs-hammering

Beat your package expressions into a shape
MIT License
241 stars 15 forks source link

Add to nixpkgs #122

Closed figsoda closed 1 year ago

figsoda commented 2 years ago

Any reason this is not in nixpkgs?

jtojnar commented 2 years 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.

winterqt commented 1 year ago

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.)

jtojnar commented 1 year ago

@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.

winterqt commented 1 year ago

@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?

jtojnar commented 1 year ago

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.

mweinelt commented 1 year ago

Naersk usage was removed in #134. Is there a chance to revisit the topic?

figsoda commented 1 year ago

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

jtojnar commented 1 year ago

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.

figsoda commented 1 year ago

https://github.com/NixOS/nixpkgs/pull/211958