Hi @LecrisUT, we've chatted about CMake some over at Libxc. The Libint project could use something like your DynamicVersion, but they'd like to stick with cmake=3.16. Preliminary tests show DynamicVersion does not like 3.16. Possibly they might be willing to bump the version, but I wanted to inquire if (1) 3.16 is even feasible after modifications and (2) are you ready for users at this stage? Thanks!

Failed to load packit config file:

Cannot parse package config: ValidationError({'jobs': {0: {'packages': defaultdict(<class 'dict'>, {'cmake-extra-utils': {'value': {'files_to_sync': {3: {'deest': ['Unknown field.']}}}}})}, 1: {'packages': defaultdict(<class 'dict'>, {'cmake-extra-utils': {'value': {'files_to_sync': {3: {'deest': ['Unknown field.']}}}}})}, 2: {'packages': defaultdict(<class 'dict'>, {'cmake-extra-utils': {'value': {'files_to_sync': {3: {'deest': ['Unknown field.']}}}}})}, 3: {'packages': defaultdict(<class 'dict'>, {'cmake-extra-utils': {'value': {'files_to_sync': {3: {'deest': ['Unknown field.']}}}}})}, 4: {'packages': defaultdict(<class 'dict'>, {'cmake-extra-utils': {'value': {'files_to_sync': {3: {'deest': ['Unknown field.']}}}}})}}, 'packages': defaultdict(<class 'dict'>, {'cmake-extra-utils': {'value': {'files_to_sync': {3: {'deest': ['Unknown field.']}}}}})}).

For more info, please check out the documentation or contact the Packit team.

Need to test that fallthroughs: CONFIG -> Pkg-config -> manual work correctly

Should remove COMMAND_ERROR_IS_FATAL ANY and instead parse the exit code

Failed to load packit config file:

Please correct data and retry.

For more info, please check out the documentation or contact the Packit team.

This is more nuanced as discussed in the PR. Need to investigate how setuptools_scm calculates it more carefully.

          >> but computing the next M.m.p always seemed iffy -- perhaps scm has conventions nowadays.

Interesting, can you elaborate. I thought it was just the git describe info directly.

I was referring to .postN being distance beyond the most recent tag, which is what one gets from git describe. Whereas .devN is distance on the way to the next tag, so the versioner software has to make a choice whether that's M+1.0 or M.m+1 or M.m.p+1, etc. I get around this in that psi4 script by having the user commit the intended upcoming tag, but I don't pretend that that's a feature :-) scm might well have conventions on this now -- I just haven't looked into it lately. https://packaging.python.org/en/latest/specifications/version-specifiers/#summary-of-permitted-suffixes-and-relative-ordering (succeeds pep440).

Originally posted by @loriab in #19 (comment)

For example if the latest tag is v2.1.0-rc1, this is allowed by git describe --match=?[0-9.]*. But there is an inconsistency between parsing from git_archival.txt and setuptools-scm

• git_archival.txt: describe-name = v2.1.0-rc1-257-gcbc8618a5
• PKG-INFO: Version: 2.1.0rc2.dev257+gcbc8618

Issues are that the - in the rc is removed and the regex needs to account for the version syntax having - suffix in its name.

It is not ideal because you need to run cmake --build twice to pick up changes on the commit/tag, etc. This is because it is consumed via configure_file

Potential alternatives:

• Allow to provide a custom file(WRITE) script/function or other way to write the commit metadata at build time instead of configure time

Syntax like cmake_minimum_required(VERSION 3.20...3.29) sets policies for up to 3.29 automatically. And since a new policy stack is created even when using include and find_package, all of these should be safe ¹

I am not sure how this will interact with FetchContent, SOURCE_DIR and other such variables.

Not sure how git will handle this