[TIP] Coming changes to unittest2 plugins

[Olemis Lang]

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 ...

>>
>> 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 .

> 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 ...

> 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
?

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 .

> (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
(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)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article: