V2 lock file format #822
V2 lock file format #822
Conversation
shs96c
force-pushed
the
v2-lock-file-format
branch
from
113edd5
to
c77db95
Compare
|
|
||
| exports_files([ | ||
| "hasher_deploy.jar", # built from //private/tools/java:hasher_deploy.jar | ||
| "list_packages_deploy.jar", # build from //private/tools/java/rules/jvm/external/jar:ListPackages_deploy.jar | ||
| "hasher_deploy.jar", # built from //private/tools/java/rules/jvm/external:hasher-tool_deploy.jar |
There was a problem hiding this comment.
Do you know if we can use buildkite to create these jars on each CI build? Then at least we'd have non-local dev builds.
There was a problem hiding this comment.
I'm not sure. We'd also (presumably) want buildkite to update the PR or fail the build if these change....
There was a problem hiding this comment.
Yeah that could work too. Mind adding a test?
|
Simon, can you given an example for the new lockfile format? |
|
@meisterT the diffs contain the newly generated json lockfiles. |
|
Thanks Jin, github didn't load it by default and so I missed it. Is the summary of the new format to reduce nesting? |
|
The fundamental goal is to have a lock file format that's easier to review by humans (eg. in PR reviews) A secondary goal is to make the build file more compact, but that's really just a nice benefit. FWIW, I created a small diff to demonstrate what an update might look like. This is bumping the guava version. |
You achieved this goal by avoiding nesting or are there other things to consider?
That looks very easy to review indeed! |
The existing lock file contains a lot of duplicate information, the main thing being that there are not only the direct dependencies listed in one property, but also all the transitive dependencies, in each and every dependency. By removing that duplication, the file gets a lot smaller (particularly in regular projects --- the examples in the |
shs96c
force-pushed
the
v2-lock-file-format
branch
from
3f6a580
to
7a6dae0
Compare
|
LGTM. small nit: Running |
|
I've been asking for comments on the lock file format from people at work, and they suggested that it might be easier for a human to review if the version and shasums were grouped closer to the artifact key in the lock file. I've created some straw-man example updates here. The first uses the lock file format currently proposed in this PR. The second uses the format amended to bring shasums closer to the version. I'd appreciate any input before I continue with the PR.... |
shs96c
force-pushed
the
v2-lock-file-format
branch
from
7a6dae0
to
010213f
Compare
|
I can definitely see the argument for the new versio. It looks easier to review. |
shs96c
force-pushed
the
v2-lock-file-format
branch
from
010213f
to
8508803
Compare
This is designed to be more friendly when making updates, particularly if the lock files are being reviewed as part of a PR in GitHub.
shs96c
force-pushed
the
v2-lock-file-format
branch
from
dbf5bd0
to
ce5de50
Compare
|
Congrats on shipping :) |
Add support for the v2 lockfile format introduced in bazel-contrib/rules_jvm_external#822
|
Nice, thank @shs96c! Would it be possible to expose the |
|
Can you please file a new issue for that? It should be easy enough to add it. I'd also very happily accept a PR :) |
Thanks for doing it through #862! |
This is designed to be more friendly when making updates, particularly if the lock files are being reviewed as part of a PR in GitHub.
Introduces (and uses!) a new lock file format. This format is designed to change less as dependencies are updated, which should make reviewing update PRs in GitHub a nicer experience. As a nice side-effect, the new lock files are also (typically) more compact.