Move all supported package metadata into pyproject.toml

[dataflake]

This is a test for moving all project metadata that is fully supported from setup.py into pyproject.toml and clean up some small configuration items. Feedback highly welcome. This is like a blueprint for all ZF packages.

Metadata for extension modules has not moved because...

• While it is supported in general (see https://setuptools.pypa.io/en/latest/userguide/ext_modules.html#building-extension-modules) doing so brought up warnings while building the sdist under setuptools 80.9.0 that the ext-modules keyword is still experimental and likely to change.
• gcc fails to locate the header files when building binary wheels (binary wheels build correctly when adding an explicit include-dirs = ["src"]
• I don't see a way to express "don't build these under PyPy" as we do in setup.py

I have also tried to clear up the author versus maintainer relationship by leaving author as "Zope Foundation and contributors" while adding "Plone Foundation and contributors" as maintainer. The Zope Foundation has not existed for many years now.

[dataflake]

Side note: While experimenting I found that it's possible to declare the successful build of an extension module as optional, which lets a PyPy build proceed instead of failing immediately. But then the tests fail:

• zope.testrunner imports zope.interface
• zope.interface wants to check if it can use its own C extensions
• the check in zope.interfaces._compat._c_optimizations_required only checks for the PURE_PYTHON environment variable, but not for PyPy.
• the bad check assumes "yes, I can use C extensions" which then fails with an ImportError.

[mauritsvanrees]

LGTM. One setting could be removed, see inline suggestion. But it works as is when I try it locally.

One thing I don't like, is that this no longer adds the CHANGES.rst to the long_description. But it seems you cannot specify multiple files as source for project.readme. I tried, but ran into validation errors. I see that poetry supports this with an own setting. But I don't want to use poetry.

At least this is compensated by having a link to the changelog, so I guess we have to live with it. A lot of projects do this.

[mauritsvanrees]

For this package with C-extensions it may be hard or impossible to completely get rid of setup.py. For pure Python packages it should be doable.

So a small reminder of current buildout status when removing setup.py:

• With zc.buildout 4 you cannot develop such a package: buildout basically calls python setup.py develop, so you must have the file. It can be just a few lines though, with the real configuration living in pyproject.toml.
• With zc.buildout 5 a setup.py is no longer needed. Everything can be in pyproject.toml.
• But: you do still need to use setuptools as build-system. I tried getting zc.buildout 5 to handle development of a package that uses hatchling as build system, but that did not work.

[dataflake]

One thing I don't like, is that this no longer adds the CHANGES.rst to the long_description. But it seems you cannot specify multiple files as source for project.readme. I tried, but ran into validation errors. I see that poetry supports this with an own setting. But I don't want to use poetry.

At least this is compensated by having a link to the changelog, so I guess we have to live with it. A lot of projects do this.

I'm guessing a lot of projects do this because they don't have a choice... Not being able to concatenate the change log into the description is annoying, I know.

For this package with C-extensions it may be hard or impossible to completely get rid of setup.py. For pure Python packages it should be doable.

Yes, we're not there yet, but this is a good first step. I think there's a lot of value in being able to parse and, if necessary, manipulate those values that only existed in setup.py before.

[dataflake]

@mauritsvanrees Speaking of zc.buildout 5, is there any holdup I can help with? No, rush, just wondering.

[icemac]

@dataflake I like the approach to get all the config back into one file and one which is not code to be run at install time.

Did you do the conversion setup.py -> pyproject.toml by hand or did you use a tool for it? So what could be a step foreward to apply this migration to other repositories?

[icemac]

I like it.

[dataflake]

@icemac I did it by hand. But once you have done a few it's more like copy/paste from previous packages and just changing details.

[mauritsvanrees]

@mauritsvanrees Speaking of zc.buildout 5, is there any holdup I can help with? No, rush, just wondering.

@icemac Did you get a chance to test zc.buildout 5 on your projects yet?

[icemac]

@mauritsvanrees I am running zc.buildout 5 in production since some days, but I am not running it on any mixed namespace packages, mostly PEP-420 ones, some remaining pkg_resources ones. So 👍 from me for a final release, would also make life here in zopefoundation packages easier.

[mauritsvanrees]

I have released zc.buildout 5.0.0 and zc.recipe.egg 4.0.0 (which depends on zc.buildout>=5.0.0 now). Both support Python 3.9-3.13. I suppose they will work on 3.14 as well, but I just now realise we are not yet testing that.

[dataflake]

Check out zopefoundation/Zope#1272 and the test failures. Looks like the alltest buildout stanza can't find the external Products namespace packages anymore, but only on Linux and Windows?

Building and running the simpler bin/test works.