Standard APIs for PEP 751?

[woodruffw]

Hey all!

I'm opening this for discussion/to gauge interest.

TL;DR: I think it would be nice to have an "official" API for PEP 751 in packaging. This would ease/accelerate the adoption curve for Python packaging tooling that already uses packaging, since they could import existing APIs that are consistent across the entire ecosystem rather than doing their own at-hoc/at-point deserialization/modeling.

Some related thoughts:

• The existing models in pip's pylock.py might be a good starting point for this: https://github.com/pypa/pip/blob/46c482f70ad41d0327c20803a46857a82dc6b6bd/src/pip/_internal/models/pylock.py

I'm curious what people think about this! CCing @brettcannon and @pradyunsg and @sbidoul in particular since I know you've all been involved in PEP 751 and its adoption 🙂

+CC @di @sethmlarson as other interested parties 🙂

[di]

Agreed! Not sure if this issue is a coincidence but @sbidoul just asked about this very thing here.

I think APIs for creating & reading pylock files would probably make sense to included here and the model currently in pip seems like a good starting point.

[woodruffw]

Agreed! Not sure if this issue is a coincidence but @sbidoul just asked about this very thing here.

I completely missed that! Apologies to @sbidoul, looks like you're way ahead of what I was thinking in terms of APIs.

[sbidoul]

models/pylock.py in pypa/pip#13369 is indeed a more advanced starting point.

• the models are complete
• the dataclasses are immutable and kw_only
• they are fully typed
• it has to_dict and from_dict compatible with the toml serialization
• from_dict validation is fairly extensive
• I purposely left out writing toml as the exact serialization format is more complex and there are decisions to be made about which tables to inline, etc. But that can eventually be added later.

If packaging maintainers think that approach is on the right track, I can open a PR here for review.

[brettcannon]

I personally assumed that we would end up with something like packaging.metadata; basically a TypedDict when the TOML is parsed and then a more structured one that build off the dict. But I'm also happy with skipping straight to the structured output like what @sbidoul has in pip since it's not exactly controversial as it closely mirrors the TOML structure and we shouldn't have messy data out there to need raw data access for.

[brettcannon]

One thing to keep in mind is future changes to the spec, both minor changes and new versions. That probably means versioning things.

[sbidoul]

I created #900.

One thing to keep in mind is future changes to the spec, both minor changes and new versions. That probably means versioning things.

Good point. I made from_dict a function instead of a class method so it can eventually instantiate different classes depending on the version discovered.