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

Rename canonical workspace to @rules_python #203

Closed
brandjon opened this issue Jul 19, 2019 · 3 comments · Fixed by #212
Closed

Rename canonical workspace to @rules_python #203

brandjon opened this issue Jul 19, 2019 · 3 comments · Fixed by #212
Assignees

Comments

@brandjon
Copy link
Member

The canonical workspace name -- i.e. the name appearing in the workspace() declaration, documentation, examples, and code -- is currently @io_bazel_rules_python. We should change this to @rules_python for consistency with @rules_cc, @rules_java, etc.

This reflects how this repository is (or ought to be) the canonical home for all things Python in Bazel, and is especially important in light of bazelbuild/bazel#8893. As part of that work, Bazel itself may begin to assume that the core Python rules (py_binary, etc.) are available under a @rules_python repo.

@brandjon
Copy link
Member Author

For more rationale see here.

@johnynek
Copy link
Member

I think this is unfortunate.

DNS based names, a-la java have been used elsewhere. I think continuing that is the only sure-fire collision avoidance.

Name collision avoidance is worth it IMO.

@brandjon
Copy link
Member Author

Ideally it should be possible to remap the names of dependencies and transitive dependencies, so that name collisions can be handled. This works to some extent but is broken in rules_python's case because the generated pypi repos hard code the @rules_python identifier. In principle if we parameterize that identifier then users can get around name conflicts involving rules_python.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants