default plugin path

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> On Mon, 2009-01-26 at 22:51 -0500, Aaron Bentley wrote:
>> Robert Collins wrote:
>>> On Mon, 2009-01-26 at 22:12 -0500, Aaron Bentley wrote:
>>>> Robert Collins wrote:
>>>>>>> What harmful effect will setting the path have?
>>>>>> It will cause bzrlib clients to load bzr plugins from the system path,
>>>>>> which will be incompatible with their local version of bzrlib.
>>>>> If I put a patch forward that doesn't spuriously add the system python
>>>>> to the path
>>>> Adding the system python to the path is *right* for many cases.  It's
>>>> also *wrong* for many cases.  Therefore the client should decide.
>>> Alternatively, which is what I'm proposing, the clients that consider it
>>> wrong can just change it.
>> 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.

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.

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

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

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

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

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

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

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkl+qd4ACgkQ0F+nu1YWqI36XwCfR6uRDfmSE2cebKFupsCO28mU
bNgAn3yJfJDdgaDkkKmUDk1lpak2DC4J
=evAX
-----END PGP SIGNATURE-----