Would it make sense to split the functionality of ccount into version_ccount and tag_ccount?

[remohoeppli]

To start, I really love your package. It is super handy and helps a lot to automate the versioning.

The way ccount works currently, it has basically two functions. Either it counts the commits since the last edit of the VERSION file, or it counts the commits since the last Git tag in the git repository graph.

This can introduce an issue into the versioning. Assume we have a feature branch originating from dev. We start to work on it and do some commits. At some point, we set a new tag on the dev branch. If our feature branch originated from the commit of dev, on which we set the tag. This will reset the ccount and possibly give us duplicated version numbers on the feature branch discussed before.

Let me try to visualize this with the following graphs.

If instead of the ccount, I could use the version_ccount (which only counts the commits since the last changes in the VERSION file), I could prevent the counter from accidentally being reset if someone adds a tag in Git.

I hope this helps to clarify my issue. Please let me know if you need any further information.

[dolfinus]

Hi.

Regarding a graph on the second image, that is the tag name added to dev branch, and what version format is used?

[remohoeppli]

Hey
Sorry for the late reply.
Yes, this would be a tag with the name 1.0.0+alpha.1 that was added to the dev branch.

[dolfinus]

1. What is version format?
2. Why any tags are added to dev branch in the first place?

[remohoeppli]

1. The template for the versioning is {tag}+{branch}.{ccount}.
2. We use tags in dev to create pre-release versions.

I hope this answers your questions. Otherwise, I would be happy if you could be a bit more precise with what you want to know, so I can give you the details you need.

[dolfinus]

1. Why tag is named 1.0.0+alpha1 instead of 1.0.0alpha1 or 1.0.0a1?
2. According to documentation tags should added to commit in master/main branch, not in develop branch.

[remohoeppli]

1. Because 1.0.0+alpha1 is SemVer compatible, while 1.0.0alpha1 and 1.0.0a1 aren't.
2. I know. This is why I added the idea of having separate ccount (ccount_version, ccount_tag) because it would solve this restriction of not being able to have a tag on dev.

[dolfinus]

1. Python does not follow SemVer. Package versions should be compatible with PEP-440

[remohoeppli]

I believe, you aren't open for suggestions that could increase the usability of your package. In the current state, I'm unfortunately not able to use setuptools-git-versioning in my production projects because it is too restrictive. This is why I suggested the change above.

Doing two different things with ccount at the same time is too error-prone and unpredictable for us. For this reason, I asked if there was a possibility to split the two different functions into two variables, which would make it much more versatile and safe to use.

Python doesn't strictly follow SemVer, but it is possible to find a way that PEP-440 and SemVer are respected. Instead of PEP-440 which is a historical document, you should refer to https://packaging.python.org/en/latest/specifications/version-specifiers/#version-specifiers

Thanks anyway for your time.

[dolfinus]

What I'm taking about is even if there were version_ccount subst, how exactly are you going to use it?

If you use tag names like 1.0.0+alpha1 with dev_template="{tag}+{branch}.{version_ccount}", then you'll get 1.0.0+alpha1+dev.1 which is not a valid version number. I will be converted to 1.0.0+alpha1.dev.1 which is actually the same as 1.0.0.

This is because part after + is not used by pip and other packaging tools while fetching available versions of a package. So what you'll get is not a development version but a release version. So if someone run pip install package it will got this version as it was a release, which is relly harmful (especially if you build packages from each commit of any branch in the repo).

If tag name looks like 1.0.0a1, then using the same dev_template as above produces version number 1.0.0a1+dev1 which is actually the same as 1.0.0a1. Alpha versions (like dev) can be installed only using pip install package==1.0.0a1 or pip install package --pre, so this is less harmful than example above.

But if you build versions like version+dev.N for every commit pushed to dev branch (or any other branch originated from dev), this could introduce other issues. For example, I'm not sure if pip can properly determine that 1.0.0a1+dev.1 and 1.0.0a1+dev.2 are different versions, or determine that 1.0.0a1+dev.2 is newer than 1.0.0a1+dev.1. What I know for sure is that https://pypi.org does not allow + in version numbers at all.

So the only way you can use version_ccount is to use tag names like 1.0.0a1 with dev_template="{tag}.dev{version_ccount}". This will produce version number like 1.0.0a1dev1 which:

1. Cannot be installed automatically using pip install package. You have to specify pip install package==1.0.0a1dev1 explicitly
2. Different commits in the same branch will produce different package versions which can be properly solved by pip and other packaging tools.
3. https://pypi.org will not complain to this version number

you aren't open for suggestions that could increase the usability of your package

I'm open to features but not ones which allow users to shoot themselves to their feet.

[remohoeppli]

I would be using it like this {tag}+{branch}.{version_ccount}. The idea is to use it only in the scenario where I want to produce feature-based development versions of my code that are automatically built by the CI/CD. Since I use docker images and do not need to upload the packages to pypi this shouldn't be an issue. Any pre-release or release versions would just use the direct tag (something like 1.0.0+alpha1, 1.0.0). The reason to use SemVer is that I have other modules in different languages and I want to have one consistent versioning across all the modules.

So really the only thing I was requesting is to split the two functionalities of ccount into two different variables.

ccount_tag -> commit count since last tag in graph
ccount_version -> count count since last version file change in graph

The original ccount could still exist.

[dolfinus]

Notice that setuptools-git-versioning can be used only for Python packages. It is not meant to have consistency with other languages.

Regarding ccount_tag, ccount_version, PRs are welcome.

[remohoeppli]

Thanks for the notice, we already have similar solutions for other languages in place, but I was looking for a package that can do this in Python and came across setuptools-git-versioning.

[dolfinus]

Try v2.0.0, it now ignores tags if version_file is used

[remohoeppli]

Hey
Thank you for the message and your work on this.

I just did some extended testing, but still seem to have the issue.

This is my configuration

[tool.setuptools-git-versioning]
enabled = true
version_file = "VERSION"
count_commits_from_version_file = true
template = "{tag}"
dev_template = "{tag}+{branch}.{ccount}"
dirty_template = "{tag}+{branch}.{ccount}"

This is my git graph

As you can see, I put an invalid tag in the dev branch, which changes the behavior of the count and tag that is taken for the versioning. Before adding the tag, it worked fine.

Is there something I do wrong?

Thanks for your help.

[dolfinus]

but still seem to have the issue.

Using v2.0.0, right? Have you updated lib version in [build-system] section of pyproject.toml?

[remohoeppli]

That was the issue. Thanks. I pinned the build-system requires to versions lower than 2.

Now it works perfectly fine. Thank you for your help and effort.

[dolfinus]

Ok, closing the issue then