project.licence cannot be a string

[dimpase]

while trying the source build in SageMath, I get

[meson_python-0.18.0] [spkg-install]   User defined options
[meson_python-0.18.0] [spkg-install]     Native files: /home/dima/software/sage-src/local/var/lib/sage/venv-python3.13/var/tmp/sage/build/meson_python-0.18.0/src/.mesonpy-g6b174z0/meson-python-native-file.ini
[meson_python-0.18.0] [spkg-install]     b_ndebug    : if-release
[meson_python-0.18.0] [spkg-install]     b_vscrt     : md
[meson_python-0.18.0] [spkg-install]     buildtype   : release
[meson_python-0.18.0] [spkg-install] 
[meson_python-0.18.0] [spkg-install] Found ninja-1.13.1 at /usr/bin/ninja
                                                
[meson_python-0.18.0] [spkg-install] meson-python: error: Field "project.license" has an invalid type, expecting a dictionary of strings (got "MIT")

indeed, it should be {text = 'MIT'}. I'll make a PR

---

PS. It can be a string, but you need pyproject_metadata >= 0.9.0 !

[rgommers]

It can be a string, see for example

meson-python/tests/packages/license-pep639/pyproject.toml

Line 12 in 8d50078

license = 'MIT OR BSD-3-Clause'

So something else must be going wrong there.

[rgommers]

Probably you are picking up a pyproject-metadata that is too old. Can you please check that?

[rgommers]

You need >=0.9.0: https://pep621.readthedocs.io/en/latest/changelog.html#id2

[dnicolodi]

meson-python requires pyproject-metadata >= 0.9.0

meson-python/pyproject.toml

Line 13 in 8d50078

'pyproject-metadata >= 0.9.0',

thus I don't see how this can happen.

[dimpase]

meson-python requires pyproject-metadata >= 0.9.0

meson-python/pyproject.toml

Line 13 in 8d50078
'pyproject-metadata >= 0.9.0',

thus I don't see how this can happen.

it's not the 1st time I see the version constraint in pyproject.toml ignored by meson. Put the constraint in meson.build, it will work then.

See e.g. contourpy/contourpy#498 (where a constraint had to be put in dependency() call)

[dnicolodi]

it's not the 1st time I see the version constraint in pyproject.toml ignored by meson. Put the constraint in meson.build, it will work then.

Meson does not read pyproject.toml thus I don't have idea of what you are trying to say here. Your build tool is the thing that is responsible to setup the build environment with the correct dependencies. Anyway, how would declare a dependency on a specific version of a Python package in meson.build?

See e.g. contourpy/contourpy#498 (where a constraint had to be put in dependency() call)

This is not about a dependency on a Python package.

[dimpase]

Meson does not read pyproject.toml thus I don't have idea of what you are trying to say here.

I am trying to say that this was happening because we have an old pyproject_metadata in the venv. After bumping it the problem goes away.
If your build does need a version constraint (on pyproject_metadata, in this case), it has to be enforced, but it is not the case. Otherwise, how the hell anyone knows what's wrong, you can't expect users to know the hottest PEPs by heart.

[dimpase]

This is not about a dependency on a Python package.

yes it is, because the build breaks with a too old dependency! (there it's pybind11, here it's pyproject_metadata)

[rgommers]

We already extract the version number for pyproject-metadata, so we could add a check to raise a clearer error message:

meson-python/mesonpy/__init__.py

Lines 87 to 88 in 8d50078

	_PYPROJECT_METADATA_VERSION = tuple(map(int, pyproject_metadata.__version__.split('.')[:2]))
	_SUPPORTED_DYNAMIC_FIELDS = {'version', } if _PYPROJECT_METADATA_VERSION < (0, 9) else {'version', 'license', 'license-files'}

The cost is minor, only that the version is now in two places so may go out of date. But that's never worse than not checking, and easy to keep in sync with a code comment referencing the other usage.

[dnicolodi]

@dimpase How did you install meson-python? meson-python depends on pyproject-metadata >= 0.9.0. pip or uv would have installed the correct version of the dependencies in the venv.

We already extract the version number for pyproject-metadata, so we could add a check to raise a clearer error message:

Someone needs really to try hard to be able to install meson-python with a too old version of pyproject-metadata. I guess that if they do, they know what they are doing, and I'm not going to try to stop them. Otherwise we need to start checking the versions of all dependencies, and all transitive dependencies. I don't think that it makes any sense to do that, given that package metadata has been created to avoid package authors to have to do exactly this.

[dimpase]

How did you install meson-python?

I live in a fully vendored hell called SageMath, that's how... Our truly wonderful tooling does not check versions in pyproject.toml files.

[dnicolodi]

@dimpase If the tooling you use does not enforce dependencies for you, it is your responsibility to make sure that the correct dependencies for the packages you vendor are provided. meson-python specifies the correct dependencies in the right places. I don't think there is anything to fix here.