Switch to SPDX license expression in setup.py

[icemac]

FEATURE REQUEST

Releasing packages shows the following warning:

SetuptoolsDeprecationWarning: License classifiers are deprecated.
!!

********************************************************************************
Please consider removing the following classifiers in favor of a SPDX license expression:

License :: OSI Approved :: Zope Public License

See https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license for details.
********************************************************************************

Steps to solve it:

• use license='ZPL-2.1', (Source: https://spdx.org/licenses/)
• Remove License :: OSI Approved :: Zope Public License.

Example:

• https://pypi.org/project/grokcore.message/5.0/
• zopefoundation/grokcore.message@59713a7

Tasks:

• Implement the steps mentioned above in config-package script.

[mauritsvanrees]

If you are using pyroma (from zest.releaser[recommended]) during release, you may get an error. See my comment.

Same can already be seen when you run bin/pyproject-build (from the build module), as can be seen in my comment after.

[dataflake]

I have experimented with this today.

It seems if you use license='ZPL-2.1' in setup.py then PyPI will just repeat that specific string, like on https://pypi.org/project/grokcore.message/5.0/. That is pretty uninformative, so in other places I have used things like license='Zope Public License (ZPL-2.1)' to be a bit more informative, like here: https://pypi.org/project/Products.mcdutils/

If you add this information into pyproject.toml, like so:

[project]
license = "ZPL-2.1"

then you get a couple small links to more information, like here: https://test.pypi.org/project/Products.mcdutils/. That's nicer. I wonder why that's called "License Expression" on PyPI, though, makes it sound strange to "normal" package consumers.

[dataflake]

P.S.: I have taken this as encouragement to move everything I can from setup.py to pyproject.toml in one of my own packages and in the end I was left with this setup.py stub:

https://github.com/dataflake/Products.mcdutils/blob/master/setup.py

The namespace package discovery settings are only there because pyproject.toml does not support old pkg_resources-style namespace packages. Once this is converted to a PEP 420 native namespace package those can move to pyproject.toml. I think I can even remove setup.py at that point?

Just as an idea for our other packages.

[icemac]

@dataflake This reduced setup.py looks amazing. But be aware if you want to use mr.developer you cannot delete setup.py, yet, because it does not know how to handle packages without setup.py.

[dataflake]

Thanks for the reminder - I dimly remembered there was an issue but couldn't say what it was. I am guessing mr.developer will still work with a setup.py that does nothing but call setup(name=XXX)?

[icemac]

Thanks for the reminder - I dimly remembered there was an issue but couldn't say what it was. I am guessing mr.developer will still work with a setup.py that does nothing but call setup(name=XXX)?

Yes, I think this should be enough.