-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[BUG] DID NOT WARN errors on two tests #4864
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
Comments
Oh! It's because that deprecation warning is past due, so now causes the tests to fail. That's not great. |
I've temporarily disabled the tests for this behavior so that the test suite is stable again. I see in #4679, this deprecation was postponed. @abravalheri What's your instinct now? |
Hi @jaraco, this due date kind of works as a "watchdog": it is a reminder for us to either remove the deprecated feature or to postpone it for later (otherwise there is a bunch of deprecation warnings that only linger forever in the code base). I just affects the setuptools code-base and should not impact the end users (because it is behind a env var flag). I never found a better way of doing this. Now we have a couple of options:
My only strong opinion is against 3a, the other ones are OK by me. I am not sure how realistic would be to use "PyPI BigQuery-foo" to obtain statistics about this and take an informed decision (I assume that for each package in PyPI it would be necessary to download and inspect individually each If we are bold, we can potentially go with option 1 and see if there is push back from the community. |
In coherent.deps, I've been developing a database of PyPI packages and routines around doing stuff with them. For that project in particular, I download the latest wheel of each project and inspect it (in memory). It's entirely plausible we could use some of that machinery to process the top N packages and inspect their setup.cfg. That said, I'm leaning toward option 1, get some signal out there to non-compliant projects, and then if the disruption is large, rollback and fallback to option 2 (now with the affected projects having visibility to the issue). |
This needs to be rolled back sooner rather than later |
I think rolling out changes like this is quite disruptive to the ecosystem and is to aggressive for a foundational package like this. I would appreciate more effort determining if changes like this would be disruptive ahead of time.
If something like this is plausible, it seems like a great investment for assessing future changes.
Is there a downside to this approach? It looks like this was originally deprecated because the extra names were not installed correctly by pip (#1608) but that doesn't seem like a strong motivation? (I tried |
setuptools version
main
Python version
3.13.2
OS
macOS
Additional environment information
No response
Description
Today I tried running the Setuptools tests and I'm getting two errors, seemingly due to warnings emitted as errors:
These failures are happening on 8e39bc9, which passed CI, so there's something about my environment that's triggering the failures.
Expected behavior
Tests should pass
How to Reproduce
tox
Output
The text was updated successfully, but these errors were encountered: