crane ignore sourceRoot for given sources

[TheNeikos]

Describe the bug
When setting sourceRoot it does not take it into account when trying to find what the 'actual' package is when building the dummySrc and determining the Cargo.toml and Cargo.lock.

Reproduction

I set up a quick repository to showcase it: https://git.hemera.systems/Hemera/crane-reproducer-workspace-sourceRoot

In my opinion, this should work, as I am telling crane what subset of the source the 'building' should happen in.

When manually setting the cargoToml and cargoLock options it works. So I think it is the auto-finding that has an issue maybe?

[ipetkov]

Hi @TheNeikos thanks for the report and the reproduction!

I do agree that it would be nice to support this a bit better than we do today (and there might be a few things we can try to make this smoother), the difficult bit is the impedance mismatch between the fact that vendoring happens "at evaluation time" (i.e. we have Nix code searching for Cargo.lock files and generating the derivations to pull and unpack the crates) and that sourceRoot/setSourceRoot are geared towards build time (i.e. bash code running in the sandbox and materializing the build).

For simple cases we may be able to better support sourceRoot (e.g. if we see it present, and its a relative path, and it starts with the same path component as the source derivation's name, we can peek at src + (stripSourcePrefix sourceRoot) + "/Cargo.lock" instead of src + "/Cargo.lock") and hope that's enough. But we'll never be able to support setSourceRoot (which is meant to be arbitrary bash logic that can do anything up until returning the source root) fwiw.

In the mean time there's a couple of ideas I can suggest:

• explicitly set the path to the Cargo.lock like you mentioned
• structure things in a way where Cargo.lock is at the root of src (or specify a subdirectory of what is currently src)
• explicitly set cargoVendorDir = craneLib.vendorCargoDeps commonArgs // { src = ./subdir/that/actually/has/Cargo.lock; }

[TheNeikos]

Yeah I agree, arbitrary paths might be problematic. Easy for me of course to say that the simple case would suffice for me, but while I do understand the individual parts you mention I don’t know what the actual effort is here.

The work around is good enough for me, and maybe just a mention somewhere (like this issue?) might be enough. Or maybe a warning trace, but that might be too noisy?

I was mostly very surprised that the wrong sources were being used and then errors were nonsense.

[ipetkov]

I don’t know what the actual effort is here

At the very least, the effort would be to edit lib/vendorCargoDeps.nix and emit some warnings if either sourceRoot or setSourceRoot is defined in args.

Then the effort depends on how thorough one would want to get with trying to handle what's possible and avoiding edge cases as mentioned above! Don't have a lot of time to dig into an implementation myself, but happy to review any PRs on the topic (even if its to emit some warnings here)