Skip to content

Conversation

@dnicolodi
Copy link
Member

pyproject-metadata 0.9.1 requires packaging 23.2 or later, but does not record this dependency, see pypa/pyproject-metadata#239

This becomes a problem when meson-python is installed on a platform where packaging 19.0 (the current minimum required version) is installed. This does not trigger an update of packaging to the latest available version and results in run time errors, see scipy/scipy#22840 (comment)

This could be fixed by a new release of pyproject-metadata, but we do not want meson-python to depend on very recent releases. meson-python supports pyproject-metadata 0.9.0 or later and still carries some work-arounds for issues in that release.

The least invasive and most effective solution is to bump the packaging requirement for meson-python to 23.2. This also fixes the (intentional) use of API available only with packaging 23.2 or later in the meson-python tests.

Fixes #733.

@rgommers rgommers added the maintenance Regular code improvements that are not new features nor end-user-visible bugs label Apr 25, 2025
@rgommers rgommers added this to the v0.18.0 milestone Apr 25, 2025
Copy link
Contributor

@rgommers rgommers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@rgommers
Copy link
Contributor

Oh actually, there's a test dependency ('packaging >= 23.1') further down in pyproject.toml that can be removed.

@dnicolodi
Copy link
Member Author

I knew the use of the newer packaging API was intentional in the tests, but I forgot that we actually recorded that in the test dependencies. I'll remove it. Maybe it is also time to use a dependency group for the test dependencies instead of extra dependencies. Both pip and uv should have support for dependency groups nowadays.

pyproject-metadata 0.9.1 requires packaging 23.2 or later, but does not record
this dependency, see pypa/pyproject-metadata#239

This becomes a problem when meson-python is installed on a platform where
packaging 19.0 (the current minimum required version) is installed. This does
not trigger an update of packaging to the latest available version and results
in run time errors, see scipy/scipy#22840 (comment)

This could be fixed by a new release of pyproject-metadata, but we do not want
meson-python to depend on very recent releases. meson-python supports
pyproject-metadata 0.9.0 or later and still carries some work-arounds for
issues in that release.

The least invasive and most effective solution is to bump the packaging
requirement for meson-python to 23.2.

This also allows to remove a more restrictive packaging version requirement
used for the tests optional dependencies, due to the use of API available only
with packaging 23.1 or later in the meson-python tests.

Fixes mesonbuild#733.
@dnicolodi
Copy link
Member Author

Turns out that a release of pip that supports dependency groups is scheduled for tomorrow, so we are not there yet. I don't think that switching to uv just for this is worth the trouble. The conversion to dependency groups will have to wait a tiny bit more.

@dnicolodi dnicolodi force-pushed the fix-packaging-ver-requirement branch from ae69dd6 to fa5a5f9 Compare April 25, 2025 16:38
@dnicolodi dnicolodi merged commit 991985d into mesonbuild:main Apr 25, 2025
39 checks passed
@rgommers
Copy link
Contributor

Turns out that a release of pip that supports dependency groups is scheduled for tomorrow, so we are not there yet. I don't think that switching to uv just for this is worth the trouble. The conversion to dependency groups will have to wait a tiny bit more.

Agreed, best to not be an early adopter for that, good to wait a while until versions of pip et al. that support it have been available for 6-12 months so devs are likely to have them installed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

maintenance Regular code improvements that are not new features nor end-user-visible bugs

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Incorrect lower bound on packaging versions supported

2 participants