PEP 420 native namespaces

[gforcada]

Now that Plone 6.2 is released, all python distributions from the plone and collective namespaces should move to python native namespaces.

Despite native namespaces being a new feature of Python 3.3, we have a problem with collective.exportimport as its purpose is to help move very old code bases, some still on Python 2.7.

Suggestions on how to handle this with as less friction as possible? 🤞🏾

[gforcada]

One extra remark: collective.exportimport heavily relies on pkg_resources, fortunately only for getting if a given distribution is available, but that will stop working as soon as setuptools==82.0.0 (or newer) are used.

So far, Plone 6.2 pins setuptools to 81.0.0 but for 6.3 and 7.0 that version might be easily bumped to +82.

Replacing pkg_resources, to check if a distribution is available, has a 1:1 replacement with importlib.metadata, but that again goes back to the original problem that this is only available for python 3.8+, so python 2.7 is out of question there.

[erral]

I would say that we can safely change the package to have native namespaces.

Those using the package to export old Plone content should use an older version and that's all, right?

[gforcada]

yes, that's meant to be the way in regular development, question is if newer functionality/fixes are meant then to be backported to a previous version that still works on old Plone versions, as the main idea of this python distribution is to be able to install it on old plone versions to extract its content and bring them to a newer Plone version.

[mauritsvanrees]

@gforcada wrote:

One extra remark: collective.exportimport heavily relies on pkg_resources, fortunately only for getting if a given distribution is available, but that will stop working as soon as setuptools==82.0.0 (or newer) are used.

So far, Plone 6.2 pins setuptools to 81.0.0 but for 6.3 and 7.0 that version might be easily bumped to +82.

I ran into this problem while testing buildout/buildout#752 which makes buildout compatible with setuptools 82+. The old namespace was no problem (due to zc.buildout 5, and for development horse-with-no-namespace). But actually calling pkg_resources in the code obviously fails.

Replacing pkg_resources, to check if a distribution is available, has a 1:1 replacement with importlib.metadata, but that again goes back to the original problem that this is only available for python 3.8+, so python 2.7 is out of question there.

Actually, version 2.1.3 is the last version that still claims compatibility with Python 2.7:
https://pypi.org/project/importlib-metadata/2.1.3/
So this may be an option.

@pbauer What do you think?