On 04/11/2013 12:28 PM, Cole Robinson wrote:
On 04/11/2013 12:16 PM, Gene Czarcinski wrote:
On 04/10/2013 06:29 PM, Cole Robinson wrote:
Gene, I'm sorry, but I truly have no interest in maintaining this as part of
virt-manager. The problems you describe affect just about every open source
project I've worked on, so even though it_is_ sub optimal it's common enough
that it clearly doesn't cause too much grief, so it doesn't warrant such a
complex solution.
OK, lets step back a moment. Before, considering how something is
implemented, I want to consider what is implemented and I have the following
separate issues.
1. When python setup.py sdist is run and IF we are running under a giot-clone
repository, then there should be a check made for outstanding/uncommited
changes and if such changes exist, creating the tarball should be aborted.
My reasoning is that the tarball should have a "good, known base."
There is the possibility that python setup.py sdist was not run under a
git-clone repository, the execution should proceed.
If we add the MANIFEST file, I don't see why this is required really. What if
I want to create a test RPM with uncommitted changes, why should that be
disallowed? That's not a pathological example either, I've certainly done that
on several occasions when making big build system changes. Yes, I could commit
my changes first, but really, why add code to enforce it?
Our development/work-styles differ. I break "large" efforts into multi
commits and multi branches so that I can easily back our of something
back to something "known" to work. When I complete what I wanted to do,
I then "repackage" all of the small changes into a single bigger change.
But, I can also understand where you are coming from and why building a
tarball and/or rpm with uncommitted changes makes sense.
"Ideally," I would like to see the check being done unless some override
was set to "just do it, don't ask questions" as that is sometimes what
needs to be done.
This is not something I am going to fall on my sword for.
2. Never mind what it is or how it is done, is it desirable to have some sort
of snapshot id? Yes, many projects have this problem, but that does not mean
it should be ignored.
My submitted solution has many problems including that it is way
over-engineered. I forgot the KISS principle. I was looking for something
simple and the solution got a life of its own.
While it might be "nice" to capture the information returned by
git-describe--tags, the real issue (IMHO) is to have some simple version
differentiator for tarball and rpm names ... autobuild.sh does provide a
differentiator for the RPMs it builds.
RPM maintainers also do their own differentiation when they build an updated
version of some program which is not based on an official release but instead
a point-in-time snapshot of a git repository.
So, back to the basic question: is a snapshot file-name differentiator
something desirable?
I understand why having an RPM and tarball with a git commit/tag derived
version is useful for certain usecases. But I don't think it's sufficiently
useful that we should do it by default or complicate the build system to do so.
Having a git derived version (e.g., based on git-describe--tags) for the
tarball would work but IMHO it would not work for RPMs (they like
increasing version ids and the commit id is not that). However, it would
be "nice" to have this information tucked away somewhere (maybe like for
the --version response) so that if you are running and you need to get a
better handle on just what you are running ... there is something to
tell you.
Whatever is done, it needs to be done ONCE, and only once, when the
sdist tarball is created. Like I said, the submitted patch got a life
of its own and wandered into swamps best left unexplored.
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.
My current approach is to make sure I break things up into small pieces
each of which can be addressed on its own merits.
One such small piece I intend to submit:
Bring back virt-manager.spec.in with @VERSION@ ... virt-manager.spec.in
would be git tracked but virt-manager.spec would not ... add "my_dist"
to setup.py which copies spec.in to spec and replaces @VERSION@ with
whatever the "version id" is (currently cliconfig.__version__).
This is more of a simple automation to replace requiring both
virtcli/cliconfig.py and virt-manager.spec be modified to change the
version with just a single update. If some SIMPLE means of having a
"user version" override, this would fit in.
BTW, I still prefer using git-tags to specify versions, subversion, RCs,
etc.
Gene
_______________________________________________
virt-tools-list mailing list
virt-tools-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/virt-tools-list
