Bundling more plugins into bzrtools

[James Henstridge]

On 15/02/2008, Toshio Kuratomi <a.badger at gmail.com> wrote:
> 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

There is certainly room for improvement here.  I guess one of the
reasons why many setup.py's have minimal descriptions is that they
aren't perceived to be useful.

If they are useful (e.g. for packages), perhaps plugin authors would
put more time into them?

>  >>  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.

The code responsible for setting the plugin path is set_plugins_path()
in bzrlib/plugin.py.

It currently uses the contents of $BZR_PLUGIN_PATH (or a default value
for that env var) plus the main bzrlib.plugins directory.  Perhaps
appending /usr/lib/pythonX.Y/site-packages/bzrlib/plugins to the end
when on multilib systems would be enough to allow you to keep your
plugin packages as noarch.

James.

>
>
>  -Toshio
>
>
>