Inconsistent requires_dist behavior

[astrofrog]

Describe the bug

The following packages both define dependencies in a setup.cfg file:

https://pypi.org/pypi/astropy/json (link to setup.cfg)

https://pypi.org/pypi/glue-vispy-viewers/json (link to setup.cfg)

However, while glue-vispy-viewers seems to have the correct dependencies in requires_dist in the JSON meta-data, the same field is empty for astropy.

Expected behavior

I would have expected either both cases to work, or neither.

To Reproduce

The URLs above should demonstrate the issue.

Additional context

I have seen in one place someone say something about the order in which packages are uploaded (wheels vs source) but for a package like astropy, where the wheels take a while to build and upload and are uploaded separately, it's difficult to upload the wheels first. Many developers are also not going to be aware of this behavior. So if this is indeed the issue, then if the source file is uploaded first, when the first wheel is uploaded, requires_dist should be updated if it was null previously?

[di]

Three things are happening here:

1. the first distribution uploaded for a new version sets the metadata for that version;
2. the metadata for a version is immutable;
3. source distributions don't have Requires-Dist in their metadata.

This means that if you upload a source distribution of astropy first, it will always lack requires_dist, regardless of how you set this information, or what you upload afterwards.

The first and second points are unlikely to change, but it seems reasonable that a source distribution which deterministically sets install_requires via setup.cfg could include Requires-Dist in it's metadata. I've filed pypa/setuptools#1805 to investigate.

[astrofrog]

@di - thanks for the clear explanation! I agree that it would be ideal if Requires-Dist could get set for deterministic dependencies in setup.cfg.

[di]

No problem! Regardless of the outcome of that issue, I don't think there's anything that should change on PyPI's side of things here, so this issue can probably be closed.