<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 6, 2015 at 4:15 PM, Thomas Goirand <span dir="ltr"><<a href="mailto:zigo@debian.org" target="_blank">zigo@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">tl;dr: let's add a exception handling so that python-*client having<br>
conflicting command names isn't a problem anymore, and "openstack help"<br>
always work as much as it can.<br></blockquote><div><br></div><div>This creates a first-one-wins scenario that requires *-client install order to be deterministic.   Or we need a registry of which API owns which object namens (nouns), which would actually solve our problem today without any changes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Longer version:<br>
<br>
This is just a suggestion for contributors to python-openstackclient.<br>
<br>
I saw a few packages that had conflicts with the namespace of others<br>
within openstackclient. To the point that typing "openstack help" just<br>
fails. Here's an example:<br>
<br>
# openstack help<br>
[ ...]<br>
  project create  Create new project<br>
  project delete  Delete project(s)<br>
  project list   List projects<br>
  project set    Set project properties<br>
  project show   Display project details<br>
Could not load EntryPoint.parse('ptr_record_list =<br>
designateclient.v2.cli.reverse:ListFloatingIPCommand')<br>
'ArgumentParser' object has no attribute 'debug'<br>
<br>
This first happened to me with saharaclient. Lucky, upgrading to latest<br>
version fixed it. Then I had the problem with zaqarclient, which I fixed<br>
with a few patches to its setup.cfg. Then now designate, but this time,<br>
patching setup.cfg doesn't seem to cut it (ie: after changing the name<br>
of the command, "openstack help" just fails).<br></blockquote><div><br></div><div>This is a problem with the implementation of the plugin, not with the selection of command names.  Your experience with saharaclient and the fact that editing setup.cfg did not help should confirm that.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Which leads me to write this:<br>
<br>
Since we have a very large amount of projects, with each and everyone of<br>
them adding new commands to openstackclient, I would really nice if we<br>
could have some kind of checks to make sure that conflicts are either 1/<br>
not possible or 2/ handled gracefully.<br></blockquote><div><br></div><div>The conflicting command names is due to the way setuptools handles entry points by default (I'm not sure if this can even be changed easily).  It turns out that having multiple classes registered to a common command name is useful, I have a plugin that does this intentionally in order to modify the behaviour of an existing command (changes server create to add --ram, --disk and --cpu to auto-select a flavor).</div><div><br></div><div>dt</div></div><div><br></div>-- <br><div class="gmail_signature"><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a><br></div>
</div></div>