HEADS UP: deprecation of native {http,git}_archive
Klaus Aehlig
Hallo everybody,
we're planning to submit https://bazel-review.googlesource.com/c/bazel/+/55932
soon, preferably even before the cut of bazel 0.15.0. This will switch
the default value of the --incompatible_remove_native_{git_repository,http_archive}
flags; in other words, by default bazel will insist that the skylark
versions of those rules be used and refuse usage of the native rules.
The native versions are still available by explicitly setting those
flags to false, and we intend to keep the flags available for at least
6 months.
As can be seen from the cited commit, the transition is pretty mechanical,
as the Skylark implementation is feature complete with respect to the
native rules. In fact, the Skylark versions additionally support
- shallow clones for git, and
- series patches as well as programatic transformations of the downloaded
repsository (both, git and http archives).
This is part of our ongoing effort to switch from native to Skylark
repository rules. It just isn't feasible to bundle each and every version
control system in bazel; also, experience has shown that we aren't even
good in keeping the bundled version control systems up to date. So
calling the ambient binaries should also allow to get benefits from new
versions quicker.
Therefore, we encourage everybody to convert their repositories to
switch to the Skylark rules at their earliest convenience. If there are
any concerns about that flag flip or its timing, please let us know as
soon as possible.
Thanks,
Klaus
--
Klaus Aehlig
Google Germany GmbH, Erika-Mann-Str. 33, 80636 Muenchen
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschaeftsfuehrer: Paul Terence Manicle, Halimah DeLaine Prado
Klaus Aehlig
Additional information on how to transition can, as for all backwards-incompatible
changes, be found on the respective part of the Skylark documentation; in this
case on
https://docs.bazel.build/versions/master/skylark/backward-compatibility.html#remove-native-git-repository
Also, to allow more time for the transition, the mentioned change will not
be submitted before the 0.15.0 release is cut. Still, please adapt your repositories
to this upcoming change.
david.o...@gmail.com
> > we're planning to submit https://bazel-review.googlesource.com/c/bazel/+/55932
> > soon [...]
>
> Additional information on how to transition can, as for all backwards-incompatible
> changes, be found on the respective part of the Skylark documentation; in this
> case on
>
> https://docs.bazel.build/versions/master/skylark/backward-compatibility.html#remove-native-git-repository
Thanks. I've found this statement:
The Skylark http_archive is also a drop-in replacement for the native new_http_archive (with the same proviso).
to be very helpful.
> Also, to allow more time for the transition, the mentioned change will not
> be submitted before the 0.15.0 release is cut. Still, please adapt your repositories
> to this upcoming change.
It seems not as straight forward as expected.
I tried to switch gerrit code review to consume
Skylark based {http,git}_archive rules. It turns
out, that we cannot fix that "ourself" only, but
also depends on other projects, most notably
rules_closure.
I've sent that PR: [1]. But let assume, this PR is
not merged at the time when 0.16.0 version is
released, that deprecates native rules. Now what?
a) freeze Bazel version at 0.15.0 on our side
b) add --incompatible_remove_native_{git_repository,http_archive}
to tools/bazel.rc in gerrit tree, and hope that rules_closure
switched to the Skylark rules before support for --incompatible...
option is removed from Bazel
c) fork rules_closure with [1] applied
...
Klaus Aehlig
> Skylark based {http,git}_archive rules. It turns
> out, that we cannot fix that "ourself" only, but
> also depends on other projects, most notably
> rules_closure.
>
> I've sent that PR: [1].
> But let assume, this PR is
> not merged at the time when 0.16.0 version is
> released, that deprecates native rules. Now what?
>
> a) freeze Bazel version at 0.15.0 on our side
> b) add --incompatible_remove_native_{git_repository,http_archive}
> to tools/bazel.rc in gerrit tree, and hope that rules_closure
> switched to the Skylark rules before support for --incompatible...
> option is removed from Bazel
> c) fork rules_closure with [1] applied
> ...
the flag available for at least have a year.
Depending on how you import rules_closure, there might also be
option "(c') patch on import" using the patches or patch_cmds
attributes of the skylark http_archive and git_respository rules.
Best regards,
david.o...@gmail.com
> > I tried to switch gerrit code review to consume
> > Skylark based {http,git}_archive rules. It turns
> > out, that we cannot fix that "ourself" only, but
> > also depends on other projects, most notably
> > rules_closure.
> >
> > I've sent that PR: [1].
>
> Thanks for sending the PR.
>
> > But let assume, this PR is
> > not merged at the time when 0.16.0 version is
> > released, that deprecates native rules. Now what?
> >
> > a) freeze Bazel version at 0.15.0 on our side
> > b) add --incompatible_remove_native_{git_repository,http_archive}
> > to tools/bazel.rc in gerrit tree, and hope that rules_closure
> > switched to the Skylark rules before support for --incompatible...
> > option is removed from Bazel
> > c) fork rules_closure with [1] applied
> > ...
>
> (b) certainly is a valid option and, as emntioned, we will keep
> the flag available for at least have a year.
OK.
> Depending on how you import rules_closure, there might also be
> option "(c') patch on import" using the patches or patch_cmds
> attributes of the skylark http_archive and git_respository rules.
Ah, I missed that feature in Skylark http_archive rule.
Untill now, it was rather cumbersome to patch third
party dependencies. I will look into doing it in this
non-intrusive way. Thanks.
david.o...@gmail.com
It works as advertised: [1]. Patching third party dependency,
rules_closure in our case, "patch on import" is very impressive
feature, thanks so much for adding it!
Things I've noticed during migration:
1. I'm seeing some left over debug print statements
that could probably be removed:
DEBUG: /home/davido/.cache/bazel/_bazel_davido/5c01f4f713b675540b8b424c5c647f63/external/bazel_tools/tools/build_defs/repo/http.bzl:46:5: patch file //:0001-Replace-native-http-git-_archive-with-Skylark-rules.patch, path /home/davido/projects/gerrit2/0001-Replace-native-http-git-_archive-with-Skylark-rules.patch
2. http_file Skylark variant is not a drop in replacement for
native http_file rule, unfortunately. The provided file name is
now hard coded to always be "downloaded": [2]. So in our case,
native http_file was previously "polymer_closure.js". To satisfy
the follow-up processing (closure compiler) we have to add an
intermediate steps to rename "downloaded" to required file
with ".js" suffix: [3]. This could be probably improved.
[1] https://gerrit-review.googlesource.com/c/gerrit/+/182491
[2] https://github.com/bazelbuild/bazel/blob/master/tools/build_defs/repo/http.bzl#L77
[3] http://paste.openstack.org/show/722557
