Dynamic version

[LecrisUT]

This generates the version from git tags or .git_archival.txt. DynamicVersion.cmake here is from my project CMakeExtraUtils. I still need to add the testing there before I can publish it to Fedora, after that we can move the script out of here and get the latest version automatically.

A few notes:

• The automatically generated _version.py has the __version__ as a string not tuple. That is the convention from setuptools_scm, I don't know if it is the current standard. The tuple version is still available there, should we export that as well?
• Cmake version does not support suffixes like -rc1, so there is a difference with the displayed version. I can add another Spglib_FULL_VERSION to export a version variable more complete
• There are various version_schemes to choose from that change the displayed version. Any preference on that?

TODO:

• Dynamic version in scikit-build-core is still experimental, wait until it is released to merge this
• The _version.py file is not automatically installed, need to fix this. Upstream issue
• Make sure the correct version is calculated in Fedora
• Check that PyPI test still reports the correct version

Closes: #231, #380

[codecov-commenter]

Codecov Report

Attention: 17 lines in your changes are missing coverage. Please review.

Comparison is base (c945bae) 83.85% compared to head (f2345a5) 83.71%.

Files	Patch %	Lines
python/_spglib.c	0.00%	12 Missing ⚠️
src/spglib.c	75.00%	3 Missing ⚠️
fortran/spglib_f08.F90	89.47%	2 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #271      +/-   ##
===========================================
- Coverage    83.85%   83.71%   -0.14%     
===========================================
  Files           24       24              
  Lines         8181     8205      +24     
===========================================
+ Hits          6860     6869       +9     
- Misses        1321     1336      +15     

Flag	Coverage Δ
c_api	77.50% <0.00%> (-0.10%)	⬇️
fortran_api	56.33% <83.87%> (+0.19%)	⬆️
python_api	79.94% <0.00%> (-0.44%)	⬇️
unit_tests	1.36% <75.00%> (+0.11%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[lan496]

Please call me again when ready for review 🙇

[LecrisUT]

Waiting on a contribution: LecrisUT/CMakeExtraUtils#19, after which I will fix Spglib_VERSION to Spglib_VERSION_FULL which will have a format like 2.1.1.dev96+gcbc8618 when not on tag and 2.3.0 when on tag similar to how setuptools-scm currently does it. There are a few notes I want to raise here though:

• Deprecating spglib.get_version in the python api. Use __version__ to get the version of the python bindings and spglib.get_spg_version (might need better name) to get the string format of the loaded C library
• Could then add a warning for when the version of the binding and library missmatch
• Providing more version API interface, e.g. spg_get_version and spg_get_commit
• Provide the same API interface for Fortran and Python code

Other than that need to raise an issue on scikit-build about the sdist build

[LecrisUT]

Ok, this is almost done. A few things to note:

• RTD does not display the correct version when on PR, unless the fork has all of the tags 🤷
• Still need to add all of the additional version metadata and introspection. Only Fortran remaining
• Could use some manual verification that all is in order
• Still have to tag the new additions in CMakeExtraUtils and point it to the appropriate commit

[lan496]

In my environment,

git pull upstream --tags
python -c "import spglib; print(spglib.__version__)" 

gives 2.1.1.dev117+g96daef7 though I think it should be 2.2.1.dev****. Is it expected?

[LecrisUT]

In my environment,

git pull upstream --tags
python -c "import spglib; print(spglib.__version__)" 

gives 2.1.1.dev117+g96daef7 though I should be 2.2.1.dev****. Is is expected?

The latter one is the expected behavior. I think it's because the v2.2.0 tag is on a different branch. This would automatically be fixed in the next release.