Embedded version required in snapcraft.yaml

[Stuart Bishop]

snapcraft.yaml requires the version key, which is often redundant.

Plugins will often know the version number (such as encoded in Python setup.py files), but that is just for a single part.

Perhaps the version should optionally accept a part name instead of a version number, causing the version number of the part as reported by the plugin to be used for the snap (or an error raised if the plugin does not support it).

The main use case would be have snap version numbers matching upstream for automatic builds, such as done by Launchpad.

name: juju-deployer
summary: Juju deployment lifecycle management
description: Juju deployment lifecycle management
version: juju-deployer
apps:
    juju-deployer:
        command: juju-deployer
parts:
    juju-deployer:
        plugin: python3
        source: lp:juju-deployer

[Jason Hobbs (jason-hobbs)]

I've worked around this for my tempest snap by building the actual snapcraft.yaml from a template and substituting in the tempest version.

[Sergio Schvezov (sergiusens)]

We have settled on `snapcraft set-version <version>` on the mailing list

[Stuart Bishop (stub)]

Launchpad needs more dynamic snap support. Currently, it only builds snaps from branches with a static snapcraft.yaml file in the root. Instead, it needs to invoke a build script of some sort (Makefile, executable with a well known name). This script could, for example, extract version numbers from debian/changelog or setup.py, install build dependencies, generate a snapcraft.yaml, run snapcraft to build, run tests. It would even be possible, if Launchpad allows, to build several related snaps and, only if tests pass, upload them all to the store.

[Sergio Schvezov (sergiusens)]

Please create a different bug for this and maybe even use the launchpad project.

[Stuart Bishop (stub)]

(formerly, 'snapcraft' handled the entire build pipeline. Now multiple commands are needed to build a snap, and needs to be embedded in a build script.)

[Colin Watson (cjwatson)]

Probably launchpad-buildd, not launchpad.

But Launchpad can't decide this unilaterally; the snappy community needs to decide on an augmented source format, and only then can Launchpad reasonably implement it. Perhaps something for the next sprint?

[Barry Warsaw (barry)]

FWIW, another piece of dynamic data would be the part's source key for say the PyPI download URL.

[Sergio Schvezov (sergiusens)]

El 19/09/16 a las 14:18, Barry Warsaw escribió:
> FWIW, another piece of dynamic data would be the part's source key for
> say the PyPI download URL.

I cannot escape the feeling that this is starting to feel like a command
line snapcraft.yaml. In the deb world this is solved with recipes and
perhaps this is the way to think of the solution for this.

[Barry Warsaw (barry)]

It's even more complicated, and while I've thought about it a bit, I can't say I've come up with any solution that I love. In the ubuntu-image case we have three or four "version domains".

* The Python version as you'd set it in setup.py's setup(version=) key.

* The version you see printed when you run `ubuntu-image --version`

* The debian/changelog version in several branches (e.g. stable yakkety branch and master)

* The version in snapcraft.yaml

Where it gets complicated is twofold: you'd like to set the base version in only one place. If you have to set it in multiple places, it's inevitable that you'll miss one and do a broken release. But worse, the exact version strings for each of the above domains may not be identical. Yes, the "base version" will be the same, e.g. 0.8, but you'd have something like:

* 0.8 for the Python-level versions
* e.g. 0.8+16.10ubuntu1 for the yakkety release or 0.8+17.04ubuntu1 for the zesty version
* 0.8+real1 for the snap version

What I currently do is set the version string in the d/changelog file, and then the setup.py digs it out of there (via python3-debian) and uses that to construct the Python-level version string. It puts that in a ubuntu_image/version.txt file, which the setup.py and the program's main() uses to give the Python-level version.

But I still have to manually change the snapcraft.yaml file.

So I'm down to two things to change for every release, which is an improvement, but not fantastic. It's not snapcraft's job to solve all of these, but I do think that if I had a way to invoke snapcraft with a version string placeholder, I could get one process to generate consistent version numbers across all the distribution channels.

[Stuart Bishop (stub)]

Could the version be generated by a scriptlet? It would need to be run some time after the build stage. I think it solves all the use cases, and would work with Launchpad builds without modification.

[Leo Arias (elopio)]

quick note: on quassel-webserver we are using this sed to change the version when there's a tag added to the repository: https://github.com/magne4000/quassel-webserver/blob/master/.travis.yml#L8