Update deny config & bump base64 to 0.22 #119
Conversation
|
Not sure what's going on with the Windows CI jobs here. |
I'm not sure either, but it's unrelated to this branch. I opened #117 for the failures the other day but haven't investigated yet. |
Cargo.lock
Outdated
| [[package]] | ||
| name = "base64" | ||
| version = "0.22.1" | ||
| source = "registry+https://github.com/rust-lang/crates.io-index" | ||
| checksum = "72b3254f16251a8381aa12e40e3c4d2f0199f8c6508fbecb9d91f575e0fbb8c6" | ||
|
|
There was a problem hiding this comment.
Question: Why are we bumping base64 when it just duplicates it in-tree compared to the rest of the lower-level rustls crates?
There was a problem hiding this comment.
It has been updated in the upstream crates, but we haven't been merging Cargo.lock updates as proposed by Dependabot in this repo.
There was a problem hiding this comment.
we haven't been merging Cargo.lock updates as proposed by Dependabot in this repo.
In retrospect I think turning that on for this repo was probably a mistake. I'd be OK with removing it again.
There was a problem hiding this comment.
Why do you think so?
The update PRs sit without reviews/merge and so the bot updates just become churn notifications.
From my perspective the norms for reviewing those PRs hasn't been set in this repo, or written down explicitly. I personally don't feel enough ownership here to blanket +1 updates that don't affect MSRV like I might in rustls/rustls or rustls/webpki.
I remember @complexspaces pushing back on landing the automation and in retrospect I think it would have been better to work through some kind of policy/expectation-setting before landing the automation. Lesson learned :-)
There was a problem hiding this comment.
I'd be OK with removing it again
Here's a PR for that: #120
If nothing else it gives us a place to continue this discussion separate from the cargo deny issue.
There was a problem hiding this comment.
I hope no one feels bad about the current state of the lockfile/dependency updates, that wasn't my intention at all. I tend to not look at the PRs because my OSS time is already fairly limited.
I did push back when first proposed because it seemed weird to me to update dependencies via lockfile just because they had updated, since this is generally not what I do at work or personal projects. I tend to only do dependency upgrades when there's a new direct dependency and then make sure the lockfile is clean as an end result.
This is definitely something I'd be happy discussing more though, since I don't think there's one correct way to do this across all projects.
There was a problem hiding this comment.
I hope no one feels bad about the current state of the lockfile/dependency updates
No hard feelings here!
There was a problem hiding this comment.
@complexspaces I've tacked on a separate commit here which just did cargo update, which shows that this crate only depends on base64 0.22 after these changes.
|
So I guess one potential benefit of keeping |
|
@djc Can you rebase this on @complexspaces Anything else you want to see done with this branch? It'd be nice to have passing CI for community contributions like #122 |
|
Rebased! |
Nope, things look good now 👍. Sorry, it was a busy week. |
Unblock: