pyproject.toml: validation error since setuptools 61.2.0

https://setuptools.pypa.io/en/latest/history.html mentions that pyproject.toml needs to be now compliant with validate-pyproject==0.6.1

When running the tool on the current pyproject.toml

validate-pyproject pyproject.toml 
[ERROR] `project.license` must be valid exactly by one definition (2 matches found):

    - keys:
        'file': {type: string}
      required: ['file']
    - keys:
        'text': {type: string}
      required: ['text']

This makes building wheels on setuptools 61.2.0+ impossible

[priv-kweihmann]

Thanks again for the feedback - I played around a bit with hatchling and was able to come up with the needed code to make it work on the yocto end of things - so there’s nothing to be done here.

I personally believe it was a bad idea to strictly require packages to pass validate-pyproject, especially when it is still noted as an experimental project that currently has not widened their scope to fully encompass PEP compliant backends such as Hatchling. If we are talking about more complex packages that utilize C modules and such, there is no way that they will chose flit-core, they will chose something like Hatchling. Yocto will be left behind in such cases.

I’m totally with you on this one - basically this move makes a ton of packages fail for no real reason.

I will close the issue

[facelessuser]

Here’s the thing. We are trying to fix issues that are not issues here. I use hatchling instead of flit-core because of the ability to use dynamic classifiers and such. Also, Hatchling is compliant with many of the recent PEPs regarding packaging:

Project metadata is based entirely on PEP 621/PEP 631, the build system is compatible with PEP 517/PEP 660, versioning uses the scheme specified by PEP 440, dependencies are defined with PEP 508 strings, and environments use virtualenv.

Not only that, Hatchling is maintained by the PYPA (Python Packaging Authority) just like flit-core. They both aim to solve different issues. If you have a very simplistic, non-dynamic setup, then flit-core is a fine choice: https://flit.pypa.io/en/latest/rationale.html#why-use-flit. But, if you have a more complex environment that requires more dynamic options or you are building a non-pure Python package, such as a package that links with C code, flit-core cannot be used.

Even other PYPA projects have started to use Hatchling using the same notation I do with Licenses, see pipx as an example: https://github.com/pypa/pipx/blob/main/pyproject.toml#L9.

I support numerous packages. I selected Hatchling because some of my projects have some complex steps. SoupSieve is less complex, but I do use some dynamic classifiers to make my life easier, but packages like Rummage require me to build language files for translations during installation, and flit-core doesn’t cut it. I have no intention to use more than one build backend on various projects either, so I’ve chosen Hatchling for all of my projects.

I first encountered the issue with the Yocto/bitbake build system, after there was an upgrade from setuptools 58.x to 62.x. As of now yocto only supports flit-core as a buildsystem (not sure if hatchling will be supported in the future).

I understand, but yocto currently has a very narrow view of the packaging ecosystem right now. I admit that hatchling is kind of new, so I don’t expect that every system is prepared for Hatchling right now, but there will be more packages migrating to Hatchling outside of the packages I maintain. Big packages like Tox are started to move towards it as well. If yocto doesn’t support it now, I would advise that they strongly consider it moving forward.

-license = "MIT"
+license = { file = "LICENSE.md" }

which works with hatchling and the yocto implementation.

Hatchling’s documentation on licenses is found here: https://hatch.pypa.io/latest/config/metadata/#license. While what you’ve suggested may not cause the validator to fail, I’m not 100% sure that it’ll package and note things appropriately via Hatchling if done this way.

I personally believe it was a bad idea to strictly require packages to pass validate-pyproject, especially when it is still noted as an experimental project that currently has not widened their scope to fully encompass PEP compliant backends such as Hatchling. If we are talking about more complex packages that utilize C modules and such, there is no way that they will chose flit-core, they will chose something like Hatchling. Yocto will be left behind in such cases.