-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
@
and @workspacename
considered different repositories
#3115
Comments
Change all internal load statements to absolute paths otherwise we end up with duplicate instances of the scripts, with thing like providers of the same name that don't match. This is a workaround for bazelbuild/bazel#3115
This is acutely annoying for providers, since it both breaks things, and gives bad diagnostics ("does not have mandatory providers Foo" even though it has "Foo", just a different foo). If it is difficult to fix, it might be worth at least failing-fast in the meantime, even if only for providers. |
@laurentlb this P1 will celebrate anniversary soon. |
Klaus, are you aware of this issue? |
FYI if it's a local and absolute path within the same repo ("//" vs ":") it doesn't reproduce, so I believe it has to be a repository-specific issue. |
Labels that include the repository name are still treated as different though, i.e., in the example above, This is an issue with rules and named providers. It's easy to get two incompatible copies of something with the same name. |
The question is then what to do with a bzl file in repo A which is needed
in both repositories A and B which *additionally* has a dependency on a
label inside A (for example a tool). We get invoked twice with different
strict deps outputs...
…On Fri, May 25, 2018 at 4:37 PM Jay Conrod ***@***.***> wrote:
Labels that include the repository name are still treated as different
though, i.e., in the example above, @scratch//:def.bzl is treated as
different from //:def.bzl, even they they refer to the same file.
This is an issue with rules and named providers. It's easy to get two
incompatible copies of something with the same name.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3115 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABUIF3sH2dscaqMbqtWwjqChNwDBlL8pks5t2AkggaJpZM4NukQk>
.
|
@ittaiz In rules_go, we work around this by always loading .bzl files using absolute labels that include the repo name. So we always load |
We also did that and it didn't solve the problem. I think since the label
that the bzl is dependent on gets loaded twice.
…On Fri, May 25, 2018 at 5:18 PM Jay Conrod ***@***.***> wrote:
@ittaiz <https://github.com/ittaiz> In rules_go, we work around this by
always loading .bzl files using absolute labels that include the repo name.
So we always load @io_bazel_rules_go//go:def.bzl even from inside the
repository.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3115 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABUIFxO9iMz2V9Il37skQ3OBavye6aBMks5t2BK0gaJpZM4NukQk>
.
|
Seems like this is a standard workaround: https://github.com/bazelbuild/bazel/issues/3115\#issuecomment-392072493
* BUILD: use absolute load statements Seems like this is a standard workaround: https://github.com/bazelbuild/bazel/issues/3115\#issuecomment-392072493
Two remarks.
Added @dkelmer, as this has to be considered as part of the label renaming project as well. |
@
and @workspacename
considered different repositories
A better way to demonstrate that
|
Adds a `provides` field to haskell_library and haskell_binary to tell users about our custom providers (and possibly throw better error messages). As a related change, the `load` targets for `providers.bzl` are made absolute to work around bazelbuild/bazel#3115
Adds a `provides` field to haskell_library and haskell_binary to tell users about our custom providers (and possibly throw better error messages). As a related change, the `load` targets for `providers.bzl` are made absolute to work around bazelbuild/bazel#3115
I'm still seeing these issues in Bazel 0.25.1. Was the |
@sergiocampama - yes, |
what about bazel/src/main/java/com/google/devtools/build/lib/packages/StarlarkSemanticsOptions.java Line 504 in 9a005f7
|
I'm seeing the exact provider missing error described in this issue in https://buildkite.com/bazel/rules-apple-darwin/builds/827#5ef4767f-56d7-48b6-a07e-992c9fa26db9 |
The flag is now It was scheduled to be flipped but there was missing functionality, and it was not made default in 0.26. See the tracking issue: #7130. |
Shouldn't this issue be open then until the incompatible flag is flipped? |
…kspace names (#613) bazelbuild/bazel#3115 GitOrigin-RevId: 32e685aa3cd32eae15938e9c0f6180ef4a19175c
@bazel_skylib. This works around not having flipped the --incompatible_remap_main_repo flag. If that gets done we can unwind this change. The exact problem we are working around is namespace resolution for providers which are global. Without the main repo remapping, we see the equivalent of '//StarlarkLibraryInfo' from within this library, but Stardoc sees '@bazel_skylib//StarlarkLibraryInfo'. bazelbuild/bazel#3115 bazelbuild/bazel#7130
Interestingly, the issue is not fully solved by (the current implementation of)
The first test passes, whereas the second fails in the build with remapping; interestingly enough, that command passes if we build |
#7130 is flipped now. |
@aehlig if there are test cases that are failing with the flag on, shouldn't they be fixed? |
@ittaiz Klaus is no longer working at Google or on Bazel. As far as I know there are open issues for a few related problems, if there are any more, can you file them separately? |
Didn't know that. Will do, thanks. |
The use of absolute labels in `load()` calls was a workaround for a Bazel bug[0] that was fixed in 2018, before the Bazel v1.0 release. Using either absolute or relative labels as appropriate makes it easier to understand whether a given load is expected to happen in the `@rules_m4` repository or in the root workspace. [0] bazelbuild/bazel#3115 GitOrigin-RevId: 7e5120adf89230c32569c6d9eb281123f1d48b54
Description of the problem / feature request / question:
Bazel evaluates the same Skylark file multiple times if it is loaded with a local path and an absolute path. This creates problems for rules, since everything gets defined twice. It is particularly problematic for named providers, since the duplicate definitions are neither equivalent nor compatible.
We ran into this issue when trying to migrate rules_go to use named providers. We load our .bzl files with local labels in our own repository, but repositories that depend on ours load using absolute labels, which causes errors.
Bazel should not evaluate the same .bzl file in the same repository more than once.
If possible, provide a minimal example to reproduce the problem:
Create an empty workspace with these files.
Run
bazel query //...
to evaluate the files. The message is printed twice.Environment info
bazel info release
): 0.5.0cc @ianthehat
The text was updated successfully, but these errors were encountered: