Handle external packages using CARGO_MANIFEST_DIR

[sitaktif]

No description provided.

[google-cla]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[illicitonion]

LGTM!

Looks like CI is failing because the root WORKSPACE doesn't have a definition for the hello_cargo_manifest_dir repository :)

[sitaktif]

Fixed!

[UebelAndre]

Why does this need to be a repository? And if it needs to be a repository, could it not be put into example_deps similar to how rules_proto was added to docs/docs_transitive_deps.bzl?
https://github.com/bazelbuild/rules_rust/blob/master/docs/docs_transitive_deps.bzl#L20-L31

[sitaktif]

Great questions!

It needs to be a repository because that's specifically the case we are testing: something that depends on an external target that uses the CARGO_MANIFEST_DIR environment variable. If the target is not external (ie. not in a separate repo) it won't reproduce the issue that this commit is fixing.

I can definitely put the deps in a separate bzl and will do so. Unfortunately I won't be able to reuse that .bzl file in examples/WORKSPACE because the path attribute has to be different, but it will still be a nice improvement to avoid polluting the root WORKSPACE 👍

[UebelAndre]

You could use a bool (is_top_level) similar to the snippet I sent you to toggle between the paths. Would that not be sufficient?

[sitaktif]

You're totally right, I should have read your comment more carefully. Amended as suggested!

[UebelAndre]

This should be

        maybe(
            native.local_repository,
            name = "hello_cargo_manifest_dir",
            path = "hello_cargo_manifest_dir",
        )

(Sorry if this is obvious, just trying to help 😅)

[sitaktif]

"just one small change, surely I can't mess that one up". Anyway, thanks for the help :-)

Unrelated, but I noticed that if you build from the examples/ dir (which creates all the examples/bazel-* directories, building from the root directory sometimes fails because of infinite recursion, as if the .bazelignore was ignored. I couldn't find how to fix the issue (the issue wasn't introduced in this commit though).

[UebelAndre]

Yeah... that's what happens when you have nested workspaces that depend on the root workspace like this. local_repository should ignore bazel output paths (or accept a pattern to ignore certain directories).

Hopefully Bazel's proposal for external dependencies resolves this. For now, you'll just have to make sure you bazel clean in ./examples. Or at least that's what I do... 😅

[sitaktif]

Ok I think we're good now :-)

[UebelAndre]

@sitaktif I know this is a bit late but I was wondering if you'd be willing to merge

examples
├── hello_cargo_manifest_dir
└── hello_uses_cargo_manifest_dir

to something like:

examples
└── manifest_dir
    ├── external_repo
    └── usage

Just as a way to bundle the two examples 😅

(obviously not major, just a drive-by thought)