[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