[MERGE] make plugins use the right suffixes

[Martin Pool]

On  2 Aug 2006, Robert Collins <robertc at robertcollins.net> wrote:
> On Tue, 2006-08-01 at 08:41 -0500, John Arbash Meinel wrote:
> > Robert Collins wrote:
> > >>>> import imp
> > >>>> # handwave - do a directory listing of both system plugins and user
> > >>>> # plugins and strip back the paths to the first '.'. Then:
> > >>>> for name in candidate_set:
> > >>>>     try:
> > >>>>         mod_info = imp.find_module(name, [user_plugin_dir,
> > > system_plugin_dir])
> > >>>>     except ImportError:
> > >>>>         # no module by this name -
> > >>>>         mutter()
> > >>>>     module = imp.load_module('bzrlib.plugins.' + name, mod_info[0],
> > > mod_info[1], mod_info[2])
> > >>>>     setattr('bzrlib.plugins', name, module)
> > > 
> > > That should be all we need to do. find_module takes care of pyo vs pyc
> > > vs __init__ etc etc etc.

I'm somewhat squeamish at having no visible message for import failures
-- the user will just see it apparently ignore a new plugin if it's not
just right.  In particular if you put in a module called say
'bzrtools.abentley' then it will try to load the first part, fail, and
ignore it.

Why not just give a warning for all of them?  If it's because there are
some file extensions (.py~) which should clearly be ignored, then we
should filter by extension when building the candidates.

> > For modules ending in 'module.' we could also create 2 entries. foo and
> > foomodule, preferring to load the first form. (Very few people would
> > name their module foomodule.py).
> 
> We could, so the question is 'which form of confusion is better' :). I'm
> inclinded to say 'supporting foomodule.so is worse' simply because itse
> more code for us.

So can you have a C or Pyrex extension just called foo.so or foo.dll?

> There are two forms of failure: Failure in names and failure in content.
> The find_module failures are failures in name only, and thus I dont
> think worth logging. 

What kind of situation will cause an error here that shouldn't be
reported?  I think many of them will need user attention.

> (Perhaps we could detail the activity with a -v
> option to 'bzr plugins' for debugging).

Or by a -D global that shows mutter output.

> > ^- only downside is that a lot of plugin names will have to change. And
> > it means you have to be very explicit about the naming structure. So
> > that someone can only do:
> > bzr get http://my/plugin/foo
> > 
> > If you don't have:
> > plugin/dev
> > plugin/mainline
> > plugin/bzr-0.8
> > 
> > I really think it might be better to load the plugin, and look for
> > something in the main file like OFFICIAL_PLUGIN_NAME='foo', and then set
> > bzrlib.plugins.foo = imported_plugin
> > 
> > Then it doesn't matter what the path on disk is.
> 
> This is much more complex to maintain and leads to problems where you
> have the same plugin twice in your plugin dir. I'm really against this
> complexity for a number of reasons:
>  - stock python does not have this. Because of this its not predictable
> to people that our plugins will do it. It stops them being 'just python'
> and makes them something special.
>  - We'll need to write much more code if we want to support direct
> import of the plugins - we'll need a sys_meta hook, and thats about 5-10
> times as complex conceptually.
>  - We'll have more work to do to figure out what any plugin is meant to
> be.
>  - Its not directly understandable by a user - even after documenting
> this I expect we'll see problems where people think that renaming things
> on disk is enough to disambiguate rather than moving them out of the
> search path because the internal name is different.

John has a good point about branching, it does either constrain how the
branches are named, or require very slightly more complex installation.
(Giving a target name for the branch.)

But still, I agree with Robert - being consistent with Python, for all
its warts, is more important.

-- 
Martin