No tooling for updating the "integrity" field of `source.json`

[bazelbuild]

No tooling for updating the "integrity" field of `source.json`

[shs96c]

For reference, the key appears to be a base64 encoded version of the sha256 of the archive to download.

[Wyverald]

You're not supposed to develop modules using the registry. On the contrary, you should develop your project as you normally would, and when it's released, add it to the registry.

For the record, the integrity field follows the subresource integrity metadata format, as is documented in the Bzlmod user guide. We could look at making that information more easily discoverable.

[shs96c]

I'm working on getting rules_jvm_external up and running with bzlmod, so I'm making changes in a fork of that repo, pushing to there, and then modifying a local clone of the registry so that I can try using the modularised rules_jvm_external in a different project.

[Wyverald]

It sounds like using an override (in particular, local_path_override) on rules_jvm_external in that different project might suit your use case much better.

[shs96c]

Can those be added on the command line, similar to --override_repository?

[Wyverald]

Not right now, but maybe it's a good idea to add that for development? @meteorcloudy wdyt?

[meteorcloudy]

Not right now, but maybe it's a good idea to add that for development? @meteorcloudy wdyt?

Yes, I was actually thinking about how could we run downstream test more easily (eg. to see if version 1.1 of module X breaks other modules which depend on X 1.0), if we have a flag to override a module then we don't have to mess with the MODULE.bazel file.

[Wyverald]

Closing in favor of bazelbuild/bazel#14552