Make update-deps.py generate bzlmod-compatible output#5691
Conversation
|
The generated output of |
79a8e25 to
66356e2
Compare
build/deps/gen/build_deps/dep_clang_tidy_darwin_arm64.MODULE.bazel
Outdated
Show resolved
Hide resolved
fhanau
left a comment
There was a problem hiding this comment.
Thank you, this looks like it mostly solves our bzlmod auto-update conundrum.
I believe the PR description is partially obsolete since this is sufficient to have auto-updates for bzlmod dependencies, as long as we specify them in json (which works with some of the most important ones like bzlmod). For things already in MODULE.bazel, we could move them back to bzlmod, or implement an improved update mechanism to support them directly, but both should be done in a separate PR.
You should manually delete the old *.bzl auto-generated files since the script no longer cleans them up after this, but otherwise this LGTM.
|
Marking as "ready to review" as there's only a couple of minor things left to fix then we can land this. |
Still LGTM, just need to address the remaining comments. |
b096d19 to
18ba84e
Compare
|
I also have to port over the internal repo before we can merge this |
0390949 to
ec57240
Compare
ec57240 to
62cbffc
Compare
76f5cbf to
158af70
Compare
|
CI is slower than a sloth on ambien, but I swear I'm merging this |
What this PR does:
What we can get Claude to do for us:
To make it easier for our robot buddy to do this, I've added an unused function called
get_bcr_versionthat I wrote back in August, as a starting point.With these two elements added, we can add all of our dependency management workflows as of today.
Not addressed in this PR: our "shared_deps" system where the same version is used in edgeworker and workerd needs to be redone. With bzlmod we cannot load these things across repos, though I suspect we can with symlinks. We might need some help here. At worst we can just break the link between these versions and manage them independently.
Future work: I am still not sure if we want this, but it's certainly doable: Instead of using the separate
jsoncfiles and generating Bazel code, we could parse theMODULE.bazelfiles. The potential advantages are a bit less conceptual complexity and getting ready forrenovatewhen DEVTOOLS makes it available on GitHub. This can be figured out later and doesn't block any of this work.