'snap info' does not handle versions that end in 0 well

[Mark Shuttleworth]

LXD 2.10 is just released but 'snap info' presents this as 2.1:

$ snap info lxd
name: lxd
summary: "LXD - the container lightervisor"
publisher: canonical
description: |
  LXD is a container manager for system containers.[...]
commands:
  - lxd
  - lxd.benchmark
  - lxd.lxc (lxc)
tracking: stable
installed: 2.8 (976) 12MB -
refreshed: 2017-01-25 04:47:15 +0100 CET
channels:
  stable: 2.8 (976) 12MB -
  candidate: 2.1 (1416) 12MB -
  beta: 2.1 (1416) 12MB -
  edge: git-e177ca9 (1435) 12MB -

We should make sure we are not parsing versions as numbers and silently dropping trailing post-decimal-point zeroes.

[Michael Vogt (mvo)]

I downloaded lxd r1416 and unpacked it and it already has the invalid version:
"""
$ grep version: meta/snap.yaml
version: 2.1
"""

I (strongly) suspect that snapcraft truncated it. I had the same when doing "version: 2.10" in the regression test for snapd that I wrote in https://github.com/snapcore/snapd/pull/4437 to ensure that its not our bug.

Adding a snapcraft task, maybe they can at least warn that versions should be quoted:
  version: 2.10 (will be truncated)
vs
  version: "2.10" (is fine)

However when I created a test snap and used "version: 2.10" snapcraft was generating the truncated version number 2.1.

[Cris Dywan (kalikiana)]

Indeed using `version: 2.10` will cause the version to be parsed as an integer. The schema doesn't specify a type so both strings and integers are accepted.
We probably don't want to fail here, but a warning is doable.

[Michael Vogt (mvo)]

Closing our side, we have a regression test for this to ensure we parse the version as a string.

[Gustavo Niemeyer (niemeyer)]

Indeed we parse the version in a resilient way that works even if YAML would consider it as a number.

You can do the same thing in Python with something similar to:

>>> yaml.load("version: 2.10", Loader=yaml.BaseLoader)
{u'version': u'2.10'}

You probably don't want to parse the whole file like this, though, as all you get are strings, and perhaps some other side effects too.

As a side note, this issue was reported to me on IRC as if "version: 1.2.0" would take off the last zero. That's not true.. "1.2.0" parses as a string, quoted on not, and thus will preserve the last zero as well. It's cases like described above that have issues, when the value is a valid number representations ends with one or more zeros.

[Gustavo Niemeyer (niemeyer)]

As an aside, it would be nice to warn on non-strings so that other YAML processing tools can still process the file correctly.