Metadata 2.2 and 2.3

[konstin]

This is an attempt to finish #11380 and unblock uploading metadata version 2.2 and 2.3, which i'd like to have for maturin and my resolver prototype. I've applied all review comments and added a check that dynamic isn't used <2.2.

Fixes #9660, fixes #11526, closes #11380.

[ewdurbin]

The only thing I would want to see to call this shippable is a test that exercises the storage/retrieval of Dynamic fields.

I think this could be added to tests.unit.forklift.test_legacy:test_successful_upload or maybe more favorably built out as an additional test tests.unit.forklift.test_legacy:test_successful_upload_metadata_2_3.

Just some assertions of the resulting value of Release.dynamic

[ewdurbin]

Ported outstanding comments from #11380

[ewdurbin]

The only thing I would want to see to call this shippable is a test that exercises the storage/retrieval of Dynamic fields.

I think this could be added to tests.unit.forklift.test_legacy:test_successful_upload or maybe more favorably built out as an additional test tests.unit.forklift.test_legacy:test_successful_upload_metadata_2_3.

Just some assertions of the resulting value of Release.dynamic

Missed that Provides-Extra also needs to be stored. Similarly a test for storage/retrieval of that data would be great to see.

[dstufft]

We probably want to expose this value in the existing JSON API, XMLRPC API, and.. .maybe in the UI? Not sure.

[ewdurbin]

Hi @konstin, wanted to check in and see if you planned to continue work on this. If not I'm happy to pick it up and continue on with this PR.

[ewdurbin]

We probably want to expose this value in the existing JSON API, XMLRPC API, and.. .maybe in the UI? Not sure.

@dstufft, Which value, Provides-Extra?

[dstufft]

Dynamic, and whatever other fields are new

[ewdurbin]

We probably want to expose this value in the existing JSON API, XMLRPC API, and.. .maybe in the UI? Not sure.

I will implement this in JSON API, but won't touch XMLRPC. There's nowhere we would expose this on the XMLRPC that isn't currently slated for deprecation. If people want programatic access to this data, they should retrieve it from JSON.

I'll give a smol attempt to render it in the web UI, but consider it beyond scope of this PR.

[ewdurbin]

Low budget display if available on project pages:

[ewdurbin]

@di @dstufft @miketheman, this is good for a review pass.

implemented changes

[konstin]

Sorry for responding so slow and thank you for addressing all the review comments!

[konstin]

Should i rebase this?

[di]

@konstin Yes please!

[konstin]

rebased and updated with the changes from main

[konstin]

Is there a way to tell the linters and formatters (or the make commands in general) to not lint my local .venv?

[konstin]

I tried to address all review comments, i had to change some of the suggested changes though to make it work

[miketheman]

Is there a way to tell the linters and formatters (or the make commands in general) to not lint my local .venv?

Tough to say exactly, since I don't use the same .venv style, as most development happens inside a container. You might want to add a .venv directory entry to https://github.com/pypi/warehouse/blob/main/.dockerignore so that it's not added to the container - give that a shot and if it works, feel free to add that to its own PR.

[di]

@konstin FYI, this PR has linting/testing errors (my most recent suggestion above was missing imports).

[konstin]

Thanks, i totally missed that CI failure!

[di]

LGTM, is blocked on merging #15452 first.

[di]

Leaving this unmerged a bit longer to give other @pypi/warehouse-committers a chance to review.

[konstin]

🎉

Thanks for the reviews and guidance!