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

chore: support removal of builtin providers #2274

Merged
merged 17 commits into from
Oct 8, 2024

Conversation

comius
Copy link
Contributor

@comius comius commented Oct 5, 2024

The builtin providers PyInfo, PyRuntimeInfo, and PyCcLinkParamsProvider are being removed,
which means Bazel throws an error while compiling bzl files if there is a reference to a
top-level symbol that doesn't exist anymore. For backwards compatibility, rules_python
consumes/produces these providers, so the symbols are used in various places.

To fix, use native.legacy_globals and Bazel version detection to conditionally emit
the symbols into @rules_python_internal. If they aren't present, they are reported
as None.

This mimics equivalent functionality in bazel_features; bazel_features isn't used because
it would require users to update their WORKSPACE to initialize some dependencies before
rules_python can perform its initialization.

Removal of the builtin symbols is controlled by --incompatible_autoload_externally
(which is in Bazel 8 and has been cherry-picked into earlier version). If the flag is
enabled with "@rules_python" or "-@rules_python" the providers are removed from Bazel.

Use bazel_features to detect if PyInfo is still present in Bazel and
stop using it, if it's not.

Bazel throws an error while compiling bzl files if there is a
reference to a top-level symbol that doesn't exist anymore.
bazel_features provide a mechanism that detects presence of top-level
symbols without throwing an exception. It either returns the symbol or None.

bazel_features support not only Bazel 8, but also older versions of
Bazel that have --incompatible_autoload_externally cherry-picked. If the
flag is enabled with "@rules_python" or "-@rules_python" the provider is
removed from Bazel.

Remove also PyRuntimeInfo and PyCcLinkParamsProvider.
@comius comius requested a review from f0rmiga as a code owner October 5, 2024 08:27
Copy link
Collaborator

@aignas aignas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am somewhat opposed to having a breaking change to our WORKSPACE users, but looking at the code I don't see a quick workaround for that.

I am wondering if there is a different way to achieve this? I looked at the repos that we actually need from bazel_features and it seems that under WORKSPACE there is no way to initialize them inside the py_repositories call. So there is definitely no way but to have this extra call done after py_repositories(). I think having bazel-features in the long term could be inevitable and could make the code cleaner, but the fact that all of the WORKSPACE users would need to do these additions is unfortunate.

That said, everyone should migrate to bzlmod anyway, so this could be a good push to do this. Any other opinions? We at least need a decent note in the CHANGELOG.md explaining the migration steps.

@rickeylev
Copy link
Collaborator

Is there a reason it can't go in internal_config_repo? I didn't fully trace what bazel_features is doing, but it looked like it was just generating code like:

globals = struct(
  PyInfo = getattr(getattr(native, "legacy_globals", None), "PyInfo", None)

That looks fairly simple to drop into python/private/internal_config_repo.bzl

@rickeylev
Copy link
Collaborator

I updated the rules_python_internal repo to do the globals detection and updated reexports.bzl.

I think its working? I think bazel@head still isn't quite ready, so wasn't able to fully test with autoloading enabled (got some undefined symbol errors for stuff in bazel_tools, but those were also present with the PR as it was before I made my modifications). I didn't have a chance to lookup how the autoloading flag works, either, so maybe I set it wrong.

I'm not sure I'll have time tonight to undo the py_repositories_deps() changes.

@rickeylev rickeylev changed the title feat: Conditionally remove builtin PyInfo and other providers chore: support Bazel 8 removal of builtin providers Oct 8, 2024
@rickeylev rickeylev changed the title chore: support Bazel 8 removal of builtin providers chore: support removal of builtin providers Oct 8, 2024
@rickeylev
Copy link
Collaborator

Ok, finished cleanup etc. I think this is good to go

@rickeylev rickeylev enabled auto-merge October 8, 2024 17:51
@rickeylev rickeylev added this pull request to the merge queue Oct 8, 2024
Merged via the queue into bazelbuild:main with commit 84ff577 Oct 8, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants