python3-mb: update the version string automatically for each git commit about jack HOT 10 CLOSED

Hi @zzarne , here's an idea: every developer that has push rights in git gets their own version file.
That version file is incremented by that developer only, using git hooks and tools like versioneer or bump2version.
Then, jack/version.py reads each file and uses the sum of commits to calculate the minor version number.
The tools to auto-increment would not need to be in the repo, only the version files themselves would need to be committed.

If there were only one dynamic version file, then every parallel commit would cause a conflict when pushed.

from jack.

Interesting idea, but then package maintainers would have to run (at least parts) of the product to determine the version. On the other hand, setup.py does this already, so it may not be an issue. Let's just try it, it's simple enough. Like this:

def build_version():
    basedir = os.path.dirname(__file__)
    version = [0, 0, 0]
    for pos, name in enumerate(("major", "minor", "subversion")):
        for version_file in glob.glob(os.path.join(basedir,
                f"version_*_{name}")):
            with open(version_file) as fd:
                version[pos] += int(fd.read())
    return version
version = ".".join((str(x) for x in build_version()))

together with

echo 4 > version___base___major
echo 0 > version___base___minor
echo 0 > version___base___subversion
echo 3 > version_arne_zellentin_subversion

version would be "4.0.3".

Should I push this und you do the pre commit hook?

from jack.

Just to be clear; I'd like to increment the version for every commit, not for every run of setup.py.
So this means the version files need to be evaluated both at runtime and during setup.
Then, where would the version files stay on a runtime system?
One solution would be that the version files are .py files living next to all the others, returning their version by calling a function stored in them.

from jack.

What I was about to write:

Just to be clear; I'd like to increment the version for every commit, not for every run of setup.py. So this means the version files need to be evaluated both at runtime and during setup.

Sure, the sniplet above would replace the line version = "4.0.0" in jack/version.py.

Then, where would the version files stay on a runtime system?

The files version___base___major, version___base___minor, version___base___subversion, version_arne_zellentin_subversion... would reside in the same directory (jack/) and be added to git. My commit hook would increment version_arne_zellentin_subversion, yours would be version_pimzand_subversion or whatever you prefer between the underscores. The version___base___* files would be incremented by hand whenever appropriate.

One solution would be that the version files are .py files living next to all the others, returning their version by calling a function stored in them.

I'd prefer simple text files with just the number in them as in my proposal above. That keeps the commit hooks simple.

What I write instead:

Forget about all that, let's just switch to using setuptools_scm, which provides a nice version string from git, e.g. jack 4.1.dev199+g2e1665e while developing, jack 4.1 on tagged releases. For us developers, it is updated for example with ./setup.py develop --user, which can be automated for each commit or pull.

Please test.

from jack.

For us developers, it is updated for example with ./setup.py develop --user, which can be automated for each commit or pull.

With db57062, the setup.py call is no longer neccessary if setuptools_scm is available for jack.

from jack.

Cool. Fedora 35 has a python3-setuptools_scm package available, which is what I used.
I do get to see a version string, but it appears the code changes the current directory.
This causes jack to fail when running from a directory that has jack.* files.

from jack.

I do get to see a version string, but it appears the code changes the current directory. This causes jack to fail when running from a directory that has jack.* files.

If this isn't fixed by a5d347b, how can I reproduce this? jack in a album directory ripped by jack works fine here.

from jack.

I believe the problems I am seeing are caused by jack.version.name returning "jack.version" rather than "jack"

from jack.

so it is fixed by a5d347b?

from jack.

Yes!

from jack.