-
Notifications
You must be signed in to change notification settings - Fork 1.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
Bump wheel from 0.37.1 to 0.41.1 in /python/helpers #7748
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.
Doesn't support 3.7
, so blocked on:
CI doesn't fail because this dep isn't used directly.
fbd9859
to
db1f59f
Compare
Bumps [wheel](https://github.com/pypa/wheel) from 0.37.1 to 0.41.1. - [Changelog](https://github.com/pypa/wheel/blob/main/docs/news.rst) - [Commits](pypa/wheel@0.37.1...0.41.1) --- updated-dependencies: - dependency-name: wheel dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
db1f59f
to
9461cbb
Compare
Would it add value to add an explicit test for this? Even if it is not used directly, we should know when these updates can break compatibility |
Reading through #5597 again, and seeing that pip-tools itself does not set any requirements on the version of wheel, I wonder if it would make sense to remove this pin? If we remove it, |
Yeah, I'm also personally 👍 for completely dropping the pin. I don't see the point of it for our use case other than for very occasional holdbacks if there's an unexpected bug introduced in a new release, and then unpinning as soon as upstream fixes that bug. |
It's great in theory, but a good deal of work in practice because So we'd need to add an explicit test for the dep against the lowest version of supported python... and we'd end up needing that for all our deps, eg we theoretically should have one for I know we've got one for several of the python package managers, and if someone wanted to take the time to write them for these other deps that'd be awesome, but right now we've generally got bigger fish to fry in a cost-benefit analysis. For example, finishing aligning ourselves with upstream Python release cadence... if we do that, then we've essentially side-stepped the entire version compatibility issue because most of these critical python packages won't drop support for a python version until it's actually EOL'd... by which time we will also treat it as EOL'd. Sorry, long-winded answer, but hopefully it provides more context. tl;dr is yes, that'd be awesome, but no, probably not worth the time for any of the maintainers to write that test right now. |
We've gone back and forth on this repeatedly: * #5597 * #7748 (comment) As @yeikel pointed out, if we're going to keep pinning this, we really ought to have CI that checks it in some way (although that'd potentially be tricky as we want to not only test on latest python, but also oldest python). As Deivid pointed out though, it's not really providing a lot of benefit for us to pin... simpler to just let `pip` pick whatever it needs and keep going. If we observe breakage, we can start pinning again. Although probably (hopefully) that'd be very infrequent, and it'd be only a temporary thing until upstream fixes their bug and releases a new version then we can drop the pin. Or in that case I'd probably actually expect `pip-tools` to handle the work of temp-pinning as they're the ones who need it.
We've gone back and forth on this repeatedly: * #5597 * #7748 (comment) As @yeikel pointed out, if we're going to keep pinning this, we really ought to have CI that checks it in some way (although that'd potentially be tricky as we want to not only test on latest python, but also oldest python). As Deivid pointed out though, it's not really providing a lot of benefit for us to pin... simpler to just let `pip` pick whatever it needs and keep going. If we observe breakage, we can start pinning again. Although probably (hopefully) that'd be very infrequent, and it'd be only a temporary thing until upstream fixes their bug and releases a new version then we can drop the pin. Or in that case I'd probably actually expect `pip-tools` to handle the work of temp-pinning as they're the ones who need it.
Looks like wheel is no longer a dependency, so this is no longer needed. |
Bumps wheel from 0.37.1 to 0.41.1.
Changelog
Sourced from wheel's changelog.
... (truncated)
Commits
b626a4a
Created a new release2a0a487
Don't wrap version specifiers in parens in Requires-Dist (#552)fbd385c
Fixed tense of a changelog entrye43f2fc
Fixbdist_wheel.data_dir
in the presence of local version segment given via...dc945a5
[pre-commit.ci] pre-commit autoupdate (#549)e3c46aa
Switched to trusted publishing9484d92
[pre-commit.ci] pre-commit autoupdate (#547)95c2d83
Created a new releasee8fc452
Updated FreeBSD image on Cirrus CIfb7d837
[pre-commit.ci] pre-commit autoupdate (#546)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase
.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebase
will rebase this PR@dependabot recreate
will recreate this PR, overwriting any edits that have been made to it@dependabot merge
will merge this PR after your CI passes on it@dependabot squash and merge
will squash and merge this PR after your CI passes on it@dependabot cancel merge
will cancel a previously requested merge and block automerging@dependabot reopen
will reopen this PR if it is closed@dependabot close
will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major version
will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor version
will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependency
will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)