-
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
bazel fetch does not fetch all deps #13847
Comments
@meteorcloudy @Wyverald Could you please triage this? |
Thanks for reporting! I can even reproduce the issue without using
It looks like fetch command failed to figure out the full dependencies of the target. Also, I found /cc @katre @oquenchil Do you know how the cc toolchain depends on |
Everything depends on The repository is defined by the I am surprised that the |
Ah, the fetch command does depend on the |
I am guessing that query doesn't evaluate the Try reverting the definition just for |
Nope, it doesn't work. |
Okay, I'm not sure what the difference is. You can do It looks from the error (the "External repository @local_config_platform not found and fetching repositories is disabled" message) that the |
I don't think this is the case, because the repository function for this repo was never triggered.
This will actually fetch the How does the cc toolchain depends on local_config_platform in the code? |
The error is coming during toolchain resolution, which runs for any rule that uses toolchains (not only cc rules). Toolchain resolution needs to read the target platform and all available execution platforms. The default target platform (and the default execution platform) is Essentially any configured target depends on Something is going wrong with executing the repository function for |
I'm struggling with the same issue but found a workaround that works for me, instead of bazel fetch ... I use bazel aquery "deps(...)": |
Ping - I just hit the same snag while attempting to use bazel in a packaging context (where it is typically not allowed to connect to the network). While the work-around with |
Still an issue. Happened to me while building bazel itself. You cannot I wonder is
The Maybe it is impossible to have a generic fetch, as some external dependencies may not even be available in some circumstances, like MacOS stuff being available only on their machines, or debian stuff only on debian machines. In that case, does it make sense to have See also googleapis/google-cloud-cpp#6140, |
Hello, We've re-implemented this feature with bzlmod, and the fetch --all functionality should now operate as intended, with the option to force-fetch if necessary. This update has already been incorporated into the latest Bazel version (head) and will be included in our upcoming release, version 7.0.0. For additional information, you can refer to our GitHub issue. We encourage you to give it a try and, should you encounter any issues, please don't hesitate to report them. Best regards |
Context: - Traditional query relies on the initial loading phase of the build, this lacks the context of build configurations (flags, select() logic), leading to potentially inaccurate or over-inclusive dependency listings. - cquery executes after the analysis phase, where Bazel has resolved configurations and determined how options influence target definitions. This allows cquery to provide the dependencies truly needed for a build under the current settings. Considering these differences, I'm updating fetch target logic to rely on cquery instead. This ensures that all necessary repositories are fetched for an offline build while avoiding potential over-fetching PiperOrigin-RevId: 611455579 Change-Id: I2a954476c06182fd9eb78ad86def7bd72f04074a # Conflicts: # src/main/java/com/google/devtools/build/lib/query2/cquery/ConfiguredTargetQueryEnvironment.java
Context: - Traditional query relies on the initial loading phase of the build, this lacks the context of build configurations (flags, select() logic), leading to potentially inaccurate or over-inclusive dependency listings. - cquery executes after the analysis phase, where Bazel has resolved configurations and determined how options influence target definitions. This allows cquery to provide the dependencies truly needed for a build under the current settings. Considering these differences, I'm updating fetch target logic to rely on cquery instead. This ensures that all necessary repositories are fetched for an offline build while avoiding potential over-fetching PiperOrigin-RevId: 611455579 Change-Id: I2a954476c06182fd9eb78ad86def7bd72f04074a
Context: - Traditional query relies on the initial loading phase of the build, this lacks the context of build configurations (flags, select() logic), leading to potentially inaccurate or over-inclusive dependency listings. - cquery executes after the analysis phase, where Bazel has resolved configurations and determined how options influence target definitions. This allows cquery to provide the dependencies truly needed for a build under the current settings. Considering these differences, I'm updating fetch target logic to rely on cquery instead. This ensures that all necessary repositories are fetched for an offline build while avoiding potential over-fetching PiperOrigin-RevId: 611455579 Change-Id: I2a954476c06182fd9eb78ad86def7bd72f04074a
Context: - Traditional query relies on the initial loading phase of the build, this lacks the context of build configurations (flags, select() logic), leading to potentially inaccurate or over-inclusive dependency listings. - cquery executes after the analysis phase, where Bazel has resolved configurations and determined how options influence target definitions. This allows cquery to provide the dependencies truly needed for a build under the current settings. Considering these differences, I'm updating fetch target logic to rely on cquery instead. This ensures that all necessary repositories are fetched for an offline build while avoiding potential over-fetching PiperOrigin-RevId: 611455579 Change-Id: I2a954476c06182fd9eb78ad86def7bd72f04074a
A fix for this issue has been included in Bazel 7.1.0 RC2. Please test out the release candidate and report any issues as soon as possible. |
Context: - Traditional query relies on the initial loading phase of the build, this lacks the context of build configurations (flags, select() logic), leading to potentially inaccurate or over-inclusive dependency listings. - cquery executes after the analysis phase, where Bazel has resolved configurations and determined how options influence target definitions. This allows cquery to provide the dependencies truly needed for a build under the current settings. Considering these differences, I'm updating fetch target logic to rely on cquery instead. This ensures that all necessary repositories are fetched for an offline build while avoiding potential over-fetching PiperOrigin-RevId: 611455579 Change-Id: I2a954476c06182fd9eb78ad86def7bd72f04074a
Description of the problem / feature request:
bazel fetch ...
does not fetch all the deps needed to build...
with--nofetch
. In order forbazel build --nofetch ...
to work, I must explicitly list a number of rules that appear to be implementation details about bazel, likebazel fetch ... @local_config_platform//... @local_config_sh//... @local_config_cc_toolchains//... @rules_java//...
Feature requests: what underlying problem are you trying to solve with this feature?
bazel fetch ...
should fetch everything necessary to runbazel build --nofetch ...
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Here's a simple repro:
What operating system are you running Bazel on?
Debian GNU/Linux rodete
What's the output of
bazel info release
?release 4.1.0
If
bazel info release
returns "development version" or "(@non-git)", tell us how you built Bazel.NA
What's the output of
git remote get-url origin ; git rev-parse master ; git rev-parse HEAD
?NA
Have you found anything relevant by searching the web?
Nope
Any other information, logs, or outputs that you want to share?
Nope
The text was updated successfully, but these errors were encountered: