[virt-tools-list] setup.py and packaging for distribution

[Cole Robinson]

On 03/26/2013 11:59 AM, Gene Czarcinski wrote:
> OK, I have been looking into how packaging and distribution works for example
> of when you want to get a snapshot of your development.
> 
> 1. python ./setup.py build seems to work
> 2. python ./setup.py rpm fails looking for some patch file (?) but does create
> a tarball in ./dist/

'python setup.py rpm' works for me... can you show the exact error?

> 3. python ./setup.py sdist works and creates a tarball in ./dist/
> 4. in both of the above cases the tarball is completely unsatisfactory!  They
> contain everything in the directory.
> 
> Suggestions:
> 
> 1. Use "git archive" since it will only gather files that branch currently
> manages
> 
> 2. This is a snapshot.  The tarball name should be something like
> virt-manager-git20130326.tar.gz
> 
> 3.  Add more tags.  I know you have the RELEASE-0.9.4-1, etc. tags but you
> need some additional one for things such as release-candidates,
> testing-candidates, etc.  For example, maybe the current gtk3.2 branch should
> have a tag something like gtk3.2-t1 [test 1].
> 
> Why the above suggestions:
> 1. From the git-scribe man page:
>>        The command finds the most recent tag that is reachable from a commit.
>>        If the tag points to the commit, then only the tag is shown. Otherwise,
>>        it suffixes the tag name with the number of additional commits on top
>>        of the tagged object and the abbreviated object name of the most recent
>>        commit.
> 2. Use this tag-info to set the virt-manager "version"
> 
> 3. Bring back a bit of the v-m.spec.in file.  Set the Version as the "date"
> from one specified on the tarball using "sed".  Then you can add the tag-info
> as the "release" or "extra-release" using "sed". The output of "sed" should be
> the .spec file which is NOT managed by git but the spec.in is.
> 
> 4. When you run "git archive", create the tarball (.tar file) but not
> compressed (.gz).  Now run "tar -rf" to add the spec file into the tarball. 
> Now you can run gzip to compress the tarball.
> 
> 5. Skip creating rpms ... source or "binary".  Create a mechanism to produce a
> snapshot tarball.  To get an rpm, rpmbuild -ts works just fine.
> 
> I have implemented something like the above as a bash script for another
> project.  If you want, I will take a shot at implementing this as part of
> setup.py ... just point me where to look and where to change things for the
> virt-manager --version.
> 

I started replying to things individually here but I got confused: what's the
end goal exactly? 'python setup.py rpm' generates a uniquely named rpm based
on the current commit? Who does this benefit?

If it's beneficial, I'd rather just make it a new subcommand like 'python
setup.py gitrpm'. You could likely overwrite the RPM version values with
rpmbuild options, rather than revive virt-manager.spec.in mangling which I'd
like to avoid if possible.

But really if this is about using RPMs as part of the development process, I'd
rather spend effort on making sure running virt-manager from the source tree
works.

Thanks,
Cole