`3.29.1` is broken on Python 3.7 due to `importlib_metadata` backport

[stephen-hansen]

Hi, I see that there have been recent changes made to drop Python versions <3.7, but my understanding from reading here is that Python 3.7 should still be supported by this cmake package.

cmake-python-distributions/pyproject.toml

Line 28 in 557c82a

requires-python = ">=3.7"

This morning I saw a number of 3.7 pipelines fail due to ModuleNotFoundError: No module named 'importlib_metadata'. I believe the same issue was reported in #472, but the patch only fixed the error for Python versions 3.8-3.9.

On my end we're fine pinning the cmake package to an earlier version and/or adding the missing importlib-metadata dependency in our projects, but it would be appreciated if importlib-metadata could be added as a project dependency for Python 3.7 as suggested in the original issue above.

[stephen-hansen]

Ah, it looks like the importlib-metadata dependency was there in pyproject.toml at one point, but was removed in 215cc1c. But it looks like the __init__.py file still references this package.

cmake-python-distributions/src/cmake/__init__.py

Lines 8 to 11 in 557c82a

	if sys.version_info < (3, 8):
	from importlib_metadata import distribution
	else:
	from importlib.metadata import distribution

[stephen-hansen]

Also seeing some 3.7 pipelines pass but those appear to be pulling importlib-metadata from pytest not from cmake.

[YunchuWang]

+1, it starts breaking our pipeline since yesterday https://github.com/Azure/azure-functions-python-worker/actions/runs/8637840975/job/23680955694?pr=1455 for all 3.7 tests.

[JeanChristopheMorinPerso]

I created a PR to add the missing dependency: #490

[jcfr]

Thanks for the detailed report and fix 🙏 , once the CI associated with #490 completes, changes will be integrated and a new patch release will be created 🚀

Thanks for the patience ⏳

[jcfr]

3.29.1.1¹ has been tagged, once the associated GitHub workflow² completes, the packages will be available for download.

Update: Release of 3.29.2 has also been initiated:

• Update to CMake 3.29.2 #491

---

@henryiii I am then thinking to yank 3.29.1 from PyPI and update the published releases so that 3.29.1 effectively reference 3.29.1.1 tag. How does this sound ?

Footnotes

1. https://github.com/scikit-build/cmake-python-distributions/tree/3.29.1.1 ↩

2. https://github.com/scikit-build/cmake-python-distributions/actions/runs/8653766199 ↩

[henryiii]

You need to update the version in pyproject.toml too if you do a patch release. I'd have just yanked .1 and pushed .2 when it's ready.

[jcfr]

I cancelled 3.29.1.1 workflow, will remove the corresponding tag and proceed as you suggested by yanking 3.29.1

[jcfr]

[henryiii]

I've tagged 3.29.2 with the fix. I'll make a release when it's done building (unless I forget). It'll show up on PyPI either way.

[stephen-hansen]

Thanks for the fast turnaround!

[jcfr]

Thanks @henryiii for finalizing the release 🙏