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

Missing @@_builtins providers when using pinned toolchains #2114

Closed
tpasternak opened this issue Aug 9, 2024 · 2 comments · Fixed by #2116
Closed

Missing @@_builtins providers when using pinned toolchains #2114

tpasternak opened this issue Aug 9, 2024 · 2 comments · Fixed by #2116

Comments

@tpasternak
Copy link

🐞 bug report

Is this a regression?

probably not

Description

A clear and concise description of the problem...

🔬 Minimal Reproduction

Just use this repo:

     File: BUILD.bazel
   1 load("@python_versions//3.12:defs.bzl", "py_binary")
   2 #load("@rules_python//python:defs.bzl", "py_binary")
   3 
   4 py_binary(
   5     name = "main",
   6     srcs = ["main/main.py"],
   7 )

     File: MODULE.bazel
   1 bazel_dep(
   2     name = "rules_python",
   3     version = "0.34.0",
   4 )
   5 
   6 python = use_extension("@rules_python//python/extensions:python.bzl", "python")
   7 python.toolchain(
   8     python_version = "3.12",
   9 )
  10 use_repo(python, "python_versions")

     File: main/main.py   <EMPTY>

🔥 Exception or Error

The BUILD.bazel file contains two different load statements. Depending on which one is enabled, a different set of providers is exposed

When "@rules_python//python:defs.bzl" is on, you get

% bazelisk cquery --output=starlark --starlark:expr="providers(target).keys()" //:main
INFO: Analyzed target //:main (2 packages loaded, 4 targets configured).
INFO: Found 1 target...
["LicenseInfo", "InstrumentedFilesInfo", "RunEnvironmentInfo", "@@rules_python~//python/private/common:providers.bzl%PyRuntimeInfo", "@@_builtins//:common/python/providers.bzl%PyRuntimeInfo", "@@rules_python~//python/private/common:providers.bzl%PyCcLinkParamsProvider", "@@rules_python~//python/private/common:providers.bzl%PyInfo", "@@_builtins//:common/python/providers.bzl%PyInfo", "FileProvider", "FilesToRunProvider", "OutputGroupInfo"]
INFO: Elapsed time: 0.477s, Critical Path: 0.00s
INFO: 0 processes.
INFO: Build completed successfully, 0 total actions

on the other hand, when "@python_versions//3.12:defs.bzl" is, you get

% bazelisk cquery --output=starlark --starlark:expr="providers(target).keys()" //:main
INFO: Analyzed target //:main (63 packages loaded, 1010 targets configured).
INFO: Found 1 target...
["LicenseInfo", "@@rules_python~//python/private/common:providers.bzl%PyInfo", "@@rules_python~//python/private/common:providers.bzl%PyRuntimeInfo", "InstrumentedFilesInfo", "RunEnvironmentInfo", "FileProvider", "FilesToRunProvider", "OutputGroupInfo"]
INFO: Elapsed time: 0.492s, Critical Path: 0.00s
INFO: 0 processes.
INFO: Build completed successfully, 0 total actions

Unfortunately, the latter one doesn't contain "@@rules_python~//python/private/common:providers.bzl%PyInfo", hence in IntelliJ we can't recognize it as a python target.

Screen.Recording.2024-08-09.at.09.54.53.mov

🌍 Your Environment

Operating System:

  
Fedora
  

Output of bazel version:

  
7.2.1
  

Rules_python version:

  
0.34
  

Anything else relevant?
"@python_versions//3.12:defs.bzl" seems to provide an extra target, named //:_main` which contains the expected providers

@rickeylev
Copy link
Contributor

Thanks for the report.

This looks like an easy fix. When X.Y/defs.bzl is used, it's using the py_binary in python/config_settings/transition.bzl, which only includes one of the two PyInfo objects, giving preference to the non-builtin on. It's easy to make it forward along both.

However, the intellij plugin needs to be updated to handle the @rules_python provider. The @_builtins provider will be going away eventually. It should recognized both, giving preference to the @rules_python one.

@tpasternak
Copy link
Author

Thank you for fixing it so quickly! We're aware that built-in providers will no longer be available in Bazel 8. However now we plan to overcome this problem with the --incompatible_autoload_externally flag

cj81499 pushed a commit to cj81499/rules_python that referenced this issue Aug 12, 2024
…ers (bazelbuild#2116)

This makes the versioned rules return both the `@builtin` and
`@rules_python` provider
objects. This makes the versioned rules more compatible with the
non-versioned rules.

Fixes bazelbuild#2114
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 a pull request may close this issue.

2 participants