Versioning own pre-commit hook with dynamic versioning

[MarshalX]

Hi! One of my maintained projects provides pre-commit hook written in Python and managed by Poetry. The versioning is controlled with poetry-dynamic-versioning. Thank you for the plugin and dunamai! The overall pipeline works amazingly except pre-commit hook installation... Let me explain.

Example of .pre-commit-hooks.yaml:

- id: myAwesomeHook
  name: myHook
  language: python
  entry: my_cli
  args: [ 'doMagic', ]

In such case, pre-commit will try to install this hook as Python one. The behavior is git clone + run pip install .. Unfortunately, according to the source code of “pre-commit”, it uses “--depth 1” option by default

Code: https://github.com/pre-commit/pre-commit/blob/c25ea47cf78b42da8fd403c435f156b056aaeb38/pre_commit/store.py#L191-L206

It falls back to a full history clone on errors. I don’t figure out which errors are possible here yet. Of course, I can try to raise CalledProcessError exception somehow in pre-commit's code to fall back to the full history clone, but it's a bit tricky than committing the version to git...

As you can see it looks completely incompatible to have a pre-commit hook with the dynamic version from git tags. They even don't do "git archive"...

My question is what could you suggest to make it work? The last notes

• I really don't want to switch back from dynamic versioning
• I am thinking about creating pre-commit hook to commit the version to the file, especially for my own hook (like this). But it will lead to the wrong version order between pull requests
• I am thinking about using a different kind of pre-commit hook instead of a Python one. Something already bundled with the version... Like executable file. But it will lose support of "pre-commit autoupdate"

[MarshalX]

The current solution:

if __version__ == '0.0.1.dev1':
    # If CLI was installed from shallow clone, __version__ will be 0.0.1.dev1 due to non-strict versioning.
    # This happens when installing CLI as pre-commit hook.
    # We are not able to provide the version based on Git Tag in this case.
    # This fallback version is maintained manually.

    # One benefit of it is that we could pass the version with a special suffix to mark pre-commit hook usage.

    import os
    version_filepath = os.path.join(os.path.dirname(__file__), 'pre-commit-hook-version')
    with open(version_filepath, 'r', encoding='UTF-8') as f:
        __version__ = f.read().strip()

It will be awesome to describe the fallback version file in pyproject.toml during the wheel build using poetry-dynamic-versioning's backend. But maybe too specific case

[mtkennerly]

Hi! I don't have a good solution offhand, but I found some related issues while looking into this:

• pre-commit hangs with v2.8.2 pylint-dev/pylint#4505
• install-hooks hangs indefinitely - git shallow clone pre-commit/pre-commit#1924
• Pre-commit shallow cloning strategy fails to grab the tag (git itself does) pre-commit/pre-commit#2610

I also found this other workaround that triggers a fetch while building the package: Kintyre/ksconf@cb07437 . Maybe we could add support for something like this in the plugin.

From my perspective, the best solution would be if pre-commit allowed opting into full clones, but it looks like they may not be open to adding that option, given this comment: pre-commit/pre-commit#1924 (comment) .

For reference, is this causing any errors or misbehavior? When I use pre-commit, I just look at the rev field, not at the actual installed version. I know it wouldn't be ideal to ignore the 0.0.1.dev1, but I just want to get a sense of how much impact it has here.

[MarshalX]

For reference, is this causing any errors or misbehavior

If strict mode is enabled it will throw an exception during installation and pre-commit hook will not work at all

here are my settings:

[tool.poetry-dynamic-versioning]
# poetry self add "poetry-dynamic-versioning[plugin]"
enable = true
strict = false
bump = true
metadata = false
vcs = "git"
style = "pep440"

here is the exception

[INFO] Once installed this environment will be reused.
[INFO] This may take a few minutes...
An unexpected error has occurred: CalledProcessError: command: ('/Users/ilyasiamionau/.cache/pre-commit/repovbqic_el/py_env-python3/bin/python', '-mpip', 'install', '.')
return code: 1
stdout:
    Processing /Users/ilyasiamionau/.cache/pre-commit/repovbqic_el
      Installing build dependencies: started
      Installing build dependencies: finished with status 'done'
      Getting requirements to build wheel: started
      Getting requirements to build wheel: finished with status 'done'
      Preparing metadata (pyproject.toml): started
      Preparing metadata (pyproject.toml): finished with status 'error'
stderr:
      error: subprocess-exited-with-error
      × Preparing metadata (pyproject.toml) did not run successfully.
      │ exit code: 1
      ╰─> [22 lines of output]
          Traceback (most recent call last):
            File "/Users/ilyasiamionau/.cache/pre-commit/repovbqic_el/py_env-python3/lib/python3.8/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 353, in <module>
              main()
            File "/Users/ilyasiamionau/.cache/pre-commit/repovbqic_el/py_env-python3/lib/python3.8/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 335, in main
              json_out['return_val'] = hook(**hook_input['kwargs'])
            File "/Users/ilyasiamionau/.cache/pre-commit/repovbqic_el/py_env-python3/lib/python3.8/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 149, in prepare_metadata_for_build_wheel
              return hook(metadata_directory, config_settings)
            File "/private/var/folders/yc/cr3274bj5153d79w7mk2ty1c0000gp/T/pip-build-env-p5p6ynnk/overlay/lib/python3.8/site-packages/poetry/core/masonry/api.py", line 41, in prepare_metadata_for_build_wheel
              poetry = Factory().create_poetry(Path(".").resolve(), with_groups=False)
            File "/private/var/folders/yc/cr3274bj5153d79w7mk2ty1c0000gp/T/pip-build-env-p5p6ynnk/overlay/lib/python3.8/site-packages/poetry_dynamic_versioning/patch.py", line 23, in alt_poetry_create
              name = _get_and_apply_version(
            File "/private/var/folders/yc/cr3274bj5153d79w7mk2ty1c0000gp/T/pip-build-env-p5p6ynnk/overlay/lib/python3.8/site-packages/poetry_dynamic_versioning/__init__.py", line 435, in _get_and_apply_version
              version = _get_version(config, name)
            File "/private/var/folders/yc/cr3274bj5153d79w7mk2ty1c0000gp/T/pip-build-env-p5p6ynnk/overlay/lib/python3.8/site-packages/poetry_dynamic_versioning/__init__.py", line 262, in _get_version
              version = Version.from_vcs(
            File "/private/var/folders/yc/cr3274bj5153d79w7mk2ty1c0000gp/T/pip-build-env-p5p6ynnk/overlay/lib/python3.8/site-packages/dunamai/__init__.py", line 1793, in from_vcs
              return cls._do_vcs_callback(
            File "/private/var/folders/yc/cr3274bj5153d79w7mk2ty1c0000gp/T/pip-build-env-p5p6ynnk/overlay/lib/python3.8/site-packages/dunamai/__init__.py", line 1827, in _do_vcs_callback
              return callback(**kwargs)
            File "/private/var/folders/yc/cr3274bj5153d79w7mk2ty1c0000gp/T/pip-build-env-p5p6ynnk/overlay/lib/python3.8/site-packages/dunamai/__init__.py", line 1005, in from_git
              raise RuntimeError("\n".join(x.message() for x in concerns))
          RuntimeError: This is a shallow repository, so Dunamai may not produce the correct version.
          [end of output]
      note: This error originates from a subprocess, and is likely not a problem with pip.
    error: metadata-generation-failed
    × Encountered error while generating package metadata.
    ╰─> See above for output.
    note: This is an issue with the package mentioned above, not pip.
    hint: See above for details.
Check the log at /Users/ilyasiamionau/.cache/pre-commit/pre-commit.log

The exception is understandable but I'm sad that I should disable strict mode for this specific case to be able to fallback to another source of the version

[MarshalX]

Ignoring 0.0.1.dev1 will lead to misunderstanding in the projects that track occurred errors, for example, in Sentry or collect analytics by user-agent in requests and so on

[mtkennerly]

I've just published v0.25.0b2 on PyPI that adds a new option (41c868d, 7a823d1). Could you try configuring fix-shallow-repository = true and test it out? It will run git fetch --unshallow if it detects a shallow repository.

Edit: Sorry, I think I missed a condition, so it will still complain about the shallow repository. One moment... Fixed in v0.25.0b2 by switching from git fetch --tags to git fetch --unshallow.

[MarshalX]

v0.25.0b2 works!

[mtkennerly]

Great! Thanks for testing it. I'll put out a stable release later today.

[MarshalX]

Awesome! Thank you for your work!