Fix RTD build now that the URL for 6.2-latest is now 6.2-dev

[stevepiercy]

The rename of the URL broke documentation test and RTD PR preview builds once I updated the git submodule in documentation. This should fix it.

See:

• https://github.com/plone/documentation/actions/runs/19747892202/job/56585719216?pr=1999#step:5:266
• https://app.readthedocs.org/projects/plone6/builds/30486397/

---

📚 Documentation preview 📚: https://ploneapi--591.org.readthedocs.build/

[mister-roboto]

@stevepiercy thanks for creating this Pull Request and helping to improve Plone!

TL;DR: Finish pushing changes, pass all other checks, then paste a comment:

@jenkins-plone-org please run jobs

To ensure that these changes do not break other parts of Plone, the Plone test suite matrix needs to pass, but it takes 30-60 min. Other CI checks are usually much faster and the Plone Jenkins resources are limited, so when done pushing changes and all other checks pass either start all Jenkins PR jobs yourself, or simply add the comment above in this PR to start all the jobs automatically.

Happy hacking!

[stevepiercy]

Uh-oh, looks like there's other unrelated issues that cause CI checks to fail. Can someone else add to this PR or fix those separately? I have no clue.

[mauritsvanrees]

6.2-latest has never existed. I have now added it as symlink to 6.2-dev.
Once we have an alpha/beta/rc/final release, I will let it point there.

FWIW, here are all latest symlinks:

3.3-latest -> 3.3.6
3-latest -> 3.3-latest
4.0-latest -> 4.0.10/
4.1-latest -> 4.1.6
4.2-latest -> 4.2.7
4.3-latest -> 4.3.20
4-latest -> 4.3.20
5.0-latest -> 5.0.10
5.1-latest -> 5.1.7
5.2-latest -> 5.2.15
5-latest -> 5.2-latest
6.0-latest -> 6.0.15
6.1-latest -> 6.1.3
6.2-latest -> 6.2-dev
6-latest -> 6.1-latest

(FTR, I noticed that 3-latest was pointing to 3.3.5 instead of 3.3.6, so I fixed that.)

[mauritsvanrees]

The test error is this

ModuleNotFoundError: No module named 'plone.api'

This may be caused by having switched to native namespaces, which we did a few days ago in PR #588. But the tests were green there.

I can't check now. Maybe @gforcada or @davisagli see what we are missing.

[stevepiercy]

Initially in d0b0183 the file constraints_plone62.txt was added and referred by .meta.toml and pyproject.toml using 6.2-latest, which I changed to 6.2-dev, but that also didn't work. I reverted it to 6.2-latest for the eventual release. Docs build, but the import of plone.api still fails, so the API pages are not functional, even though the CI shows it's green.

This is blocking CI for plone/documentation.

[davisagli]

@mauritsvanrees There are at least 3 problems which are preventing the PEP 420 namespaces from working correctly.

1. https://dist.plone.org/release/6.2-dev/constraints.txt still has plone.staticresources 2.3.4 which did not remove the pkg_resources namespace yet. So we have lib/python3.13/site-packages/plone.staticresources-2.3.4-py3.13-nspkg.pth which sets up the pkg_resources namespace, which means Python will not look up the __path__ the PEP 420 way. So it does not find the editable plone.api even though it is in sys.path.

@petschki could we have an alpha release of plone.staticresources please?

2. plone.browserlayer 4.0.0a1 still has a plone/__init__.py that calls pkg_resource.declare_namespace, even though the namespace is no longer declared in setup.py. This ends up in lib/python3.13/site-packages/plone/__init__.py. Again this sets up the pkg_resources namespace and gets in the way of looking up the __path__ dynamically.

I opened a PR plone/plone.browserlayer#41

3. https://dist.plone.org/release/6.2-dev/constraints.txt still has Products.CMFPlone==6.1.1, which still uses pkg_resources for the Products namespace.

[petschki]

@davisagli I've released plone.staticresources==3.0.0a1 and plonetheme.barceloneta==4.0.0a1 with PEP 420 implementations

[mauritsvanrees]

This is strange. It goes against what I have seen during testing the past months and what I have written in the zc.buildout readme: pip can handle a mix of namespace styles in final releases plus one style in editable installs. I wonder what has changed in the days between merging the PR here that added native namespaces and now.
I am not behind my computer so I can't check or fix anything.

[mauritsvanrees]

I have released plone.browserlayer 4.0.0a2 with the fix from David plus moving to a src-layout. I have updated only that version in constraints.txt and then ran tox -e test on the plone.api main branch and then it worked again.

I have updated the other constraints/versions on 6.2-dev as well now, including plone.staticresources.

[mauritsvanrees]

It is green now.

[davisagli]

This is strange. It goes against what I have seen during testing the past months and what I have written in the zc.buildout readme: pip can handle a mix of namespace styles in final releases plus one style in editable installs.

@mauritsvanrees The issue isn't really pip but how the namespace module's __path__ gets set up at runtime. I think that if a pkg_resources namespace is initialized anywhere (either by a -nspkg.pth in site-packages or a call to declare_namespace in __init__.py) then it will set up the namespace with a __path__ that only includes the paths where there is a pkg_resources namespace package.