-
Notifications
You must be signed in to change notification settings - Fork 8
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
Support providing integrity for gem downloads #82
Conversation
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.
Users that don't want a big dict in their WORKSPACE can easily locate it elsewhere in a checksums.bzl and load it up to use here.
Unfortunately this is not possible with Bzlmod because load()
is not allowed in MODULE.bazel
. The way around this would be to support passing a file input to the integrity
, which is later read by a repository rule:
rb_bundle_fetch(
integrity = "//:checksums.bzl"
)
WIth that said, what do you think if we change the PR to:
- Rename
integrity
tochecksums
. - Require it to be put into a file rather than a dict.
- Make syntax similar to Gemfile.lock to avoid writing 2 parsers:
ast (2.4.2) sha256=1e280232e6a33754cde542bc5ef85520b74db2aac73ec14acef453784447cc12
@p0deje that's a shame re. Bzlmod. I think there are a couple questions I have about the file-based approach:
|
I feel like the checksums.bzl would rather be discouraged over using built-in Gemfile.lock checksums, so I'd rather not complicate the implementation with extra runnable targets.
That's an option too. As I mentioned before, I feel like 99% should just upgrade to latest Bundler and use Gemfile.lock as a source of checksums. Frankly, I'd suggest printing this message if
I believe that the ruleset itself should have the checksums for all versions of bundler, while still allowing to pass it as an attribute to |
That sounds reasonable. I can just do that. Upgrading
I'm happy with that. I'll send a separate PR for that after #81 is complete since that change will conflict with #81. |
Hmm, I tried upgrading to 2.5.3 but still don't get CHECKSUMS in Gemfile.lock. I wonder if there is anything to be done in Bundler to turn this feature on. |
Does it require running |
Does it require running bundle lock manually?
I tried both running lock and install, but no matter what, the CHECKSUMS section does not appear in the lockfile.
|
Ok, given the fact that I can't make Bundler 2.5 generate a CHECKSUMS section, let's go with this PR. Can you resolve the conflicts and update |
Yep! |
11a398c
to
d4999bb
Compare
d4999bb
to
b19bffc
Compare
@p0deje OK, done! I renamed |
Our remote downloader service categorically rejects all requests to download a blob without a checksum. Until #63 is complete, users will need to be able to specify gem checksums manually. This PR makes that possible by adding an
gem_checksums
dict to therb_bundle_fetch
rule and Bazel will direct users to use it:Even with #63 complete, I think it's valuable to provide users that aren't on the latest version of Bundler a way to provide checksums. As part of that issue, we can make the returned
gem_checksums
value only require whatever checksums are not present in theGemfile.lock
.Users that don't want a big
dict
in theirWORKSPACE
can easily locate it elsewhere in achecksums.bzl
andload
it up to use here.