Re: [gentoo-portage-dev] Plugin framework

[Brian Harring]

On Mon, Nov 14, 2005 at 10:38:28PM +0900, Jason Stubbs wrote:
> On Sunday 13 November 2005 11:57, Brian Harring wrote:
> > >   filenames.
OT, but return of the funky 'A's...
Curious if others are seeing it, or if my nano/mutt setup just plain 
sucks.

> > > * portage.py edits to the config class to make use of the framework.
> > >
> > > Essentially, plugins.registry gives dict access to modules under
> > > plugins/. To give an example, the plugins.cache.anydbm.anydbm class can
> > > be accessed via plugins.repository["cache"]["anydbm"].
> >
> > Offhand... you're duplicating pythons "first found" for module
> > namespace, which I'm not particularly much for, at least for a
> > registry framework.
> >
> > If you're going to introduce a plugin registry, allow the plugins to
> > exist wherever they want in python namespace, and have the registry
> > entry point to it (preferably lifting code from 3.0 where possible
> > also).
>
> I'm not familiar with this. If it works better than what I've got now without
> having to hardcode what plugins are available, I'm all for it. Perhaps
> registry is the wrong word for what I was trying to do...

No... registry's probably apt. :)

If this were mainlined, I'd prefer a tool that registers the plugin 
portage uses- do this, and /etc/portage/modules can go away, using a 
generic framework instead.

I'm not much for on the fly determination via inspecting namespace- 
too easy for it to bite users in the ass, imo.  


> > Meanwhile, couple of code comments, then final comments...
> >
> > > diff -uNr portage-orig/pym/plugins/__init__.py
> > > portage-plugin-framework/pym/plugins/__init__.py ---
> > > portage-orig/pym/plugins/__init__.py	1970-01-01 09:00:00.000000000 +0900
> > > +++ portage-plugin-framework/pym/plugins/__init__.py	2005-11-12
> > > 21:52:15.000000000 +0900 @@ -0,0 +1,80 @@
> > > +class registry:
> > > +
> > > +	class _plugin_loader:
> >
> > Shoving the _pluging_loader class into the registry class namespace
>
> Strange obsession with keeping the namespace empty.

__all__ is a useful module attribute if you're concerned about 
from somemodule import *

> > makes it a bit hard for derivatives of registry to be implemented.
>
> I can't see any possible reason to want to derive from it. The point of it is
> that pulling external code in should be seamless. If it doesn't serve as is,
> I'd prefer that it be fixed rather than putting the functionality somewhere
> else.

Nothing real is lost by not hiding it.  It probably will never be 
derived from, but that doesn't mean we hide it blocking the possibility 
from ever occuring either. :)

> > > +			self._path = path
> > > +			self._loaded = {}
> > > +
> > > +		def __getitem__(self, name):
> >
> > This is not thread safe (addressed in 3.0)
>
> This is an interesting point. I wasn't thinking about thread-safety at all,
> but when should I be? Should everything be implemented with thread safety in
> mind? If not, at what point should the line be drawn?

My view on it is if you're implementing global objs, new stuff should 
be thread safe if it's sane.

Plugin registry is something I'd define, at least for the imports, as 
code that should be as defensive as possible (eg, atomic).

> $ python -c 'import plugins; print dir(plugins)'
> ['__builtins__', '__doc__', '__file__', '__name__', '__path__', 'registry']
>
> There's something attractive about the above, but I'm not married to it.
dir() isn't real useful aside from introspection/development imo;

Imo, appropriate pydoc strings tacked in ought to mitigate any issues 
in terms of pollution/uglyness.

> > config.module_priority is _evil_ (yep, first I've noticed that gem).
> > If a user specified cache backend can't be loaded, falling to a
> > default is a great way to piss users off (that's a bad 'helpful'
> > feature).  Meanwhile, back to your patch...
>
> Actually, that was also my mistaken addition. The original code uses
> module_priority but only tries loading the first found. More
> misguidedness. :(

Eh... module_priority should die, regardless if you've expanded upon 
it or not.

Ironic I'm stating portage should be made dumber then it is, but 
'helpfullness' when an app reverts user choices is something that 
always has bugged the hell out of me. :)

> So, as I said before, the point is to unify plugin management. Instead of
> having the imports done wherever something can be plugged in, unify that and
> do it all in one place. The cache and elog plugin selection(s) come from user
> settings but emaint (and repoman whenever that happens (and possibly even
> emerge itself one day?)) needs to automatically detect what's available and
> use it.

User settings is system specific settings really; this is getting back 
to why I think this should be an actual registry (as in on disk).

I'll take a look at ripping portage.plugins out of 3.0, and integrate 
it into 2.0.  The api differs, but wrapping it's base api with a dict 
style class isn't too hard to do.
~harring