plone.app.upgrade must not be a hard dependency.

[jensens]

zope.configuration.xmlconfig.ZopeXMLConfigurationError: File "/home/jensens/ws/sandbox/check342/backend/.venv/lib/python3.12/site-packages/plone/volto/patches.zcml", line 10.2-15.8
    File "/home/jensens/ws/sandbox/check342/backend/instance/etc/site.zcml", line 12.2-12.23
    File "/home/jensens/ws/sandbox/check342/backend/.venv/lib/python3.12/site-packages/Products/CMFPlone/configure.zcml", line 128.2-132.8
    File "/home/jensens/ws/sandbox/check342/backend/.venv/lib/python3.12/site-packages/plone/volto/configure.zcml", line 20.2-20.33
    ModuleNotFoundError: No module named 'plone.app.upgrade'

With pip install -c https://dist.plone.org/release/6.1-dev/constraints.txt plone.volto

The real bug is here: plone.app.upgrade should always be a soft-dependency, never a hard dependency, since some of us do not want to have it on production instances.

[davisagli]

@jensens https://github.com/plone/plone.volto/blob/main/src/plone/volto/patches.py is using alias_module from plone.app.upgrade to provide backward compatibility with old content type class locations from collective.folderishtypes.

Should we move alias_module to plone.base maybe?

[jensens]

Should we move alias_module to plone.base maybe?

Yes. And since this are only 18 LOC it's something which could be copied to here as well - if it otherwise would break with older versions (https://github.com/plone/plone.volto/blob/fdb85bb5305da27ea9f1747844a43aea3bb5bbbb/setup.py#L36C37-L37C1)

[davisagli]

it otherwise would break with older versions

unless we create a module alias for it....oh wait....