You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The contents of the metadata dict would include static metadata, and the hook is expected to replace or add field. At this stage, nothing is stated about the order of the hooks run.
Second stage could be to require version be computed before other hooks. I believe this is the current implantation in hatchling, and is the reason for adding this (hatch-fancy-pypi-readme requires the version pre-computed).
The third stage would be to add topological sorting. This would probably be easier to add after Python 3.9 becomes the minimum required version for most backends. A new hook would be added:
defmetadata_reqiures(
field: str,
settings: Mapping[str, object] |None=None,
) ->list[str]:
"Return fields needing to be computed first"
And backends should topologically sort before running.
The text was updated successfully, but these errors were encountered:
Some hooks may want to access other's metadata. I think this could be supported in three stages:
First, the hooks could be redesigned to modify an existing dictionary of metadata in place. The new hook signature would be:
The contents of the
metadata
dict would include static metadata, and the hook is expected to replace or addfield
. At this stage, nothing is stated about the order of the hooks run.Second stage could be to require
version
be computed before other hooks. I believe this is the current implantation in hatchling, and is the reason for adding this (hatch-fancy-pypi-readme requires the version pre-computed).The third stage would be to add topological sorting. This would probably be easier to add after Python 3.9 becomes the minimum required version for most backends. A new hook would be added:
And backends should topologically sort before running.
The text was updated successfully, but these errors were encountered: