I don’t think it is, the PEP explicitly describes this use-case.
Finally, this PEP is meant for (…) those doing analysis on a source checkout.
Given this is a supported use-case, I think with Brett’s changes it is now clear enough that the fields are dynamic. So the question we need to ask here is if this should be a supported use-case? I think maybe we should remove it as it gives the wrong impression. The usefulness of this is pretty low anyway, you can only rely on
name being present.
name being required is already a tradeoff, backends like
mesonpep517 would probably just want to fetch this information from an external source. It is not a big deal, but would be a nice to have . If we remove the requirement, we now support this use-case, and mitigate the problem of people relying on static metadata for external tools.
People are gonna use this for static metadata either way, I think it’s better to not validate their use-case. It would still be possible, the PEP cannot ban this practice, but it can make it clear it was not design for it.
If we choose to keep this maybe we should add a reference to
prepare_metadata_for_build_wheel, something like "this PEP can be used for this but what you probably really want to do is use