-
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
bootstrapping 0.14.0rc1 requires network access #5202
Comments
https://github.com/google/desugar_jdk_libs is 5.7MB with |
For the second option: requiring the user adds a |
IIUC, having users add the http_archive rule will require users to have network access when building (any?) Android artifacts, is that realistic? Could you please point us to any background why needing network access for building Bazel is problematic? |
When building open-source software it is standard practice, especially when building binary packages, to first fetch the needed files and compare checksums, and then do the actual build in an offline fashion. Reasons for this include (among other reasons)
That is also how I discovered that network dependency; I was doing a test build for updating the bazel port for FreeBSD. Of course, for that I can work around it by listing the desugar-jdk library as another source archive needed, but it is still considered bad upstream packaging if a build does an unsolicited call out to the network. [A related feature request is #5175, so @vrothberg might also be interested in this discussion.] |
If I recall correctly, we based this decision on there already being 3 other We could move this dependency around so that the user has to add it to their workspace file (that is, we'd grab the dependency when the user builds their android target, instead of grabbing the dependency when we build bazel), but that's not a great user experience I think. It also means you couldn't do an offline android build without understanding where the dependency is coming from and knowing how to override it in your workspace file. The simplest solution is just to add the library to bazel. It's a size cost, but one that we're already sort of paying by embedding the library into bazel (now we just make it part of the codebase too). And this will all go away once we've moved the android rules to skylark and to a separate repository. |
Do we know which commit introduced the problem? |
I would guess bfd89d6. But a quick forward fix like https://bazel-review.googlesource.com/c/bazel/+/56490 is probably less pain than a rollback. |
I have a change in progress that puts the external dependency into bazel's repo under third_party. I'll send it out tomorrow. |
As opposed to earlier versions of bazel, bootstrapping bazel with
bash compile.sh
from the distribution artifact (as described in https://docs.bazel.build/versions/master/install-compile-source.html) requires network access. The reason is that//tools/android:embedded_tools
pulls in@desugar_jdk_libs
which is anhttp_archive
.Depending on our policy this may or may not block #5056, i.e. the 0.14.0 release.
Possible solutions include
The text was updated successfully, but these errors were encountered: