Should probably run with strictDeps = true

[dpc]

It is very easy to trigger needless rebuilds of dependencies between multiple cargo inheritance steps, by just introducing seamingly unrelated binary, only because by default mkDerivation seems to make dependencies of your build inputs also available in the derivation.

So I had a one off test, imported some extra binary in nativeBuildInputs just for that one step, and I see openssl-sys and downstream crates are rebuilding because of that. Turns out that binary was using a some library which is them being added to PKG_CONFIG_PATH, which makes build.rs of openssl-sys want to rebuild. Tricky to debug.

I was told on NixOS Matrix channel that using strictDeps = true; is generally a good idea, so I'm going to do just that, but crane could do that by default, given how it is used. Might save some users lots of trouble, at the minor cost of having to list all direct build inputs.

[ipetkov]

Haven't used it myself before, what are the impacts of setting strictDeps? I'm assuming it will change what things are actually set in the various environment variables, but I'm not fully certain whether that might "break" existing derivations

FWIW adding a new nativeBuildInput will cause a rebuild anyway (since that input will show up as an environment variable to the derivation), though not including it in the pkg-config variables would avoid potentially invalidating build-script caches

[dpc]

I'm assuming it will change what things are actually set in the various environment variables

I'm not entirely sure. I've found:

StrictDeps enforces desirable properties like outputs not retaining references to build tools. It also prevents mistakes that break cross-compilation.

It seems to me that without it Nix mkDerivation's infers some inputs transitively.

FWIW adding a new nativeBuildInput will cause a rebuild anyway (since that input will show up as an environment variable to the derivation

Yes, but it will not trigger cargo rebuilding already built dependencies, which right now does happen. E.g. I build the whole workspace, inherit the resulting ./target into a test where I import some binary, and bam, I see the workspace being rebuilt again by cargo test only because that binary changed PKG_CONFIG_PATH for some reason.

whether that might "break" existing derivations

It does. I started using it and had to move certain things between buildInputs and nativeBuildInputs (pkg-config has to be in nativeBuildInputs or cargo will not find stuff). It worked just fine previously.

[ipetkov]

Although I do agree that strictDeps is probably desirable to always have on going forward, I worry that this is a departure from being a thin wrapper around mkDerivation (i.e. I worry people will be confused why stuff doesn't work with mkCargoDerivation). Though maybe we could highlight it in all the examples as a start 🤔

[dpc]

I think you're right. It is confusing, especially when it happens implicitly.