TST/DEP: add missing resolution constraints for the all extra#18955
TST/DEP: add missing resolution constraints for the all extra#18955mhvk merged 3 commits intoastropy:mainfrom
all extra#18955Conversation
|
Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.
|
|
👋 Thank you for your draft pull request! Do you know that you can use |
99fe131 to
25dfd7c
Compare
51017b7 to
d7dc78a
Compare
931fd1f to
07a4aa7
Compare
18df68b to
2c19175
Compare
| # via ipython (can be removed once ipython<8.17 is dropped) | ||
| "pickleshare>=0.7.5", |
There was a problem hiding this comment.
Why shouldn't we drop support for ipython<8.17 right now? Then we wouldn't need this constraint at all.
There was a problem hiding this comment.
I don't think this represents a maintenance burden so high as to warrant bumping a dependency.
There was a problem hiding this comment.
I also want to be extra careful with bumping any optional dependency, as we don't necessarily control how and when users install them; because most end users have long-lived multi-use virtualenvs, they can have same installed before or after they installed astropy, or just not opt into the [ipython] extra (most end users don't know about pip's support for extras...) and I don't think saving ourselves a single line of metadata warrants potentially breaking all these valid use cases.
There was a problem hiding this comment.
most end users have long-lived multi-use virtualenvs
Those users are perfectly happy running astropy 5.3 they installed two years ago. Besides, bumping our ipython requirement does not necessarily mean running astropy with an older ipython is impossible, it just means we don't guarantee that it is possible.
There was a problem hiding this comment.
And my point is that slightly cleaning up (temporary) metadata is not good enough grounds for renouncing this guarantee. See #18967
There was a problem hiding this comment.
In any case, bumping anything is out of scope for this PR, so can we please move along with this one and make clean-ups and bumping into their own discussions ?
2c19175 to
06d271c
Compare
|
This is currently the last PR attached to #18782, so I'm making an attempt to resolve it here. Moving to draft while CI is running 🤞🏻 |
|
clearly not ready yet. I'll revert to the previous scope of this PR and will keep track of the remaining issue(s) elsewhere. |
b3e0e56 to
148c1a7
Compare
d49beac to
e3a22be
Compare
|
@eerovaher @pllim this is the last bit needed to close a large issue, can we postpone any user-visible change to an eventual follow up ? |
|
I am okay with this but since @eerovaher had comments, I'll let him approve. Thanks for your patience! |
f3550ec to
ce2905c
Compare
mhvk
left a comment
There was a problem hiding this comment.
This looks nice -- the no-build part is just obviously good, and I like the clear comments about when we can drop indirect dependencies. I think some of that will happen soon, but this sets us up well enough.
|
I'm going to put this in as it is holding up other work -- we should discuss what we do with optional dependency versions in #18967 (where I think we were not that far from a consensus). |
Description
ref #18782
complementary to #18949
I'm getting very close to the end goal.