[TIP] Coming changes to unittest2 plugins

[exarkun at twistedmatrix.com]

On 09:04 pm, olemis at gmail.com wrote:
>On Tue, Sep 28, 2010 at 4:41 PM,  <exarkun at twistedmatrix.com> wrote:
>>On 07:57 pm, olemis at gmail.com wrote:
>>>
>>>On Mon, Sep 27, 2010 at 8:36 PM,  <exarkun at twistedmatrix.com> wrote:
>>>>
>>>>On 27 Sep, 07:42 pm, holger at merlinux.eu wrote:
>>>>>
>>>>>On Mon, Sep 27, 2010 at 19:19 -0000, exarkun at twistedmatrix.com 
>>>>>wrote:
>>>>>>>
>>>>>>>packaging meta data is for consumption of tools.  For example, i 
>>>>>>>want
>>>>>>>to
>>>>>>>write one that converts a newstyle setup.cfg into an oldstyle
>>>>>>>setup.py.
>>>>>>
>>>>>>What transformation do you need to perform on an arbitrary,
>>>>>>application-
>>>>>>specified fully qualified Python name?  In general you can't know
>>>>>>anything about it, whether it has a ":" in it or not.
>>>>>
>>>>>Wrong. The ":" carries information.  For example, if we have:
>>>>>
>>>>>  [global]
>>>>>  script-entry-points =
>>>>>      somescript = testpath.to:some.function
>>>>>
>>>>>we can easily generate an oldstyle setup.py from it:
>>>>>
>>>>>  setup(entry_points={'somescript': 'testpath.to:some.function'}, 
>>>>>...)
>>>>>
>>>>>without having to load live objects.  The dotted name does
>>>>>not allow that and thus carries less information.
>>>>
>>>>Thanks for explaining that.  This is clearly a case where the ":" 
>>>>helps
>>>>(a
>>>>sort of self-referential case, where the ":" is only needed because 
>>>>it
>>>>used
>>>>to be needed).
>>>>
>>>>It's not an important case to me (and I don't think it should be
>>>>important
>>>>to anyone else).  It's still nice to know *why* the ":" might be 
>>>>desired
>>>>though.
>>>
>>>What d'u think of the example I mentioned before (i.e. the Trac 
>>>plugin
>>>(macro?)  for the lazy dev ...) ???
>>
>>This one?
>
>kind of ...

Why "kind of"?  It's a direct quote from your email.  If you meant 
something else, please say what.
>>>
>>>However, suppose I'm developing some apps (each one under top-level
>>>folder in VCS) adding unittest plugins and I want to develop a Trac
>>>plugin (macro ?) that will know the path to top-level folder in VCS
>>>and will look for unittest metadata definition inside setup.* (or
>>>wherever it might be defined ...) of all direct descendants (i.e.
>>>folders). With this data it will render inside a floating div some
>>>links to Trac repository browser area (e.g. highlighting the lines
>>>where the plugin code is located) . That would allow me to quickly
>>>find plugin code inside e.g. repository browser and wiki pages (/me
>>>the lazy dev ) .
>>
>>I have a little difficulty following it.  That said, unless I've 
>>gravely
>>misunderstood, it sounds like you can implement it without ":" just 
>>about as
>>easily as with.  Given "foo.bar.baz" look for foo/bar/baz.py. Exists?
>> Great, you're done.  Otherwise look for foo/bar.py.  Otherwise look 
>>for
>>foo.py.
>
>and this backtracking is definitely quite much more inefficient than
>loading the module directly . I hope you know that in this case I'm
>not talking about flat folder structure but rather about data stored
>in VCS changeset store , and streams are not file streams , but VCS
>internal streams .

No, I don't know that.  Maybe you should have a more efficient data 
store?  It's only approximately a constant difference, anyway.  I'm sure 
you spend more time thrashing the locks on your database or rendering 
html, so it probably doesn't matter.
>>It'll be wrong sometimes, but so will assuming that "foo.bar:baz" 
>>means to
>>look in foo/bar.py.
>
>no way if I say so . If that's wrong then there's an error in my code,
>so I better look a way to catch situations like these ...

Consider the possibility that baz is implemented in foo/_baz.py and 
exported via foo/bar.py.  The proper public name of the interface is 
foo.bar.baz, not foo._baz.baz.  But there's no way you can learn that 
from "foo.bar:baz" or "foo.bar.baz".  So if you think you'll find the 
source for baz in foo/bar.py because you saw either of those strings, 
you may be in for a surprise.
>>Without loading the code you can't be completely sure
>
>No way . I'm writing the code (and let's say I figured out to ensure
>it will be there before committing to VCS ;o) so how could I be wrong
>?

I don't really understand this, but hopefully my explanation above 
addresses it.
>
>IMO there's a difference between not to know because the syntax is
>ambiguous and not to find it in the place it was supposed to be
>because there's a bug . In the first case you are on your own &
>hopeless , in the second you'd be terribly mistaken .

As above.
>>(and maybe even if you load the code you'll still get it wrong 
>>sometimes,
>>I'm not sure).
>
>even if you are able load the code from VCS using Trac multi-VCS API

Involving a VCS and trac sort of muddies the waters.  The problem has 
nothing to do with either of these things, it has to do with the fact 
that an identifier like "foo.bar.baz" or "foo.bar:baz" doesn't tell you 
where the source code for something is, it tells you a name which you 
can use to get an object.  That's a very strong hint about where the 
source is, but it's not a guarantee.
>(something you might not want to do inside Trac unless we'are talking
>of installed plugins & apps ;o) you'll be guessing quite a lot of
>times (like I said before, this exact backtracking is the one I used
>when I patched Trac PyDocPlugin to make it compliant with PEP 302
>import hooks e.g. egg imports, so I know it very well ;o)

I don't really understand this.  You don't need to guess if you're doing 
the import.  The import will take care to resolve everything.  But 
several of the sentences in this paragraph appear to contradict each 
other (to the best that I can understand them), so I'm not really sure 
what point you're making.

Jean-Paul