-
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
Add support for isolated extension usages to the lockfile #18991
Conversation
@bazel-io flag |
@bazel-io fork 6.3.0 |
src/main/java/com/google/devtools/build/lib/bazel/bzlmod/GsonTypeAdapterUtil.java
Show resolved
Hide resolved
} | ||
|
||
@Override | ||
public ModuleExtensionId read(JsonReader jsonReader) throws IOException { | ||
if (jsonReader.peek() == JsonToken.BEGIN_OBJECT) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is quite a lot of code. could we simplify this by folding everything into a string, something like //abc.bzl%ext_name[%isolation_key]
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking about this as well, but then found this to be confusing in its own way as we would essentially concatenate a variable number of up to five distinct pieces of information into a single string. If you prefer it that way I can certainly implement it, I just slightly leaned towards the current solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually, we may have to concatenate everything here, since a ModuleExtensionId is used as a JSON object key for the extension map. I just remembered that this was why we had a concatenated string for ModuleExtensionId (instead of the normal JSON object representation) in the first place. But then again, your test passed... so I'm not quite sure what's happening here. I wonder what the lockfile actually looks like in that test case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of a map, it has a list of pairs, but that was the case already before my change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we explore going back to the regular object representation for everything?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure? With a simple local test case, this is what I see in the lockfile with Bazel HEAD:
"moduleExtensions": {
"//:ext.bzl%ext": {
"bzlTransitiveDigest": "X8hz9J00k/ncSFM8d3lFoFATXO4NhBFr5xuqfhWiRs0=",
"envVariables": {},
"generatedRepoSpecs": {
"kek": {
"bzlFile": "@@//:ext.bzl",
"ruleClassName": "rr",
"attributes": {"name":"--_main~ext~kek"}
}
}
}
}
EDIT: same with 6.3.0rc1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right. What's your preference? Strings, list of pairs or the current solution that's a max of both? Probably not the latter, I suppose.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually prefer the string version. It's terser, and IMO more human-readable, and human readability is a desirable property in the lockfile despite its main "audience" being Bazel itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In fact, I wanted to go a bit further and squash things like Starlark's Location into a string (so "abc.bzl:5:6"
instead of {"file":"abc.bzl","line":5,"column":6}
. But that would require bumping the lockfile version so I thought to do it later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, I can change this tomorrow.
Regarding compressing location: Wouldn't now be a good time given that lockfiles haven't been enabled by default in a release yet?
Previously, Bazel would crash if a module declares an isolated extension usage and the lockfile is used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice! I like this very much :)
' print("Name:", dep.name, ", Versions:", dep.versions)', | ||
'', | ||
'_dep = tag_class(attrs={"name": attr.string(), "versions":', | ||
' attr.string_list()})', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess there is no need for tags, environ and this printing code here
@@ -299,6 +299,55 @@ def testModuleExtension(self): | |||
) | |||
self.assertNotIn('Hello from the other side!', ''.join(stderr)) | |||
|
|||
def testIsolatedModuleExtension(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe another test to check changing "isolate" causes re-evaluation as it should be treated as a new different extension? Also, make sure that the previously saved one is removed?
self.ScratchFile( | ||
'MODULE.bazel', | ||
[ | ||
'lockfile_ext = use_extension("extension.bzl", "lockfile_ext", isolate = True)', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should test here that if we have two usages one isolated & one not this should result in two extensions in the lockfile?
@SalmaSamy The PR has already been merged, but I will submit another one with the changes and additions to the tests you proposed. |
@fmeum Thanks for that! |
Previously, Bazel would crash if a module declares an isolated extension usage and the lockfile is used. Closes bazelbuild#18991. PiperOrigin-RevId: 549631385 Change-Id: Id8e706991dc5053b2873847a62f5e0b777347c69
Previously, Bazel would crash if a module declares an isolated extension usage and the lockfile is used. Closes #18991. PiperOrigin-RevId: 549631385 Change-Id: Id8e706991dc5053b2873847a62f5e0b777347c69 Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>
Previously, Bazel would crash if a module declares an isolated extension usage and the lockfile is used.