default plugin path

[Robert Collins]

On Tue, 2009-01-27 at 01:29 -0500, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> >> The client won't know that they consider it wrong until a bunch of their
> >> users break simultaneously due to a package upgrade.
> > 
> > I really don't follow here. Can you unpack what you mean?
> 
> The developer has a local copy of bzr 1.8 and bzrtools 1.8 specifically
> for the application "FooBaz", so that version skew doesn't affect him.
> He also has bzr and bzrtools 1.8 system-wide via the PPA.
> 
> He thinks he's importing bzrtools for the local bzr, but he's actually
> importing the system-wide bzrtools.  He releases FooBaz.  A bunch of
> people install it.

Thats precisely the other, unfixed bug. The system plugin path shouldn't
be included for a source-checkout bzrlib. If we fix that, he won't be
importing the system wide bzrtools under any circumstances unless he
actually uses a system installed bzrlib.

> bzr and bzrtools 1.9 are released, the PPAs are updated, the users get
> new system bzr and bzrtools.  Now FooBaz is importing bzrtools 1.9, but
> 1.9 expects bzrlib to support lazy command registration.  FooBaz's
> bzrlib has 1.8, so importing bzrtools starts giving AttributeErrors.
> 
> Since everyone's got bzrtools 1.9 via the PPA, not only is the developer
> affected, but most of his users, too.

Yes, that would suck. Its not related to a default path setting though.
The current situation of explicitly setting a path will go *just as
bad*, with the exact same symptoms.

> >>>> It would be setting bzrlib to load plugins that the client author hasn't
> >>>> requested.
> >>> No. Its telling bzrlib *where* plugins are found, but in itself isn't
> >>> loading any.
> >> Yes, exactly.
> > 
> > I really can't get any sense out of this - I disagree, and you say that
> > my statement about what its doing is correct. 
> 
> I didn't mean to say it was causing bzrlib to load plugins.  I meant
> that it was configuring bzrlib to load plugins — if and when it loaded
> plugins — from locations that the author hadn't specified, therefore
> getting the wrong versions.

Ok, we're sync()ed here.

> >>>>>> Launchpad and Bundle Buggy have both been hit by bad default plugin
> >>>>>> paths, even though Launchpad tried to control the plugin path.
> >>>>> I know that - but I'm not proposing to *load plugins*, only to set the
> >>>>> path.
> >>>> Which would mean that the wrong plugins would be loaded if we used the
> >>>> "from foo import bar" method.
> >>> The same logic is used for 'from bzrlib.plugins.foo import bar' as for
> >>> 'load_plugins()' - a search path is searched to find foo, and it is
> >>> imported into bzrlib.plugins.foo.
> >> Right.  And the wrong version of a plugin can be loaded that way, when
> >> instead what you should get is an import error.
> > 
> > No version of a plugin is *also* wrong.
> 
> No, it's not necessarily wrong.  Plugins may be loaded conditionally.
> bzr loads bzrtools conditionally, for example.

By which you mean --no-plugins?

> > And if the default path was
> > being used, which most library clients want, then they will *still* get
> > the wrong version of a plugin loaded, instead of an import error.
> 
> But if they ask for the wrong thing, they can't complain when they get
> the wrong thing.

They would be getting what bzr itself gets, which is very important as a
default, because most applications of bzrlib I can think of will use bzr
as a debugging tool- you want the same plugin versions to be loaded when
you drop into a shell and run '/path/to/bzr log BRANCH' or whatever.

> > There are precisely three cases:
> >  - default path wanted
> >  - a specific path wanted
> >  - no plugins wanted
> > 
> > The third case is clearly uninteresting (just don't import anything from
> > any plugin).
> > 
> > The first case is what I am asserting is the common case. Any library
> > client wanting that case will before 1.10 have done nothing special
> 
> No.  Most of them will have called load_plugins.  The client that uses a
> plugin directly is very rare.

Perhaps for you; many clients I know of want plugins directly -
loggerhead, whatever jamesh' script was, a bunch of other micro tools I
have written.

> >> Clients are expecting that.  Having "from bzrlib.plugins import
> >> bzrtools" Just Work without any kind of set-up is weird.
> > 
> > I don't think its weird at all. Every plugin has a name, and its code is
> > accessible under that name. It works great.
> 
> All packages I've ever encountered, with the sole exception of
> bzrlib.plugins had a single directory that corresponded with the
> package.  Even if it's correct, it's still weird.

mmm, well we can disagree here I think. I mean, heck, the package '' has
many directories attached to it. You can't use python without this
functionality.

> >>> And the simplest comparison is that more code is needed now than
> >>> then - clearly a regression IMO.
> >> I don't agree with the premise that requiring more code makes something
> >> worse.  I believe that explicit is better than implicit, even though it
> >> tends to be more wordy.
> > 
> > It is indeed in 'import this' - but its rule of thumb.
> 
> Right, and here I was not saying that explicit is better than implicit
> was right, but that it was in clear conflict with *your* rule of thumb,
> something like "less code is better".  I was saying it's not "clearly a
> regression".  Even if I were to stipulate that it's a regression, it
> wouldn't "clearly" be so.
> 
> > Another great one
> > is sane defaults - and this default isn't sane because it works for
> > noone. 
> 
> Another great one is "In the face of ambiguity, resist the temptation to
> guess."

When guessing does no harm, guess the most common default and let users
override. We do this in bzr itself all the time - we choose a default
log format, a default disk format, we guess that 'foo' is a file path
and not a malformed relative url, we guess at encodings etc etc etc.

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090128/0b435d79/attachment.pgp