search

wheel-next / ideas

For discussion of ideas for wheel enhancements
1 stars 0 forks source link

Top level package metadata #1

Open flying-sheep opened 1 month ago

flying-sheep commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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