<br><br><div class="gmail_quote">On Fri, May 18, 2012 at 12:16 PM, Andrew Bogott <span dir="ltr"><<a href="mailto:abogott@wikimedia.org" target="_blank">abogott@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
On 5/17/12 4:38 PM, Doug Hellmann wrote:
<blockquote type="cite"><br>
<snip><div class="im"><br>
<div class="gmail_quote"><br>
<div>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.</div>
</div>
</div></blockquote>
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?<br></div></blockquote><div><br></div><div>I don't know enough about how the flags code works or whether the order of flag declarations matters. I based my comments on the fact that I have been burned in the (distant) past by library code that modified global state on import (Zope) so I avoid the pattern and stick with explicit triggers. If the flags module supports modification in an indeterminate order, which the existing convention implies, then what you have should be fine.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
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.)<div class="im"><br>
<br>
<blockquote type="cite">
<div class="gmail_quote">
<div><br>
</div>
<div>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.</div>
</div>
</blockquote></div>
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?<br></div></blockquote><div><br></div><div>The names need to work as variable names for ConfigParser. I don't think they can include whitespace or '.' but I'm not sure about other restrictions.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
Also, is supporting unique names the same thing as /requiring/
unique names? Would this ultimately result in us needing a
governed, hierarchical namespace?</div></blockquote><div><br></div><div>You cannot have two entry points with the same name in the same setup.py, but you can have duplicate names from different setup.py files. Whether you want to do that depends on how you are using the plugins. In this case, it shouldn't matter if there are duplicates *unless* we provide an option to enable/disable plugins.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="im"><br>
<br>
<blockquote type="cite">
<div class="gmail_quote"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Two different loading pathways -- is that useful or just
confusing?<br>
</blockquote>
<br>
<div><br>
</div>
<div>"One and only one obvious way to do it."</div>
</div>
</blockquote>
<br></div>
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?</div></blockquote><div><br></div><div>>From what I have seen all of the projects use setuptools/distribute for packaging, so using entry points will not add any new dependencies.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="im"><br>
<br>
<blockquote type="cite">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Should the plugin base class interpose itself between the
plugin and python-openstackclient in order to enforce
interface versioning? Is that even possible?<br>
</blockquote>
<div><br>
</div>
<div>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?</div>
</div>
</blockquote>
<br></div>
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.<br></div></blockquote><div><br></div><div>The command plugin API for the common CLI is intended to be public and will be documented. I thought we were going to put the command implementations in project-specific packages (so that you only got the quantum commands if you installed the python-quantumclient package, for example). Dean convinced me we should just put the core stuff into one package, so we went that route. Extensions can plug directly in. We will document the base classes within the openstackclient library, but extensions can also write directly against the cliff framework classes if they do not need any of the features specific to the unified CLI.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
Of course, if the expectation is that that common client API will
soon become public/documented/frozen anyway, then there's no
problem.<span class="HOEnZb"><font color="#888888"><br>
<br>
-Andrew<br>
<br>
</font></span></div>
</blockquote></div><br>