[tahoe-lafs-trac-stream] [tahoe-lafs] #1405: python setup.py --help-commands raises exception

[tahoe-lafs]

#1405: python setup.py --help-commands raises exception
--------------------------+------------------------------------------------
     Reporter:  zooko     |      Owner:  davidsarah
         Type:  defect    |     Status:  new
     Priority:  minor     |  Milestone:  undecided
    Component:            |    Version:  1.8.2
  packaging               |   Keywords:  packaging setuptools docs reviewed
   Resolution:            |
Launchpad Bug:            |
--------------------------+------------------------------------------------

Comment (by zooko):

 I did some experimenting:

 1. If I {{{sudo apt-get remove python-setuptools}}}, thus removing
 {{{Distribute v0.6.15}}}, which is [http://packages.ubuntu.com/natty
 /python-setuptools distributed by Ubuntu] in Natty 11.04 under the name
 {{{python-setuptools}}}, then the exception {{{ImportError: No module
 named upload_docs}}} stops happening. If I {{{sudo apt-get install python-
 setuptools}}} to put it back on my system, then the exception starts
 happening again.

 2. If (while Ubuntu Natty's {{{python-setuptools}}} package is installed),
 I comment out [http://tahoe-lafs.org/trac/tahoe-
 lafs/browser/trunk/setup.py?annotate=blame&rev=5037#L72 line 72 and 73 of
 setup.py], which injects {{{zetuptoolz}}} into the current Python process,
 then the exception stops happening. If I comment those lines back in, the
 exception starts happening again.

 So I guess this is not a bug in {{{Distribute}}} itself, nor in
 {{{zetuptoolz}}} either, but is a conflict between the two of them. I
 guess that {{{Distribute}}} has added {{{upload_docs}}} to a list of known
 commands, but since {{{zetuptoolz}}} instead of {{{Distribute}}} is loaded
 into this Python process, {{{upload_docs}}} can't be imported. I'm
 guessing that {{{upload_docs}}} isn't in {{{zetuptoolz}}} but is in
 {{{Distribute}}}.

 Even if this is the case, then the solution encoded into attachment
 :tolerate-exceptions-in-help-commands.darcs.patch is still potentially a
 good solution. If there is a command listed in the available commands, but
 attempting to import it to get its usage string raises {{{ImportError}}},
 then perhaps just skipping it and not listing it in the {{{--help-
 commands}}} output is fine.

 Is there a useful unit test we could write to detect future regressions in
 attachment:tolerate-exceptions-in-help-commands.darcs.patch or conflicts
 between it and other code?

 Also: this makes me more interested in catching narrowly
 {{{ImportError}}}, since I currently think that this particular kind of
 conflict should not result in any other error than that.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1405#comment:4>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage