Dependencies in the PPA for Jaunty

[Martin Pool]

2009/6/23 Andrew Cowie <andrew at operationaldynamics.com>:
> On Mon, 2009-06-22 at 14:35 -0700, Maritza Mendez wrote:
>
>> I took Aaron's advice and went back to trusting the PPA's.  I really
>> tried.  It was less than a day before I found myself driven back into
>> the hard choices Joseph is describing.
>
> At the risk of being off-topic, there are some views that I'd like to
> offer.
>
> 1) Plugin architectures appear to be an anti-pattern
> ----------------------------------------------------
>
> I know that the Bazaar hackers think their plugin system is brilliant.
> And it is. It's mature, well thought out, and capable.
>
> But the sort of confusion and pain being described on this thread is
> very common as soon as anyone starts trying to *package* plugins.

I haven't heard anyone say it's perfect or brilliant in every regard.
Some things are pretty nice - moderate api stability despite frequent
releases, and the ability to connect to foreign VCSs through plugins.
The overall experience of installing and keeping plugins up to date,
and getting them updated, is not so good.

I don't think anyone is complacent about the need to fix it, it's just
that there are many other things we want to fix too.  Slow network
roundtrips drove people away too: it's now down to about 7 for a
typical push or pull, and I do think that was better to do first.

Actually, maybe the possibility of plugins does cause a kind of
complacency, that we would confront these problems more directly,
perhaps by having one big tree, if they didn't exist.

I would agree that plugins can be an antipattern because things that
need to be separately installed don't exist for most users - much like
software that's not in apt doesn't exist or doesn't matter to Debian
or Ubuntu users and a bzr release with no binary doesn't exist for
Windows users.  Firefox, after a lot of work and several missteps, has
a pretty good plugin system but I'd guess the majority of users have
zero installed.

(Shipping everything can be an antipattern too.  Python has trouble
evolving the standard library and applications have trouble relying on
fixes to it, but that's too far off topic.)

There are a few complementary things we can do:

1- Merge plugins into the core.  This is not enough by itself but it's
relatively easy to do, and we should just do it for things like
rebase: anything small, that's not changing rapidly and that won't be
a problem to have installed by default might as well be merged.
Having a small tree for its own sake is not worth, given the
technology that exists today, the problems it causes.

2- Make installers/packages of interesting plugins, preferably in sync
with bzr releases.  This also means more cross testing, and putting
the plugins into say a buildbot and checking the results.

3- Extend the plugin system so that it has a concept of installing or
updating plugins without the user needing to know where specifically
they're being pulled from.  This would be neat, but I think it's
actually the least useful, partly because many users already have some
kind of OS-level package management system and it's better to be
packaged within that than to work around it.  Because many interesting
packages like bzr-svn or qbzr have OS-level dependencies we can't
easily solve the whole problem.

-- 
Martin <http://launchpad.net/~mbp/>