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.

Sign up for GitHub

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

Jump to bottom

Fix deprecation warnings #4090

Open
40 of 46 tasks
mauritsvanrees opened this issue Jan 20, 2025 · 7 comments
Open
40 of 46 tasks

Fix deprecation warnings #4090

mauritsvanrees opened this issue Jan 20, 2025 · 7 comments
Assignees
@mauritsvanrees

Comments

@mauritsvanrees
Copy link
Member

mauritsvanrees commented Jan 20, 2025 •
edited by davisagli
Loading

There are many deprecation warnings at Plone startup, or when browsing the site or running the tests. A lot are because of code that was moved to plone.base. We should fix those so internally we always use the new code. Lots have been fixed in the past years, but there is still a way to go. I have started on this and will push branches (maurits-warnings) for lots of packages. Notes:

  • This does not fix deprecation warnings for pkg_resources namespaces.
  • All other deprecation warnings at startup have been fixed, at least in Plone code. There is stuff left to fix in Chameleon at least.
  • bin/test -u is also free of such warnings.
  • This includes changes in GenericSetup profiles, such as in registry.xml and componentregistry.xml, where the files no longer point to Products.CMFPlone.interfaces.controlpanel.X but to plone.base.interfaces.X. So this has influence on the database. I think it is fine. I tried migrating a Plone 5.2 site to Plone 6.1. The changes that I made in 5.2 to the syndication settings and search settings were kept, so that seems okay. At some point we should probably advise people to run bin/zodbupdate so any persistent classes are rewritten to their new canonical places.
  • plone.restapi is the only package I touched that still is compatible with Plone 5.2. This has a bbb.py where we try to import from plone.base and fall back to Products.CMFPlone or other places.
  • Ah, same for plone.rest.

The PRs could be tested and merged separately, but let me try to run the checks together on Jenkins. Most will need to still work on 6.0 as well.

I will update this comment to add links to the PRs.

For 6.1 only:

For 6.0 and 6.1:
@mauritsvanrees mauritsvanrees self-assigned this Jan 20, 2025
@mauritsvanrees
Copy link
Member Author

mauritsvanrees commented Jan 20, 2025 •
edited
Loading

Jenkins runs:

@davisagli
Copy link
Member

@mauritsvanrees Thanks for working on this. I see there are 7 new errors on the 6.1 jenkins job

@mauritsvanrees
Copy link
Member Author

On 6.1 there are errors in plone.stringinterp, plone.app.content and for Products.CMFPlone in csrf.txt. When I run those tests individually locally, they go fine. Together they fail:

bin/test -s Products.CMFPlone -s plone.stringinterp -s plone.app.content

Ah, here is a hint:

$ bin/test -s Products.CMFPlone
...
Running Products.CMFPlone.testing.CMFPloneLayer:Functional tests:
  Tear down Products.CMFPlone.tests.testSearch.Search:Integration in 0.000 seconds.
  Tear down Products.CMFPlone.tests.testSearch.SearchLayer in 0.002 seconds.
  Set up plone.app.contenttypes.testing.PloneAppContenttypes in 0.019 seconds.
  Set up Products.CMFPlone.testing.ProductsCMFPloneLayer Traceback (most recent call last):
  File "/Users/maurits/shared-eggs/cp313/zope.configuration-6.0-py3.13.egg/zope/configuration/config.py", line 240, in resolve
    __import__(moname)
ModuleNotFoundError: No module named 'Products.CMFPlone.testing.TestSelectWidgetForm'; 'Products.CMFPlone.testing' is not a package

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/maurits/shared-eggs/cp313/zope.configuration-6.0-py3.13.egg/zope/configuration/fields.py", line 174, in fromUnicode
    value = self.context.resolve(name)
  File "/Users/maurits/shared-eggs/cp313/zope.configuration-6.0-py3.13.egg/zope/configuration/config.py", line 246, in resolve
    raise ConfigurationError(
zope.configuration.exceptions.ConfigurationError: ImportError: Module Products.CMFPlone.testing has no global TestSelectWidgetForm

Okay, that is a missing rename, or a rename too many:

$ bin/zopepy 
>>> import Products.CMFPlone.testing
>>> Products.CMFPlone.testing.TestSelectWidgetForm
Traceback (most recent call last):
  File "<console>", line 1, in <module>
AttributeError: module 'Products.CMFPlone.testing' has no attribute 'TestSelectWidgetForm'. Did you mean: 'TestSelect2WidgetForm'?
>>> Products.CMFPlone.testing.TestSelect2WidgetForm
<class 'Products.CMFPlone.testing.TestSelect2WidgetForm'>

I will fix and squash the CMFPlone PR and rerun the 6.1 tests.

@mauritsvanrees
Copy link
Member Author

All Jenkins tests have passed. See links in comment above.
So all PRs could be merged, I think.

None of these PRs should be dependent on one another, so they can be reviewed and merged on an individual basis.
Most are small, simple fixes, but some may need a more critical look, especially if you think persistent data may be affected, and we may need an extra upgrade step. But I don't think this is needed.

@gforcada
Copy link
Member

I will try to review them. I don't have much time as of late, but specially for the small ones, I can do easy work. On the City Alpine Sprint I will try to get myself a bit more up-to-speed with current developments 🍀

@gforcada
Copy link
Member

@mauritsvanrees the PRs on the section For 6.1 only means that the distributions need to be forked for master and X.Y branches? 🤔

@mauritsvanrees
Copy link
Member Author

the PRs on the section For 6.1 only means that the distributions need to be forked for master and X.Y branches? 🤔

It means that for these packages the master or main branch is only used on 6.1, and I have only fixed it there. If we want to get rid of deprecation warnings in those packages in 6.0 as well, we would need to back port these PRs. I would say this is not needed, though someone could do it if they wanted to. But no one cared enough about deprecation warnings in 6.0 to do this the past two years. Back porting can also be slightly tricky, as you may need more try/except ImportErrors in this case, or need to ignore a few fixes (especially imports of plone.app.z3cform.widget).

For clarity, the packages in the 6.0+6.1 list are packages where the same main/master branch is used on 6.0 and 6.1. In the Jenkins 6.0 jobs I only pasted the second list, in the 6.1 jobs I pasted the combination of both lists.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mauritsvanrees mauritsvanrees

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@davisagli @mauritsvanrees @gforcada