Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #353 +/- ##
=======================================
Coverage 87.17% 87.17%
=======================================
Files 20 20
Lines 2019 2019
=======================================
Hits 1760 1760
Misses 259 259
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Or maybe I'm misunderstanding and we should discuss. I would like to take a bit of time to understand the right thing to do and make sure we're doing it the right away. |
| "Operating System :: OS Independent", | ||
| "Programming Language :: Python", | ||
| "Programming Language :: Python :: 3", | ||
| "Programming Language :: Python :: 3.8", |
There was a problem hiding this comment.
I'm not seeing a python-requires = '>=3.9' anywhere. This would arguably be more important than removing a trove classifiers, as installers like pip understand the former, and don't use the latter.
There was a problem hiding this comment.
We stopped testing with Python 3.8, and we make no claims about working with Python 3.8.
|
@jagerber48 Please approve. FutureWarning is the current warning, and is widely viewed as obnoxious because it gives a warning at every usage. You can argue your points about which deprecation warning is best while working on 3.2.6, at any pace you want. This PR will turn off those warnings, while preserving the rest of the changes in 3.2.4. I did not push 3.2.4, but I am also not in favor of yanking it. Again, please approve. |
Co-authored-by: Clément Robert <cr52@protonmail.com>
|
At my current level of understanding, which may be wrong, you're using |
|
@jagerber48 It adds testing and support for Python 3.13 and 3.14. It fixes the project configuration files and fixes the uploads of releases to PyPI. If we yank 3.2.4, we go back to 3.2.3 from last April, with no process for releasing a new version. And no clear statement or commitment to support for Python 3.13. All changes made since April become part of a set of mistaken changes, and someone will have to separate the usable parts from the stuff to throw away. And you now have to re-litigate every one of those changes. I am not in favor of that. This PR preserves all the other changes, and suppresses the annoying warnings, which sort of follows normal Python usage. Yes, Python warnings do not work well. The available choices are 1) use Again, yes, it is very weird that this is ignored by default and is a constant source of pain, but that's what we have. Go ahead and "try to understand this" AFTER this get approved and pushed as 3.2.5. That you are not in favor of that worries me greatly. |
|
Btw I don't understand how this is supposed to resolve #352 |
|
Here's my proposal:
If you like we can drop 3.8 support in 3.2.5 but that change is ENTIRELY orthogonal to this deprecations issue and I think should be ignored for now. This proposal addresses
as for
The thing to re-litigate is deprecating
I don't mind |
|
@jagerber48 Your proposal requires a PR. That does not exist. You can make that PR right now -- you could have made one at any point in this process. Or you can approve this one AND THEN un-deprecate anything you want. Code can be undeprecated after being warned as PendingDeprecationWarning -- that is actually a clear feature of pending deprecation warnings. Move forward. Do not ignore maintenance. There is a very real danger of precipitating a non-friendly fork here. |
|
@jagerber48 I will enable "merge without waiting for requirements to be met" (ie, without an approved review) and merge this branch in 2 days if it is not approved. And then we will need a very real conversation about how this project is managed. This is not good. |
|
@newville I genuinely don't understand why you're pressuring your peers into approving this PR, which again, doesn't address the problems it's claiming to. As a third party consumer, your attitude is a bit alarming. |
Note, this is the purpose of the yank feature on pypi. If you make a mistake and push a bad release then, if the team makes the decision, you can have the release quickly yanked within 5 minutes so users don't face issues while you sort through things internally. |
@newville I agree with this. Your attitude has pushed away the other people who volunteered to help maintain this repo when lebigot made the call. Your attitude also pushes away friendly folks in the community offering their time to help make |
|
@jagerber48 This PR is to fix the FutureWarning. I did not add that code, I did not push that release. In fact, my PR for 3.2.4 was ignored. This is just "let's turn those messages off and go back to figuring it out". You can do anything you want after that. You are delaying fixing the actual problem. But, OK, I'm the bad guy. OK. I yanked 3.2.4. Closing this PR. That's 2 PRs in a row not merged. yep, good luck. |
3 participants
pre-commit run --all-fileswith no errorsThis should be merged and tagged as 3.2.5