Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CI: run tests with pyproject-metadata 0.8.0 #612

Merged
merged 4 commits into from
Apr 18, 2024

Conversation

dnicolodi
Copy link
Member

No description provided.

@dnicolodi dnicolodi force-pushed the ci-pyproject-metadata-08 branch 3 times, most recently from fac5b2d to ba14bfd Compare April 15, 2024 20:42
@rgommers
Copy link
Contributor

Once pyproject-metadata 0.8.0 is released, should we tweak CI to ensure we have at least one job with the oldest supported version, and the rest continue defaulting to the latest version?

@rgommers rgommers added the CI Continuous Integration label Apr 17, 2024
@dnicolodi
Copy link
Member Author

I'm debating whether once pyproject-metadata 0.8.0 is released we should keep compatibility with older releases or require 0.8.0 with the next (intended as 0.17.0, not the upcoming 0.16.0) meson-python release and drop the workaround for the bugs fixed in pyproject-metadata (see #613 for what these are). In the past we updated the required minimum version quite aggressively. I don't know if we should be a bit more conservative this time around, given that meson-python is now a build dependency for more packages.

@rgommers
Copy link
Contributor

I think we can still bump fairly aggressively if there's a significant benefit (bug fix we need etc.). We want to be a bit more conservative on average though probably. The main issue occurs for distros that don't have build isolation I think. They tend to unvendor vendored deps, so if we bump the lower bound then we're bumping it for other tools that use pyproject-metadata as well.

pyproject-metadata is quite small and well-behaved, so we probably can't cause too much pain. I was in the process of writing "it's worse for our dependency on packaging" - and then realized that we don't actually express that dependency. I don't have a memory of us discussing that before - but that seems wrong to me. We seem to rely on pyproject-metadata continuing to depend on it. WDYT about adding it with a reasonable lower bound (in the 19.0-22.0 range probably)?

@dnicolodi
Copy link
Member Author

I didn't realize either that we don't have an explicit dependency on packaging. I think it is an oversight and not a decision. We definitely should add it. pyproject-metadata requires packaging >= 19.0. AFAIK we don't depend on anything introduced in later versions, so we should add the same constraint.

@rgommers
Copy link
Contributor

Okay, I'll open a separate PR now.

@dnicolodi dnicolodi force-pushed the ci-pyproject-metadata-08 branch 3 times, most recently from e678453 to f170513 Compare April 18, 2024 08:20
@dnicolodi dnicolodi changed the title CI: run tests with pyproject-metadata 0.8.0rc1 CI: run tests with pyproject-metadata 0.8.0 Apr 18, 2024
@dnicolodi dnicolodi force-pushed the ci-pyproject-metadata-08 branch 2 times, most recently from c9e252b to fda7dad Compare April 18, 2024 08:30
pyproject-metadata 0.8.0 has been released, keep one CI job testing
with the oldest supported version to ensure regressions are not
introduced.
mypy is always run with the latest version of the dependencies.
@dnicolodi dnicolodi merged commit d940353 into mesonbuild:main Apr 18, 2024
41 checks passed
@rgommers rgommers added this to the v0.17.0 milestone Apr 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI Continuous Integration
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants