[Packaging] Reconsider use of Versioneer

[Chandan Singh <ch...@chandansingh.net>]

Hi all,

(I have now ran into this issue often enough that I thought I should bring it
up on the list.)

I have recently created this issue [0] to describe this problem. I'd suggest
having a read through that issue to get some background on this issue. The gist
of it is that BuildStream complains at runtime (not build time) that it doesn't
have any tags.

Versioneer (also, its predecessor setuptools_scm) is really good at solving
that problem that it does, i.e. managing versions based on scm tags. I am not
disputing that. I am saying that this is not a problem we need to have.

As an alternative, we could simply bake-in the version number as part of
version control. This is also a tried and tested strategy for managing version
numbers. Pip itself for, example, manages its version in this manner [1].

The obvious downside is that the some one/thing else is going to have to push a
tag to the git repository separately after changing the version number.
Although I don't think this is that adds too much to the release ceremony, but
this can easily be automated if we wish. (For example if `setup.py --version`
returns something greater than previous tag, an automation could create and
push a new tag.)

Not relying on Versioneer will mean that if someone managed to _somehow_ get
all the buildstream source files untampered, they'd end up with a working copy
of BuildStream.

As I mention in the issue, this can happen due to multiple reasons, ranging
from for performance to ignorance.. to default flags (like BuildStream's very
own `track-tags: false` default). Personally, I think this collective lost
productivity justifies the chore of having to tag the scm version separately.

Let me know what you think!

Cheers, Chandan

[0]: https://gitlab.com/BuildStream/buildstream/-/issues/1383 [1]:
https://github.com/pypa/pip/blob/master/src/pip/__init__.py#L7

Re: [Packaging] Reconsider use of Versioneer

[Chandan Singh <ch...@chandansingh.net>]

Hi Tristan,

Thanks for getting back.

I fully expected some fireworks on this thread, as versioning debates
can do that very easily :)

> > I have recently created this issue [0] to describe this problem. I'd suggest
> > having a read through that issue to get some background on this issue. The gist
> > of it is that BuildStream complains at runtime (not build time) that it doesn't
> > have any tags.
>
> Sounds like this is a problem worth correcting at build time indeed.

Glad that we agree on this part. I'll add it to my to-do list to move
this error to the right place.

> > Versioneer (also, its predecessor setuptools_scm) is really good at solving
> > that problem that it does, i.e. managing versions based on scm tags. I am not
> > disputing that. I am saying that this is not a problem we need to have.
>
> Except that "managing versions based on scm tags" is not the key,
> important problem which versioneer solves (although it is helpful in
> this automation, this automation is *not* the main reason we are using
> it).

Thanks for clarifying this.

> BuildStream takes build provenance tracing very seriously, as is
> demonstrated by the verbose summarizing of cache keys in the master
> build log (which is the key trace of provenance when speaking of any
> binary artifact it produces, in addition to the individual build logs
> of each binary artifact being produced).
>
> Since there is a significantly non-zero possibility that a copy of
> BuildStream that is not *exactly* a release version is used in
> production, and for this reason it is of extremely high importance that
> the copy of BuildStream I currently have on my machine says:
>
>     BuildStream 1.93.4+145.g4a8746161
>
> And not:
>
>     BuildStream 1.93.4
>
> This is highly valuable information about what precise version of
> BuildStream produced an artifact, information which cannot be captured
> better in a later build, since the build has already occurred and has
> potentially been deployed.

I can definitely see where you're coming from. And I can see the value in that.

And, while I may not necessarily agree that this is a better
versioning strategy, I can appreciate its benefits and won't push this
issue any further.

Thanks,
Chandan

Re: [Packaging] Reconsider use of Versioneer

[Tristan Van Berkom <tr...@codethink.co.uk>]

Hi Chandan,

As someone who originally thought it was a good idea to do like other
traditional softwares and manually bump the version in the source code,
but stood gravely corrected (by Paul), I have to give this a strong -1.


On Tue, 2020-08-11 at 22:32 +0100, Chandan Singh wrote:
> Hi all,
> 
> (I have now ran into this issue often enough that I thought I should bring it
> up on the list.)
> 
> I have recently created this issue [0] to describe this problem. I'd suggest
> having a read through that issue to get some background on this issue. The gist
> of it is that BuildStream complains at runtime (not build time) that it doesn't
> have any tags.

Sounds like this is a problem worth correcting at build time indeed.

> Versioneer (also, its predecessor setuptools_scm) is really good at solving
> that problem that it does, i.e. managing versions based on scm tags. I am not
> disputing that. I am saying that this is not a problem we need to have.

Except that "managing versions based on scm tags" is not the key,
important problem which versioneer solves (although it is helpful in
this automation, this automation is *not* the main reason we are using
it).

BuildStream takes build provenance tracing very seriously, as is
demonstrated by the verbose summarizing of cache keys in the master
build log (which is the key trace of provenance when speaking of any
binary artifact it produces, in addition to the individual build logs
of each binary artifact being produced).

Since there is a significantly non-zero possibility that a copy of
BuildStream that is not *exactly* a release version is used in
production, and for this reason it is of extremely high importance that
the copy of BuildStream I currently have on my machine says:

    BuildStream 1.93.4+145.g4a8746161

And not:

    BuildStream 1.93.4

This is highly valuable information about what precise version of
BuildStream produced an artifact, information which cannot be captured
better in a later build, since the build has already occurred and has
potentially been deployed.


When you are in a bind, and that latest deployment may be the cause of
your fleet being positioned two parsecs off course and in klingon
territory, you want to be damn sure that the version of BuildStream you
used to compile the recently deployed "Death Star 2.x" firmware is very
exactly the version that you think you used, and knowing for sure which
exact version of BuildStream you used might prevent the next
intergalactic conflict.


The "${major}.${minor}.${micro}" version number is just not specific
enough to pinpoint what BuildStream is responsible for a build, and I
would be in support of any course of action which does not cause us to
lose important context from the reported BuildStream version.

Cheers,
    -Tristan