[virt-tools-list] [PATCH-v5.5 5/5] virt-manager version-id changes

[Gene Czarcinski]

On 04/12/2013 03:37 PM, Christophe Fergeau wrote:
> On Thu, Apr 11, 2013 at 02:01:39PM -0400, Gene Czarcinski wrote:
>>> I think this can be solved by adding an option to sdist or rpm subcommands
>>> that allows temporarily overwriting __version__. Then all the __version__
>>> building logic can be moved to an external script, which just passes the value
>>> to setup.py
>> Great minds and all that stuff.
>>
>> This is more or less the approach I thought to look into.  Something
>> where the default is as it now is but with some means of specifying
>> a "user version" override when sdist is run.
> I haven't followed the conversation closely, hopefully all of this was not
> discussed yet ;) The solution you are aluding to sounds a lot like the
> git-version-gen script which is used in several projects, see
> http://stuff.mit.edu/afs/athena/astaff/project/opssrc/cups/autoconf-2.65/build-aux/git-version-gen
> for example.
> This is the solution Eric mentioned at the beginning of this thread
> https://www.redhat.com/archives/virt-tools-list/2013-April/msg00106.html
>
> The way the versioning is done is:
> - if there's a 'vXXXX' tag pointing at the current HEAD, then version is
>    XXX
> - else version is XXXX.z-hash where XXXX is the most recent tag in the
>    current branch, z is the number of commits made since that tag, and
>    hash is a short hash for HEAD
>
> This gives you a version number that always increases, even for snapshots
> from git.
>
I like what the referenced script does.  Unfortunately, it works with 
autotools and those have been removed from virt-manager and replaced 
with python's distutils which has the same or at least similar 
objectives but is definitely different.

I like using a tag as the basis for "version."  Unfortunately, this is a 
bit difficult.  AFAIK, you cannot set a tag via patch and version is set 
from the value of the hardcoded and git tracked 
virtcli/cliconfig.__version__ which has the current value of "0.9.4".  
In addition, the tags which are used to identify the commit which is the 
base (top level) for a release has the form of RELEASE-0.0.0-1 ... a 
little string editing gets this to "0.0.0".

While I like the information provided by git-describe--tags, it does not 
necessarily produce an increasing number.  Consider a base with the tag 
of "0.9.100".  Now have two branches off that.  The two branches sill 
likely have different values for commits as well has the commit-id but 
the relationship is definitively defined and you could desire to replace 
"0.9.100.19" with "0.9.100.10" (last number is the number of commits).  
The git-describe--tags information would (IMHO) be good for an internal 
"version" but not when used for the version-id in a sdist-tarball or an 
rpm.  Right now, I am not going to worry about git-describe--tags and a 
potention internale version-id.

So, my focus is the version-id for taballs and rpms (that is in the spec 
file that is part of the tarball.

Right now I am envisioning a "bunch" of small steps the first two of 
which should be acceptable:

1.  For the current master (gtk3.2+), update cliconfig.__version__ to be 
"0.9.100" to indicate development/prerelease for whatever the next 
release will be called.

2.  Put spec.in back in witjh @VERSION@ and add "my_sdist" class to 
setup.py.  Before running the regular sdist, spec.in is copied to spec 
with @VERSION@ updated to the value of cliconfig.__version__.

Here is where is starts getting questionable.

3.  Add a "pkgversion" keyword to setup.py-configure and, if something 
is specified, update cliconfig.__version__ to that value during 
cliconfig initlization.  This is a nice to have but the result will be 
that the pkgversion value is used for everything and not just the 
sdist-tarball.

The problem is the the setup() kerword "version" is initialized/set long 
before sdist is called.  I do not see how to change it. Furthermore, 
specifying any version when sdist is run is thus useless.

First of all, I am NOT a python expert or anything like that (think 
beginner or novice).  Therefore, there may be a way to override the 
methods and I do not understand how to do it.

It appears that [all of this is under "distutils"] sdist uses Command 
and which, in turn, uses dist.  dist has the primary definition for 
class Distribution but also has this somewhat hidden class 
DistributionMetadata and it is that last class which defines 
get_fullname() [name + version].  In the sdist class, there is the 
make_distribution() method which calls distribution.get_fullname().

Creating a good, acceptable version-id is easy.  Getting it used without 
re-writing a lot of code not so much.

If one of you python experts out there knows how to do the override, I 
would appreciate any help.

Gene