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.0
+0900
+++ portage-plugin-framework/pym/plugins/__init__.py 2005-11-12
21:52:15.0 +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
pgpdQlmVfTpMW.pgp
Description: PGP signature
