Prevent Version.from_git from climbing too high in path

[aantn]

I am using dunamai as follows:

version = dunamai.get_version(
        "holmes-gpt",
        first_choice=lambda: dunamai.Version.from_git(
            pattern=dunamai.Pattern.DefaultUnprefixed, path=this_path
        ),
    )

My goal is for dev clones from git to report the version according to git details, and for that to take precedence over pyproject.toml metadata.

This works for the clone scenario. However if the package is pip installed, I receive very strange results, as the git version takes precedence over the pyproject.toml version, and my Python package is installed to /opt/homebrew/lib/python3.12/site-packages/holmes/ which has no .git, yet dunamai reads a .git from /opt/homebrew/ which is obviously wrong.

I'm not sure how to fix.

[mtkennerly]

Hi! Yeah, that's a tricky combination. Dunamai just checks if it's in a Git repository by running git status. I did find GIT_CEILING_DIRECTORIES, but that takes a list of absolute paths, not a depth number. Maybe we could have the option to look for the .git folder instead with a specified depth.

Since holmes-gpt uses Poetry, would you be open to using poetry-dynamic-versioning? It uses Dunamai, but solves this by embedding the version statically during poetry build.

For dev clones:

• Poetry commands will use the dynamic version if the user has poetry-dynamic-versioning installed (except poetry run and poetry shell, because of this issue).
• If you install the package directly from the code using a PEP 517 frontend (e.g., pip install .), then it will install with the dynamic version as long as you've configured poetry-dynamic-versioning in the build-system section of pyproject.toml.
  • Poetry itself ignores the build-system, which is why you'd also need the plugin installed when running Poetry commands.

[aantn]

I looked into poetry-dynamic-versioning, but am on the fence as this is all getting rather complex for a minor requirement. For now, I have just copied Dunamai's idea of reading archival data into my own implementation (see here if curious) and I am putting the .git_archive file inside the installed python module so that it is accessible after pip install.

I am closing as this solves my own problem. In any event, thank you for the help and without Dunamai I would not have known about the ability to generate metadata during git archive. The readme and docs are wonderful btw.