Skip to content
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

REL: drop overly protective version upper limits for hard dependencies #3721

Merged

Conversation

neutrinoceros
Copy link
Member

PR Summary

Fix #3712
replaces #3713

Rationale:
I changed my mind about protective version capping after reading this blog post
https://iscinumpy.dev/post/bound-version-constraints/

Essentially, the reason why we're currently capping matplotlib (<3.6) is that we're used to seeing breaking changes in with every matplotlib minor release,
occasionally nasty ones (like the time matplotlib broke yt by erroring on colliding colormap names, see for instance #3165), but there was always the possibility to fix these problems on the user side by downgrading matplotlib.
The problem with that approach is that by setting upper limits in advance, we just make users unable to use future versions of our dependencies, even when they would probably be fine, and there is no easy workaround on the user side there.
Given that our release cadence is de facto slower than matplotlib's, it doesn't seem like a good long term strategy.

Note that I'm keeping some hard caps:

  • in the optional dependencies ([full] env) because it's mostly intended for testing, and not advertised to users so I don't expect anyone to be actually broken by these, and in any case these constraints can be worked around easily on the user side
  • still capping Python<3.12 because it's an actual known incompatibility (see MNT: migrate away from distutils #3384), not an overly protective capping as the ones I'm removing here

For reference, we've been having (and occasionally bumping) an upper limit for matplotlib since #3150

@neutrinoceros neutrinoceros added the enhancement Making something better label Dec 15, 2021
@neutrinoceros neutrinoceros added this to the 4.0.2 milestone Dec 15, 2021
@neutrinoceros neutrinoceros force-pushed the uncap_protective_upper_limits branch from 4fa8f1e to 5431093 Compare December 15, 2021 10:31
@matthewturk matthewturk merged commit 1315367 into yt-project:main Dec 16, 2021
@lumberbot-app
Copy link

lumberbot-app bot commented Dec 16, 2021

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

  1. Checkout backport branch and update it.
git checkout yt-4.0.x
git pull
  1. Cherry pick the first parent branch of the this PR on top of the older branch:
git cherry-pick -m1 13153678747fdef94637b1a2a2d5a5f2956d7b36
  1. You will likely have some merge/cherry-pick conflict here, fix them and commit:
git commit -am 'Backport PR #3721: REL: drop overly protective version upper limits for hard dependencies'
  1. Push to a named branch:
git push YOURFORK yt-4.0.x:auto-backport-of-pr-3721-on-yt-4.0.x
  1. Create a PR against branch yt-4.0.x, I would have named this PR:

"Backport PR #3721 on branch yt-4.0.x (REL: drop overly protective version upper limits for hard dependencies)"

And apply the correct labels and milestones.

Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon!

Remember to remove the Still Needs Manual Backport label once the PR gets merged.

If these instructions are inaccurate, feel free to suggest an improvement.

@neutrinoceros neutrinoceros deleted the uncap_protective_upper_limits branch December 16, 2021 10:54
neutrinoceros added a commit to neutrinoceros/yt that referenced this pull request Dec 16, 2021
matthewturk added a commit that referenced this pull request Dec 24, 2021
Backport PR #3721 (REL: drop overly protective version upper limits for hard dependencies)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Making something better
Projects
None yet
Development

Successfully merging this pull request may close these issues.

MNT: bleeding edge CI isn't running against matplotlib's dev branch
2 participants