Accept a callable for version generation

[webknjaz]

Most of my projects use setuptools-scm for versioning. It grabs a tag from Git and also generates versions for intermediate commits.
To work with this, I'd have to use --version.

I think it may be a good idea to think about some way to improve this.
I was thinking maybe pyproject.toml could have an option pointing to an importable callable which would return version. This'd be quite customizable as users would be able to specify own logic for generating a new version.

Another related idea would be being able to hint which version part to bump (major/minor/patch), according to semver, based on change fragments present. Maybe even just expose this info with a CLI command.

[RonnyPfannschmidt]

i'm preparing initial steps and planning for integrating setuptools-scm, towncrier and github/gitlab based automation to enable approval based releases or signed tag push based release with maximum local support

[webknjaz]

@RonnyPfannschmidt are you at PyCon Sprints? I'd love to meet and collaborate on things.

[RonnyPfannschmidt]

Nope, I'm in Europe,

[webknjaz]

Will be waiting to see what you'll come up with. I've built some expertise with GitHub Apps/Actions OTOH and would like to try making something generic on top of that...

[RonnyPfannschmidt]

i severely/direly am in need of that expertise (a key part of what i need to do will be to create PR's with commits and act upon their acceptance/tags appearing in them)

[webknjaz]

Sounds like you want to maintain a state machine. It should be possible by just handling the events happening on the GitHub platform side and anything else is just hitting GitHub APIs.

You may want to go through this tutorial: https://tutorial.octomachinery.dev. This should familiarize you with what some concepts. But keep in mind that it's GitHub-specific.

We can collaborate on smth when I come back home next week and we'll be in the same timezone :)

[omry]

Another idea here that would extend to non Python is to support getting the version by calling a command.

[tool.towncrier]
    version_cmd = "cat version.txt"

This can also support python imports as is:

version_cmd = "python -c 'from project import __version__; print(__version__)'"

[webknjaz]

@omry there's no reason for a Python callable to not be able to use subprocess.check_output() or similar.

[omry]

sure. but we can have explicit support for both styles.
both are equally powerful.

[webknjaz]

both are equally powerful.

Supporting many ways of doing the same thing would introduce unnecessary maintenance burden. Zen Of Python is to be followed here: There should be one-- and preferably only one --obvious way to do it.

[omry]

Those two things address different use cases.
There is nothing obvious about writing a python file to call an external binary for someone that wants to use towncrier in - say - a JavaScript project.

On the other hand, there is nothing natural about the example I pasted above for someone working in Python:

version_cmd = "python -c 'from project import __version__; print(__version__)'"

Regardless, I would be happy with ANY solution, I am not going to argue the details here.

[webknjaz]

I understand and it probably can be solved by documenting things. I just think that since it's a Python project that is mostly (probably only?) used by other Python projects, it's more natural to not try to escape this ecosystem because of some hypothetical use-case that may or may not exist in the future (hence premature optimization).

[omry]

Another source of version is setup.py.

e.g:

$ python setup.py  --version
1.1.0rc1

setup.py it self can either contain the version directly, or apply whatever logic the user need to generate the version.
Worth considering as well.

[RonnyPfannschmidt]

How about simply declaring a callable and arguments in toml, subprocess calls can just be that then

Alternatively just a cli command with env vars?

[omry]

My preference is to support both a callable and a process call, but I'd take either (read short discussion above).
I mentioned python setup.py --version because a more compelling use case than to support non Python projects.

[RonnyPfannschmidt]

Setup.py will soon be a legacy artifact not used by modern projects