default plugin path

[Aaron Bentley]

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

Robert Collins wrote:
> On Mon, 2009-01-26 at 22:12 -0500, Aaron Bentley wrote:
>> Robert Collins wrote:
>>>>> which is a dead chicken.
>>>> If you mean it's voodoo, I disagree.  It's reasonably easy to understand.
>>> Its easy to understand but its replicating logic that in the common case
>>> isn't needed.
>> There is no common case.
> 
> Sure there is - pqm, every microscript I've seen, bzr itself, all want
> the bzrlib default path setting logic. AFAIK only launchpad and
> bundlebuggy want something different.

Every bzrlib client I've worked on was afflicted by something like this.
 Including hitchhiker.

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

> Their code looks identical in both cases. So
> its transparent to them.
> 
>>> (there is a bug in the path setting at the moment affecting
>>> normal bzr as well as bzr clients), what harmful effects would setting
>>> the path by default at module load have?
>> 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.

> One of the following applies:
>  - the client author doesn't load plugins at all - non issue
>  - the client author wants the same plugins bzr loads - no action needed
>    vis-a-vis the path
>  - the client author wants a specific path - they set the path as 
>    desired
> 
>>>> 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.

>>> And both can set it to whatever they like *anyway*.
>> Yeah, but they need to remember to do that.  These are the sort of bad
>> defaults that look right up until the point that stuff starts breaking
>> for all users.
> 
> There are currently two bits of damage:
>  - the path is wrong for *all users* including bzr itself. bug
> https://bugs.edge.launchpad.net/bzr/+bug/316192 has discussion on this. 

I don't agree.  It looks completely correct for a system-installed bzr.

>  - clients have to know to call a function to allow callouts to *any*
> plugin to work.

Clients are expecting that.  Having "from bzrlib.plugins import
bzrtools" Just Work without any kind of set-up is weird.

> I'm happy to make the second depend on fixing the first, to avoid
> breaking clients like lp that were affected by bug 316192. But I don't
> think that the situation today is better than what we had in e.g. bzrlib
> 1.0!

And I do, and that's why I landed the patch I did.

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

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

iEYEARECAAYFAkl+hKwACgkQ0F+nu1YWqI14PACfaizNWCQWb1sEXiud2csB1vUQ
U/8An3qgdpL1BWipOES83erjD4pqFfch
=XxxO
-----END PGP SIGNATURE-----