Skip to content
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

Open
cameron-martin opened this issue Aug 20, 2022 · 3 comments
Open

Support local cargo dependencies outside of a workspace #1525

cameron-martin opened this issue Aug 20, 2022 · 3 comments

Comments

@cameron-martin
Copy link
Contributor

If you have a dependency on a local crate that isn't in the same workspace, cargo-bazel seems to fail with:

error: failed to load manifest for dependency `foo`

Caused by:
  failed to read `/foo/Cargo.toml`

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:

pkg_b = { path = "../sub_pkgs/pkg_b" }

I know I could arrange these into a cargo workspace, but I would prefer not to if possible.

@bsilver8192
Copy link
Contributor

bsilver8192 commented Sep 16, 2022

This looks like the same problem as google/cargo-raze#361, for reference.

@cameron-martin
Copy link
Contributor Author

cameron-martin commented Sep 17, 2022

Are you sure that is a duplicate? This is about rust to rust dependencies, not C++ to rust

@bsilver8192
Copy link
Contributor

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
Projects
None yet
Development

No branches or pull requests

3 participants