Bundling more plugins into bzrtools

[Toshio Kuratomi]

James Henstridge wrote:
> On 14/02/2008, Toshio Kuratomi <a.badger at gmail.com> wrote:
>> setup.py does help just as making tarballs for releases helps.  We have
>>  a template in Fedora for distutils/setuptools using packages so these
>>  things do cut down on how much time we spend reinventing the wheel but
>>  it is still much more effort for a packager to package twenty packages
>>  rather one.
>>
>>  There is the one-time cost of writing suitable descriptions for each of
>>  those packages, checking them for errors, sending them through our
>>  review process, doing the initial import and build.
> 
> Does the description from the setup.py file help in filling in the
> blanks for a new package?
> 
Yes, if it exists and is comprehensive enough.  Something like::
   description='Statistics plugin for Bazaar',
   long_description="""
   Simple statistics plugin for Bazaar.
   """
or::
   description="dbus core plugin for bzr.",

is not really optimal for telling an end user why they want to install a 
certain plugin package.  So the packager ends up checking setup.py, 
checking any included READMEs, checking for a blurb on the website, and 
finally checking the output of --help and writing up something as best 
they can. As a comparison, our current description for the bzrtools 
package was an easy to write summary of the descriptions on the bzrtools 
website::

BzrTools is a collection of plugins for Bazaar(bzr).  Among the included
plugins are:
* rspush - uses rsync to push local changes to a remote server
* annotate - prints a file annotated with the revision next to each line
* baz-import - (Requres PyBaz) import an arch archive losslessly into bzr
* shelve/unshelve - allows you to undo some changes, commit, and restore
* clean-tree - remove unknown, ignored-junk, or unversioned files from 
the tree
* graph-ancestry - use dot to produce banch ancestry graphs
* shell - a bzr command interpreter with command completion
* patch - apply a patch to your tree from a file or URL

>>  Then there is the
>>  recurring cost of rebuilding them whenever a distro-wide event requires
>>  it.  For instance, when we switched from python-2.4 to python-2.5 we had
>>  to rebuild all of our packages.  The packager would have to kick off a
>>  rebuild for each package in this situation instead of just one.
> 
> You don't have a way to automate those sort of rebuilds?
> 
Yes and no.  When we do mass rebuilds we give maintainers the option to 
do rebuilds on their own.  That way a responsible maintainer has a 
chance to look for updated packages, apply any patches they've been 
working on, and most importantly, and fix things if the new version of 
python/gcc/other build tool breaks their package.  Anything not taken 
care of by a cutoff date is rebuilt by a script.  If there is breakage 
in the build (for instance, python-2.5 added egg-info to modules using 
distutils so many filelists had to be updated), a packager could end up 
writing patches or modifying the spec file for each of the affected 
packages instead of fixing it once for the package as a whole.

>>  Another
>>  rebuild example (worse because it required patching the package spec
>>  files) came when bzr started including compilable modules for speed.
>>  Since Fedora is a multilib distro, all the plugin packages had to be
>>  switched to storing their files in /usr/lib64/[...]/bzrlib on x86_64
>>  instead of /usr/lib/[...]/bzrlib.
> 
> That does sound like a problem with the way plugins are stored on the
> file system.  I suppose it means you can't share the plugin package
> between x86 and amd64 even though they may be architecture independent
> themselves.
> 
> Perhaps it'd be worth configuring bzr to look in
> /usr/lib/pythonX.Y/site-packages/bzrlib/plugins too for your amd64
> builds?
> 
If bzr could do that it would be awesome!  I don't know how the plugin 
architecture works internally but if it relies on python's import to 
find the plugins you'll have some code to write, though.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080214/73ad93eb/attachment.pgp