On 5/17/12 4:38 PM, Doug Hellmann wrote:
<snip>
In the wikistatus plugin I notice that you modify the global FLAGS
when wikistatus.py is imported. Is that the right time to do that, or
should it happen during the on-load handler in the plugin class? Or
maybe even in the plugin manager, which could ask the plugin for the
new options and then modify FLAGS itself. It seems like lots of Nova
code modifies FLAGS during import, but having an explicit trigger for
that (rather than depending on import order) seems safer to me.
I don't feel strongly about this -- I'm just following the example set
by existing Nova code. Can you think of a corner case where loading it
at import time would cause problems? Alternatively, can you think of a
corner case where we would want a flag to be defined during the magic
moment /between/ import time and the load callback?
I can't think of a case for either, although I have the vague feeling
that the latter is slightly more possible (if still improbable.)
If the entry point for each plugin is given a unique name (instead of
being called "plugin", as the sharedfs plugin is) we would be able to
log "loading plugin X" as well as provide options to control which
plugins are activated. I don't know if that latter idea is a goal or not.
If leaving in that option is free, then I'm all for it. I'm still a bit
new to entry points... is the entry-point name a totally arbitrary string?
Also, is supporting unique names the same thing as /requiring/ unique
names? Would this ultimately result in us needing a governed,
hierarchical namespace?
- Two different loading pathways -- is that useful or just confusing?
"One and only one obvious way to do it."
OK, I'm convinced. Outside of the common client, are entrypoints
already a hard dependency elsewhere in OpenStack such that we don't lose
anything by requiring them?
- Should the plugin base class interpose itself between the plugin
and python-openstackclient in order to enforce interface
versioning? Is that even possible?
We could probably figure out a way to do that, but I don't know why
you would want to. What did you have in mind? Which interface are you
worried about versioning, the CLI itself?
I'm not sure I do want to, but here's my concern: Right now the common
client's API for extending the commandline is entirely internal to the
common client itself. When I write the sharedfs plugin to make use of
that same API, I'm treating that internal API as external... and I don't
like being the only person in the world doing that.
Of course, if the expectation is that that common client API will soon
become public/documented/frozen anyway, then there's no problem.
-Andrew
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
