-
Notifications
You must be signed in to change notification settings - Fork 432
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
Support local cargo dependencies outside of a workspace #1525
Labels
Comments
This looks like the same problem as google/cargo-raze#361, for reference. |
Are you sure that is a duplicate? This is about rust to rust dependencies, not C++ to rust |
Oops, my bad, edited the prior comment to avoid further confusion. I was confused about which project this issue is in, I was trying to refer to google/cargo-raze#361 which is the same problem for raze. |
criemen
added a commit
to github/codeql
that referenced
this issue
Feb 13, 2024
…or`. I investigated porting our ruby extractor build to bazel, and unfortunately, bazels `rules_rust` only support local dependencies inside a workspace, c.f. bazelbuild/rules_rust#1525. Therefore, to be able to build the ruby extractor with bazel, I had to move the `tree-sitter-extractor` project out of `shared/`, where it morally belongs, into the ruby extractor workspace. Alternatives considered: - Provide a symlink from inside the workspace into `shared/`. This is possible, but due to the poor symlink support on Windows, it'd make working with the entire codeql repo on Windows more difficult. Our internal developers all (have to) have developer mode enabled, so that we can use symlinks in Bazel, but all external contributers on Windows would presumably run into trouble while cloning the repo. Imo, that's not acceptable. - Fake an environment that looks like it's a workspace using advanced bazel magic. That's possible, but would make the build much harder to understand. In particular, bazel doesn't (easily) allow writing to the source tree, so this is not an easy/quick hack. It's important to me that the build system can be understood by non-bazel experts, so this isn't acceptable either. - Fix the upstream issue. I don't have a good enough understanding of the issue or the code to do that. - Drop the `Cargo.toml` for the ruby extractor, and model all dependencies only on the bazel side. This'd break IDE support, and the bazel<->cargo integration is actually quite good (besides its limitations), so I don't want to do that. Out of all these alternatives, moving the shared code into the ruby workspace seemed the least bad option. Note that this works, because we want to build the ruby language pack with bazel, but not the ql-for-ql one - for now, I don't see an advantage of porting that to bazel anyways, so it's okay that it's blocked from being ported to bazel right now. I'm happy to discuss this change and alternatives further. If we agree that this is the way forward, then this needs to be merged together with a simple corresponding change in the internal repo.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If you have a dependency on a local crate that isn't in the same workspace,
cargo-bazel
seems to fail with:My situation is almost identical to the multi-package example, but where there is a dependency between the packages, for example
pkg_a
has the following dependency:I know I could arrange these into a cargo workspace, but I would prefer not to if possible.
The text was updated successfully, but these errors were encountered: