Minor update to pyproject.toml for license fields

[RobertoRoos]

Resolves

• Warnings from setuptools #495

[coveralls]

Pull Request Test Coverage Report for Build 21128702717

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall first build on bugfix/toml-license at 93.86%

---

Totals
Change from base Build 21022931437:	93.9%
Covered Lines:	10762
Relevant Lines:	11466

---

💛 - Coveralls

[RobertoRoos]

Oh, looks like this is the time already to drop Python 3.8.
Also see pypa/setuptools#4903

[stlehmann]

Can't see any harm in dropping Python 3.8 support. It's marked EOL since 2024.
https://devguide.python.org/versions/

[stlehmann]

@chrisbeardy what do you think?

[chrisbeardy]

It feels a bit wrong dropping support for a python version over a purely static bit of metadata telling people the licence, i know its EOL but i bet a lot of people using pyads may still be on 3.8. I personally have no projects still on 3.8 but i do on 3.9 and I know the automation industry moves slow. Is this the only way of telling people license terms these days "included" with the package, because its in the repo. What does this metadata do, just make it appear on pypi as MIT? I'd be more inclined to drop python version support because of a new feature for example.

[chrisbeardy]

Having said that, I do see a very high value and do want to move to a more modern build platform including pyproject.toml As I definitely think that will help maintain things in the future and also stuff like the what we're doing with the wheel builds will definitely help across multi platforms and probably just generally Making things more maintainable. So ultimately if keeping 3.8 support means we can't modernize our build platform then I would also be happy to drop support for that version.

[RobertoRoos]

It feels a bit wrong dropping support for a python version over a purely static bit of metadata telling people the licence

I won't miss 3.8, but this is indeed a peculiar point for the setuptools people to drop the axe for.

Actually, I was already curious so I tried to keep up 3.8 and came up with this:
https://github.com/RobertoRoos/pyads/tree/bugfix/toml-license-3.8

By using dynamic the issue can be bypassed it seems. It's just that I can't really test the results of this change, I don't know how the info is used anyway.
Personally I say we don't bend over backwards and just drop it.

[stlehmann]

I get the point of @chrisbeardy. Sometimes you have old production environments that restrain you to use an old Python version, especially in the Automation sector. However dropping 3.8 support doesn't mean folks can't use pyads anymore. They just won't get the latest version anymore.

[chrisbeardy]

I would agree not to bend over backwards. It'd be quite nice if we were able to add additional features and still support 3.8. Obviously if a time came where we're adding additional features and 3.8 prevented it, then I would obviously happily probably drop 3.8. It's like as we say it's a bit of a strange one for setuptools.

I've been looking into this, I think best to just drop 3.8.

[chrisbeardy]

This made me chuckle, just compiled some software for my PC and got this warning :

writing top-level names to pyrsistent.egg-info/top_level.txt
writing manifest file 'pyrsistent.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
adding license file 'LICENSE.mit'
writing manifest file 'pyrsistent.egg-info/SOURCES.txt'
* Building wheel...
/usr/lib/python3.13/site-packages/setuptools_scm/_integration/deprecation.py:7: UserWarning: setup.cfg: at [metadata]
version = attr: ... is forcing setuptools to override the version setuptools-scm did already set
When using setuptools-scm it's invalid to use setuptools dynamic version as well, please remove it.
Setuptools-scm is responsible for setting the version, forcing setuptools to override creates errors.
  warnings.warn(
[01/18/26 19:30:37] WARNING  toml section missing       pyproject_reading.py:215
                             PosixPath('pyproject.toml'                         
                             ) does not contain a                               
                             tool.setuptools_scm                                
                             section                                            
/usr/lib/python3.13/site-packages/setuptools/dist.py:759: SetuptoolsDeprecationWarning: License classifiers are deprecated.
!!

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

        License :: OSI Approved :: MIT License

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

!!
  self._finalize_license_expression()
running bdist_wheel
running build
running build_py

We're not the only ones

[stlehmann]

So I recon we can go ahead and merge this. @RobertoRoos would you mind adding an entry to the changelog which includes the info that Python 3.8 is no longer supported?

[RobertoRoos]

Done!