Python is missing a version

[mpkorstanje]

🤔 What's the problem you've observed?

Currently there is no version = <some version> declaration in pyproject.toml. The current release process expects this to be present.

✨ Do you have a proposal for making it better?

Add version = <some version> back into pyproject.toml

📚 Any additional context?

I'm happy to support anything else, but this should be applied consistently across all repositories.

[jenisys]

This is not needed anymore by using the setuptools-scm mechanism.

• The version information is derived from the git-tag, like: git-tag v6.1.0 leads to version = “6.1.0”.
• The package version is determined when you build the package: python3 -mbuild
• The package version is stored in other metadata files that are related to the description of this package (this is Python specific and independent of this package).
• In addition, a temporary file cucumber_tag_expression/_version.py is generated in the package archive that contains the version.

[mpkorstanje]

I'm afraid that will not do.

Releases are made with a script. This is necessary because nobody can remember the intricacies and conflicting requirements of releasing 13 different languages. And currently the script expects there to be a version in the pyproject.toml.

Again, I'm happy to adopt any other solution, and this does look like a good solution, but it should be applied consistently to all Python projects in the Cucumber org. Preferably at the same time. This to keep the already complicated release script and release procedures simple.

So for now, please add version = <some version> back into pyproject.toml.

The version information is derived from the git-tag, like: git-tag v6.1.0 leads to version = “6.1.0”.

What happens if multiple tags are present? For example, when go is included in a release all release commits are tagged with both v1.2.3 and go/v1.2.3 (this is necessary for go to find the right sub directory in the project).

[jenisys]

I will look at the script.
If it helps, I can remove the mechanism again and provide a version parameter.

Multiple git-tags are no problem (any more) because the matching git-tag format is specified in pyproject.toml:L119. It matches only git-tags that match v[0-9]* by using the git_describe_command parameter. Without this parameter, using setuptools-scm did not work correctly because the probably later assigned git-tag go/v6.1.0 was selected.

RELATED:

• setuptools-scm: Issue #1079

[mpkorstanje]

If it helps, I can remove the mechanism again and provide a version parameter.

Yes, cheers!

It matches only git-tags that match v[0-9]* by using the git_describe_command parameter.

Mmh. That should probably be v[0-9]+\.[0-9]+\.[0-9]+. Right now it would be only a partial match against v1.2.3.

[jenisys]

No, it works. Your match expression is just more specific. Mine is the minimal match-pattern that is needed to work.

Note that it would be sufficient for your polyglot-release script that the following, commented-out line is contained in pyproject.toml:

# version = “6.1.0”

[mpkorstanje]

Note that it would be sufficient for your polyglot-release script that the following, commented-out line is contained in pyproject.toml:

Heh yes. That would work. But it's also the sort of workaround nobody likes to see.

[mpkorstanje]

And thanks for fixing! Much appreciated!