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
_______________________________________________
virt-tools-list mailing list
virt-tools-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/virt-tools-list
