Support for PEP 794 (import name metadata)

[rgommers]

PEP 794 adds import-names and import-namespaces keys under [project] in pyproject.toml. Support for that just landed in pyproject-metadata, see pypa/pyproject-metadata#260. Once that is released, we can add support.

EDIT: prerequisites are support in:

• pyproject-metadata (0.10.0, see feat: PEP 794 support (METADATA 2.5) pypa/pyproject-metadata#260)
• packaging (26.0, see New release for PEP 794 and packaging.pylock pypa/packaging#950)
• PyPI (see Support Core Metadata 2.5 (PEP 794, Import-Name, Import-Namespace) pypi/warehouse#19083)
• twine (no issue yet)

[dnicolodi]

What is required from the meson-pythons side to support PEP 794? AFAIU PEP 794 is just about adding some metadata fields and those are handled by pyproject-metadata without meson-python intervention. Am I missing something? Or do you intend that we should add this metadata to the meson-python package itself? In this case I don't think we should: meson-python does not have a public API and the fact that a mesonpy module exists is a pure implementation detail.

[eli-schwartz]

That -- and also, the RECORD file contains all the information in question already.

As I understand, the PEP only adds support for projects which use pth files to provide import names that don't correspond to any on-disk files. On-disk files "have to" be importable either way, so RECORD is intrinsically a valid subset of import names.

I'm not actually aware of any project other than https://github.com/pypa/setuptools that benefits from the distinction (it exposes distutils via pth hacks). But maybe I am missing something.

[rgommers]

The implementation may just work out of the box with the newest version, but there are a couple of things to do I think:

• The PEP bumps Core Metadata version to 2.5, we should add a test using the new field and ensuring we get that version.
  • Can be an update to an existing test by adding one line and updating the reference Metadata-Version in the corresponding test.
• It will require a newer version of pyproject-metadata; we're supporting a larger range of versions. So we should check the version of we see the pyproject.toml field used, and raise a clear exception when pyproject-metadata is too old. We've implemented this kind of check several times before for both pyproject-metadata and packaging.

Re what it brings: it's not super impactful indeed, but it will help IDE/tool authors. Compared to deriving it from RECORD, the PEP points out "Putting this metadata in the core metadata means the data is (potentially) served by an index server, independent of any sdist or wheel."

I'm not personally in need of what this PEP offers, but some users will probably be - either way, let's just be good citizens here and support all packaging PEPs we can:)

[rgommers]

I don't think we should: meson-python does not have a public API and the fact that a mesonpy module exists is a pure implementation detail.

💯 agreed. I wasn't suggesting that.

[eli-schwartz]

Re what it brings: it's not super impactful indeed, but it will help IDE/tool authors. Compared to deriving it from RECORD, the PEP points out "Putting this metadata in the core metadata means the data is (potentially) served by an index server, independent of any sdist or wheel."

Sure, and that was a personal choice of the PEP author to insist on reinventing the wheel (as it were) instead of leaning on prior art and being compatible with all/most projects automatically via a trivially server-side API update. Although maybe that is a good thing.

Because at any rate, if it's only useful for IDE tooling then there is no justification for adding it to projects that don't allow IDEs to be aware of their internal API. In fact there's an extremely strong motivation for such projects to fully reject the PEP, since it would be a strong negative to such projects if IDEs could help users figure out how to import a private internal API. The PEP doesn't really communicate this to users. :( Perhaps the docs here could do so instead.

[rgommers]

then there is no justification for adding it to projects that don't allow IDEs to be aware of their internal API

Agreed. Only the top-level public namespace(s) should be added.