-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Should we add a DeprecationWarning
to pkg_resources.declare_namespace
?
#3434
Should we add a DeprecationWarning
to pkg_resources.declare_namespace
?
#3434
Conversation
I reckon this is a good idea, but without a clear timeline or policy on what this deprecation means (beyond "use a newer nicer thing, instead of this older thing"), it's not particularly useful to "deprecate". As a fly-by suggestion, consider doing the following:
|
Thank you very much @pradyunsg for the feedback. I think that in practice Unfortunately this milestone does not provide a timeline or metric/trigger point that we could reference here (I understand that it is a complicated matter). Regarding your suggestions.
That is a very fair request, thank you very much. I will try to come with something soon-ish...
I think I cannot come up with this alone. To be sincere it is not clear to me yet what is the setuptools policy about deprecation, and how much time we give as notice between deprecation and removal. I also understand that the support for some features instead of being completely dropped can just be reduced to the bare minimum in order to avoid breaking old packages in the ecosystem (e.g. supported in regular installations, but not in editable installations). So this could be the way to go here. I will wait for input from the other maintainers, and once we have an understanding/agreement on what would be a suitable timeline/metric/trigger, I can add that. |
Fair enough! I guess my comments are more pertinent to the broader deprecation then, instead of this specific PR. I appreciate that you took the time to write a detailed reply @abravalheri to my fly-by comment. ^.^ |
a85759c
to
93ce5a0
Compare
This PR seems reasonable. I was originally concerned that the deprecation warning might be noticed by end users, but then was reminded that DeprecationWarnings are typically not visible to end users except in test suites, so that's good. I'm fine with rolling this out to see how it helps. One other thing to check - have we also deprecated the use of |
6d8b0a4
to
de2361c
Compare
I have rebased the PR and updated the docs to explain why the deprecation is needed.
Yes, it is already deprecated: https://github.com/pypa/setuptools/blob/v67.2.0/setuptools/dist.py#L281-L285 |
Is there a good guide on how to actually do this migration on the downstream package side? Is it enough to just delete the |
Removing the The caveat is that all projects sharing the same namespace have to agree with that... (The same way, previously they all agreed to use |
Although technically, a namespace should share the same technique, in my experience in typical pip-installed environments (which strip the init.py for pkg_resources-managed namespace packages anyway), the transition is painless. I migrated several namespaces, including For example: jaraco/jaraco.functools@d84738a If you encounter any trouble, don't hesitate to mention me in a bug report. |
That's going to be interesting for |
I am not sure if |
Hi, Plone Release Manager here.
That is a total of 171 packages. Included in those are a few with a second namespace level:
I don't look forward to fixing all of these in one go as community, but I guess it was coming, I think have seen a deprecation warning already a few months ago. If needs be, it can be done. All packages that you use from one namespace have to use the same technique, right? So either pkg_resources namespaces or native namespace (ignoring pkgutil here for simplicity). This means that for Plone it only makes sense to do this in a major release, so Plone 7. Since the previous major release was only released a few months ago, December 2022, it can still be a few years before the next major one is released. We have no definite timeline yet, but here is our release schedule. Maybe this can be taken into account when considering when to completely remove support for pkg_resources namespaces? That would be nice. The Plone policy can be summarised as this:
Keeping support for pkg_resources namespaces for five more years seems too much to ask. Of course, once support is dropped, people can still use an older setuptools version when they run Plone 6. I don't think there are any plans to ban either uploading or downloading pkg_resources-style namespace packages from PyPI. |
Can we keep support for Note: This is not an official poll. I am not a |
Where I see the major problem here is with Coordinating Zope or Plone on its own will be a lot of effort, but doing that for As @mauritsvanrees says, knowing when the code is going to be removed to see how much time we have to adapt, and specially which version will be the last one with support for |
Hi @mauritsvanrees and @gforcada thank you very much for the insights. The idea behind introducing the warning was precisely to improve the communication with the community. This deprecation and alternative has been documented for a few years (together with other tips and advise for swapping Setuptools still has to finish decoupling itself from We have a few options on how to handle the removal in a way that it is backwards compatible:
Probably @jaraco will have better insights on this topic. It would be interesting also to understand to which extent the projects are relying on deprecated features of setuptools which are not exactly direct calls to Footnotes
|
So
For the same reason, I don't think this can technically work for
I suppose
Entry points are widely used in Plone, certainly for add-ons and some tooling packages like In code outside of I recently patched code that had an incompatibility when calling There are about seven Zope packages that use C extensions, but I don't think there is anything deprecated about that. For the rest I am not aware of anything in Plone code that would be |
This will break previously working CI for packages that use A workaround is to add an ignore for this specific deprecation warning:
https://docs.pytest.org/en/7.1.x/how-to/capture-warnings.html#controlling-warnings Is this a reasonable thing to do until packages are updated? |
I think it makes sense to add a warning recommending the migration to PEP 420.
pkg_resources
is in its majority "discouraged", isn't it?Summary of changes
DeprecationWarning
topkg_resources.declare_namespace
.DeprecationWarning
to the final user (unless they opt-in for something more strict, in which case they should be familiar with more complex warning filters), so this approach should be OK.Closes
Pull Request Checklist
changelog.d/
.(See documentation for details)