[PATCH] better python plugins (well, better IMHO)

[Aaron Bentley]

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

John Arbash Meinel wrote:
> Aaron Bentley wrote:

>>You think *that* will slow down startup?  Personally, I think your
>>changes will slow down startup, because they require unconditional
>>loading of every plug-in the user has installed.  We have already been
>>trying to improve startup speed by reducing the number of useless
>>imports-- this is a push in exactly the opposite direction.
> 
> 
> I agree that searching in subdirectories is just fine. I originally
> implemented it, but there was some hesitance, so I pulled it back out to
> try and get plugins merged. Which I was very happy to see did occur.

I was happy that they were merged, as well.  I don't fault you for
taking that functionality out.  I just thought it was unbelievably
hypocritical for Lalo to say searching subdirectories would slow down
startup while introducing a system guaranteed to slow down startup much
more significantly.

>>When plugins are just for commands, you can load only the command you
>>need.
> 
> There are a couple of issues here. First is that you have plugin
> commands that operate at the top-most level. So they create a new "bzr
> foo" command. But I also agree with Lalo that it is possible to want
> lower-level plugins. Perhaps something that adds a new filesystem
> protocol. With our discussion of having a BranchStorage object, it could
> be very possible to have plugins to support various protocols.

I'm still not convinced that everything in the system should be made
pluggable.  You can easily run into situations where defective plugins
cause data loss, and since it's not obvious that code that caused the
data loss came from a plugin, bzr could well be blamed, just as Windows
is often blamed for flaws in third-party drivers.

But if we assume that third-party plugins for core functionality does
make sense, it doesn't follow that we should treat command plugins the
same as other plugins.  If we treat them differently, then we can say
things like when we load "bzrlib.tree", let's load any plugins called
"tree.py".  That means you still only load plugins at need, not all the
time.

>>That doesn't seem to be the way plugins are currently handled, but it
>>could be, and for my money even searching subdirectories under that
>>system would be faster than your proposal to load every single plugin
>>every time bzr is run.
>>
> 
> True, but how do you handle the case where you want to add functionality
> that is not a command?

What I described above is one way.  A short-term solution for the export
case would be to supply a wrapper export command plugin, that actually
monkey-patched the export functionality.

> PS> Just to clarify, I understand your reasoning behind wanting to
> search subdirs and I support it. I just wanted to get plugin support
> merged.

Yeah, I'd make that tradeoff too.  Thanks for getting it in there.

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

iD8DBQFCrG7C0F+nu1YWqI0RAsCOAJ9o1sttRX7snzBKJM3wn2vUpGEvVQCeL3mk
CVQcYr84RQ2UimuN38/lJ0A=
=NaAW
-----END PGP SIGNATURE-----