Hatch-vcs metadata hook fails when run on sdist tarball

[jorisroovers]

When using the metadata hook and doing a hatch build -t wheel build from an sdist tarball that was previously built using hatch-vcs, the metadata hook will attempt to access version control to determine the commit_hash variable:

https://github.com/ofek/hatch-vcs/blob/0c9289da346efbee80d1188e3a56019e23761669/hatch_vcs/metadata_hook.py#L39

This will cause hatch-vcs to crash since there’s no version control present in the sdist tarball.

Details on how to reproduce for my project gitlint: https://github.com/jorisroovers/gitlint/issues/460

Discussed with @ofek in https://github.com/jorisroovers/gitlint/issues/367

[jorisroovers]

Had a closer look at this and was thinking hatch-vcs could read a fallback commit_hash from file in case git is unavailable (or raises an error). This commit_hash would be stored by hatch-vcs itself in case git is available.

So something like this (pseudo-code):

def get_commit_hash(self):
    try:
        commit_hash = vcs_utils.get_commit_hash(self.root)
        store_commit_hash(commit_hash, fallback_file)
    except:
        commit_hash = read_commit_hash(fallback_file)

# How it's used:
'commit_hash': lambda *args: get_commit_hash(),

In this scenario, the question becomes what the location and format of fallback_file would be to store commit_hash.

• I thought PKG-INFO but I didn’t find a good field for it in the spec.
• I found a section on Direct URL Data Structure but am unsure how to use it or whether hatch-vcs replaces this capability.
• pyproject.toml / hatch.toml in a new table like [tool.hatch.metadata.hooks.vcs.info] but I don’t like the idea of rewriting that file
• An additional metadata file that hatch-vcs creates, probably structured (toml/json/?), but also not very clean.

Any thoughts?

[ofek]

Metadata is now persisted for dynamic fields properly as of Hatchling v1.22.0