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

Allow workspaces to reference themselves canonically #1033

Closed
jart opened this issue Mar 11, 2016 · 7 comments
Closed

Allow workspaces to reference themselves canonically #1033

jart opened this issue Mar 11, 2016 · 7 comments
Labels
P2 We'll consider working on this in future. (Assignee optional) type: feature request

Comments

@jart
Copy link
Contributor

jart commented Mar 11, 2016

This is a blocking issue for the Closure Rules.

If I say:

workspace(name = "io_bazel_rules_closure")

Then I should be able to say within my workspace:

deps = ["@io_bazel_rules_closure//foo/bar"]

Which makes the codebase more copy/pasteable. But most importantly, I need to be able to say:

"_jschecker": attr.label(default=Label("@io_bazel_rules_closure//closure/compiler/jschecker"), executable=True)

Because otherwise the bzl rule will have no way to reference its own tooling. This is because a bzl rule exists in the namespace to which it's loaded. Without the ability to specify a fully canonical name, the rule will only work from other repositories. But if I run bazel test ... within the Closure rules repository, it will not be able to test itself.

CC: @damienmg

@damienmg damienmg added type: feature request P1 I'll work on this now. (Assignee required) External repositories P2 We'll consider working on this in future. (Assignee optional) and removed P1 I'll work on this now. (Assignee required) labels Mar 11, 2016
@damienmg
Copy link
Contributor

Hi Justine,

We decided this week to do be able to use the Label() function to refer to the repository containing the skylark extension. @kchodorow will work on that.

@kchodorow also work on a more principle ways to refer to external repository but that will take time.

@jart
Copy link
Contributor Author

jart commented Mar 11, 2016

Is there an estimated timeline for this functionality becoming available in Bazel head?

@bsilver8192
Copy link
Contributor

For reference, this sounds like it came out of the (fairly extensive) discussion in #975.

@kchodorow
Copy link
Contributor

Label("//foo") referring to the skylark rule's repo should be available this week, barring unforeseen issues on the code review.

@kchodorow
Copy link
Contributor

This is now committed (6f15335). The options are:

  • Label("//foo") refers to the Skylark file's repository.
  • Label("//foo", relative_to_caller_repository = True) refers to the repository the BUILD file is that's using the Skylark rule.
  • Label("@//foo") refers to the repository the build is happening from.

@brian-peloton
Copy link
Contributor

This is a different issue that still doesn't seem to be fixed. This bug is about "@io_bazel_rules_closure//:something" working from the closure repository itself. It definitely does not work in a build_file attribute with current Bazel master.

Once this is fixed, bazelbuild/rules_closure#9 will be easy to fix.

@brian-peloton
Copy link
Contributor

On second thought, this doesn't actually block anything any more. Just using default-repository labels should work fine... However, it would be still nice if referring to the main repository by name worked for consistency.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 We'll consider working on this in future. (Assignee optional) type: feature request
Projects
None yet
Development

No branches or pull requests

5 participants