[TIP] Coming changes to unittest2 plugins

Olemis Lang olemis at gmail.com
Tue Sep 28 12:48:59 PDT 2010


On Mon, Sep 27, 2010 at 3:19 PM,  <exarkun at twistedmatrix.com> wrote:
> On 07:08 pm, holger at merlinux.eu wrote:
>>
>> On Mon, Sep 27, 2010 at 18:50 -0000, exarkun at twistedmatrix.com wrote:
>>>
>>> On 06:36 pm, holger at merlinux.eu wrote:
>>>>
>>>> On Mon, Sep 27, 2010 at 17:51 -0000, exarkun at twistedmatrix.com wrote:
>>>>>
>>>>> On 05:09 pm, holger at merlinux.eu wrote:
>>>>>>
>>>>>> On Mon, Sep 27, 2010 at 16:17 -0000, exarkun at twistedmatrix.com wrote:
>>>>>>>
>>>>>>> But this difference doesn't matter.  If someone wants to specify a
>>>>>>> method of an inner class to be used as a plugin - great!  As far
>>>>>>> as I
>>>>>>> can tell, unittest2 doesn't care.  The : doesn't add anything.
>>>>>>
>>>>>> In context of generic distutils2 entry point-like specification we
>>>>>> are not only talking about plugins but also command line main()
>>>>>> functions etc.
>>>>>
>>>>> Where, again, the difference does not matter.
>>>>
>>>> It does if you want more or something else than loading a live object.
>>>
>>> Yes?  And do main points or unittest or distutils plugins want more than
>>> this?
>>
>> 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.

generally speaking ...

- code generation
- intercept calls in restricted environments and assert correct module names
  to detect possible
- diagrams generation
- models extraction
- data mining (relationships | dependencies)

generally speaking ... if talking of unittest plugin to load live
objects that's another situation.

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

>>> And even if you do, then once you have the live object, you can
>>> do whatever else you want with it.
>>
>> no doubt.  And what if i can't get at a live object because i am
>> on the wrong platform or am missing a dependency?
>
> I don't know.  I still don't know what you want to do with these things
> except use them for their intended purpose.
>

example above ... and the *dot* notation would be a PITA, AFAICS .

-- 
Regards,

Olemis.

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

Featured article:



More information about the testing-in-python mailing list