I’ve just started a discussion at Enforcing consistent metadata for packages to collect information on things we need to consider if we want to enforce a rule that metadata needs to be consistent for all instances of a given version of a package. People who have participated in this thread might want to take a look, as I expect a lot of the same considerations to apply in that discussion as came up here.
1 Like
Just FYI there is another bug reported to Hatchling about this:
The oversight on my part is that there is not a one-to-one correspondence between project fields and core metadata i.e. entry points are stored in a separate file so when building wheels from source distributions there are no more entry points if they happen to be dynamic. Therefore, I have to add an additional criteria to the first step to only copy fields that correspond to core metadata and retain the ability to dynamically define entry points.
I’m fixing now.
Cool. I may be missing something, but in that case the entry points would be dynamic in pyproject.toml but not present (and hence not “static”) in PKG-INFO, so (1) doesn’t apply. So there’s no change needed to my statement - is that right?
The issue is that the implementation removes the internal dynamic array elements thereby precluding hooks from executing. The solution is to only remove elements from the dynamic array if an element actually corresponds to something that would show up in PKG-INFO.