Extra files in .dist-info?

This came up in stub packages with overlapping namespaces overwrite their METADATA.toml · Issue #11047 · python/typeshed · GitHub : In typeshed when distributing type distributions, we like to include the METADATA.toml file (confusingly unrelated to the METADATA file in .dist-info), which contains information for our automated builds in the generated types- distribution. Currently, we add the file to each -stubs package inside the distribution, but that is a bit of a hack and is problematic for shared namespaces.

The packaging docs are a bit ambiguous on whether it’s allowed to add additional files to .dist-info:

This .dist-info directory may contain the following files, described in detail below:

Would it be permissible to add extra files to the directory? (Although we should probably not call it METADATA.toml there to avoid confusion.) If so, what’s the best way to do it when using setuptools? Probably just add the file to the generated .tar.gz/.whl file using tar/zip?

1 Like

This wouldn’t be sufficient for wheels. Wheels are supposed to include a list of all files and their hashes in *.dist-info/RECORD, so you’d also have to update that file as well.

1 Like

Not sure if it’s the best way to this, but… I’m using a custom egg_info command in pyobjc-core that adds some files to the egg-info/dist-info directory during the build,

Depending on your code structure you might be able to use an “egg_info.writers” entry-point for this (the code in pyobjc is old and works around an ancient bug in distribute(!)).

1 Like

There have been discussions on this in the past (sorry, I don’t have links right now). While there’s no standard that stops you adding new files, there’s a risk that if you do, then a future standard might claim the name you used for a different purpose. Ideally, we should have reserved something like a tool subdirectory for application use, but we didn’t.

As a practical approach, I’d be inclined to suggest putting all of the files you want to add in a subdirectory named (say) _typeshed, to minimise the risk of collisions. And then, if a standard does emerge, all you’d have to do is rename the one directory.


If you use Hatchling you can set shared-data. Project Jupyter wrote a blog post about using that for their extension ecosystem switch to Hatchling and there should be links inside.