-
Notifications
You must be signed in to change notification settings - Fork 435
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Example of local path crate dependency? #2961
Comments
@sthornington I had to symlink external directories into the workspace to get it to work for me. |
But they are still crates and lacking BUILD files? I haven't even been able to get this working... cargo-bazel gives some sort of splicing error. What version of rules_rust are you on? |
I can't even figure out how to get |
I narrowed my problem down to this code: https://github.com/bazelbuild/rules_rust/blob/main/crate_universe/src/splicing/splicer.rs#L617-L621 ... it works if I just cut that out and evaluate to false. I'm happy to submit a PR for that change, but it would be helpful to know why that logic is there in the first place ...? @illicitonion any ideas? |
Never mind, that was insufficient, getting |
I have no idea how this is supposed to work, what would it put into |
@illicitonion sorry to ping you on this - hypothetically, is getting this to work something I could sponsor you or someone to do? I do a lot of co-iteration on crates and bazel projects which depend on them, so it would be very convenient to be able to change a |
Hi @sthornington - certainly happy to discuss how we can get this working :) There are a few levels of support I can imagine here - can we establish exactly what you're needing? At the simplest end, I am imagining basically just dropping in a replacement for the repo right at the end of any other work. So we'd do any resolving, generating, and such using the released upstream metadata, and then just replace one of the crates with a local directory. Basically equivalent to At the most fully-featured end, I can imagine wanting to factor the locally forked Cargo.toml file in when resolving. This would allow the forked Cargo.toml file to e.g. force extra dependencies to be resolved, change versions that get resolved, etc. All of these things are possible, but if you're really just looking to support the "one-off edit/debug" use-case with no dependency changes, we can probably get away with a lot less complexity than the "fully treat local crates the same as published ones" feature. |
I had imagined that a path-local crate would be treated as it is in cargo - it could pull new dependencies (i.e. if necessary trigger a re-pin), so I think it makes sense for it to be noticed ahead of hashing/splicing. If I were to attempt this myself, it looked at a glance like a new SourceAnnotation or something would be necessary and some sort of replacement for semver and URL to identify changes would be necessary? I only looked for maybe 10 minutes. If I understand correctly, that is closer to your second proposal...? |
Yeah, that sounds reasonable. I'll do a little thinking about how I imagine this looking (and how much work it would be) and get back to you. |
Thanks! |
Does anyone have a working example of a cargo crate dependency in a crate_universe which is referred to by path on disk? Or any way to depend upon a local copy of a crate that you are actively working on?
I am having terrible trouble actively iterating on crates that I depend upon alongside a Bazel workspace that uses them...
The text was updated successfully, but these errors were encountered: