Top level package metadata

[flying-sheep]

top_level.txt should be standardized. importlib.metadata.packages_distributions() relies on it for a quicker lookup.

See also: https://discuss.python.org/t/record-the-top-level-names-of-a-wheel-in-metadata/29494

---

Sure, it’s possible to infer that from the manifest, but wouldn’t it be useful to have it in the metadata?

If this becomes part of the wheel-next standard, we can also circumvent the issue of “there is no difference between the metadata of a package that contains no top-level Python packages and a package that doesn’t declare them”: no metadata field means no top level packages, so don’t try to infer them.

[ethanhs-nv]

Oh, sorry I missed this issue! I seem to have not been subscribed to new issues, but have now fixed that.

As for standardizing top_level.txt, I do think having some standard mechanism to declare what top level packages are provided by a wheel is reasonable. I will make sure to include some language about this in my Wheel 2 format specification.

[merwok]

Could modules and scripts be included? If one of the goals is to discover file conflicts, then scripts are also a source of them.

[flying-sheep]

Oh yeah terminology: Yes, I thought about both toplevel packages (…/site-packages/name/__init__.py) and toplevel import modules (…/site-packages/name.py).

Regarding scripts: They are already listed in the metadata as console_scripts entry points. If you mean something else, you need to specify what you mean.

[merwok]

I mean scripts, plain scripts, what distutils has always called scripts.
Executable text files (python or other).