buildRustPackage: add darwin Security to buildInputs #95556
Conversation
ofborg
bot
added
6.topic: darwin
| buildInputs = buildInputs ++ stdenv.lib.optional stdenv.hostPlatform.isMinGW windows.pthreads; | ||
| buildInputs = buildInputs | ||
| ++ stdenv.lib.optional stdenv.hostPlatform.isMinGW windows.pthreads | ||
| ++ stdenv.lib.optional stdenv.hostPlatform.isDarwin darwin.apple_sdk.frameworks.Security; |
There was a problem hiding this comment.
Is it needed for the stdlib? @LnL7 usually prefers to have impure macOS dependencies on a per-package base.
There was a problem hiding this comment.
Sorry I don't understand, why is it acceptable for go and not for rust?
There was a problem hiding this comment.
I think in go is required by its standard library, but in rust is only specific crates which depend on Security. e.g. getrandom crate in shadowenv
There was a problem hiding this comment.
nixpkgs/pkgs/development/compilers/rust/rustc.nix
Lines 132 to 134 in 19a0b38
nixpkgs/pkgs/development/compilers/rust/cargo.nix
Lines 21 to 22 in 19a0b38
There was a problem hiding this comment.
Rust uses external crates, including rand:
https://github.com/rust-lang/rust/blob/9d38dc22e5d543b9c350dd48ac014135547e7953/Cargo.lock#L2478
So, it's not surprising that rustc and cargo require Security.
I don't think the standard library depends on Security. E.g. the skim derivation does not have Security in buildInputs and builds fine on Darwin.
There was a problem hiding this comment.
Not to import the discussion of #89563 here. But the underlying problem here is that buildRustPackage et al. do not properly define the crate dependency graph in Nix, so it is all or nothing. If dependent crates were also defined as Nix derivations (as e.g. buildRustCrate does), then we could just add the Security dependency to the small number of crates (rand etc.) that require it. In fact, we already have a bunch of these in defaultCrateOverrides:
https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/rust/default-crate-overrides.nix
This issue also resurfaces with other Rust crates that depend on a native library., it's just that they are not as widely used. E.g., from a quick grep we have ~90 buildRustPackage derivations (out of ~280) that use openssl.
Edit: removed the last paragraph, too opinionated ;).
Edit 2: sorry for repeating your point @LnL7, I didn't see your comment yet.
There was a problem hiding this comment.
Yes, buildRustPackage already has multiple issues. I don't see why Security is a hill to die on.
There was a problem hiding this comment.
So solutions like crate2nix mean that the darwin Security, etc inputs in packages is literally cruft?
We're adding it to packages knowing that it will be removed anyway?
There was a problem hiding this comment.
Yes,
buildRustPackagealready has multiple issues. I don't see whySecurityis a hill to die on.
I agree that it is very tedious, so perhaps we should be pragmatic about this particular case. It is not required by the Rust standard library, but that's because the standard library does not carry (proper) RNG support and most packages do need it anyway (or some transitive dependency).
There was a problem hiding this comment.
I'd like to continue with this but I don't know that I've got the time to see it through at the moment.
Apologies for my ranty comments, rereading them I probably come across harsher than I intended.
Same as #83472 for rust.
cc @Mic92 I'm not sure if this is the most correct way of doing this?
Starting with
Securityas it is the most commonly needed withbuildRustPackage.