fix: version resolution not working in `23.0`

[cbueth]

Current Behavior

pymovements.__version__ resolves to "0+unknown".
This was tested in the conda-forge version.

When installed editable mode, resolves to '0.23.0+0.gc7e4c6a.dirty'.

Expected Behavior

The actual package version is expected when installing packaged version.

My suggestion is using importlib.metadata.version('pymovements').

Minimum acceptance criteria

__version__ should return the correct version.

Failure Information (for bugs)

No error or warning is produced.

Steps to Reproduce

• Install from pypi or conda-forge
• python -c "import pymovements as pm; print(pm.__version__)"

Checklist

• I checked the documentation and found no answer
• I checked to make sure that this issue has not already been filed
• I have provided sufficient information for the team

[cbueth]

Both

  "setuptools-git-versioning<3",
  "versioneer[toml]>=0.29,<1.0",

are installed. Resolution happens in four steps

1. Git keyword expansion

pymovements/src/pymovements/_version.py

Lines 650 to 654 in dd122fd

	try:
	return git_versions_from_keywords(get_keywords(), cfg.tag_prefix,
	verbose)
	except NotThisMethod:
	pass

• Try to find root directory.

pymovements/src/pymovements/_version.py

Lines 656 to 667 in dd122fd

	try:
	root = os.path.realpath(__file__)
	# versionfile_source is the relative path from the top of the source
	# tree (where the .git directory might live) to this file. Invert
	# this to find the root from __file__.
	for _ in cfg.versionfile_source.split('/'):
	root = os.path.dirname(root)
	except NameError:
	return {"version": "0+unknown", "full-revisionid": None,
	"dirty": None,
	"error": "unable to find root of source tree",
	"date": None}

2. VCS detection

pymovements/src/pymovements/_version.py

Lines 669 to 673 in dd122fd

	try:
	pieces = git_pieces_from_vcs(cfg.tag_prefix, root, verbose)
	return render(pieces, cfg.style)
	except NotThisMethod:
	pass

3. Parent directory parsing & fallback

pymovements/src/pymovements/_version.py

Lines 675 to 683 in dd122fd

	try:
	if cfg.parentdir_prefix:
	return versions_from_parentdir(cfg.parentdir_prefix, root, verbose)
	except NotThisMethod:
	pass
	return {"version": "0+unknown", "full-revisionid": None,
	"dirty": None,
	"error": "unable to compute version", "date": None}

---

Version should be frozen at build time and having two versioning systems sounds too much to me. Versioneer should administer the _version.py file, while setuptools-git-versioning, which is also in the [build-system], should generate the version when building.

The issue of having the version to resolve to 0+unknown means that the build system did not properly set the version. I would reccomend to stay with one versioning system.

[dkrako]

1. I'm pretty sure that we don't actually use setuptools-git-versioning. It was moved from an older setup.cfg in this commit: a772d1d

As this didn't work propertly, versioneer was added half a year later here: dd122fd

So it's probably safe to remove setuptools-git-versioning.

2. It think we are currently doing something wrong in the build process. The version resolution via git works fine, but after packaging there won't be any git available anymore. I'm not sure how to fix this. Reading some of the documentation this might possibly solved by using the experimental build time mode: https://github.com/python-versioneer/python-versioneer#build-time-dependency-mode

But I'm really unsure about this, so we need to investigate a bit more.