[py-dev] Re: cmdline options / rev 10344

[holger krekel]

Hi Armin, 

i CCed to py-dev in case others are interested (beware everyone, 
we are touching some deeper implementation issues here).  The 
following discussion starts off at the py-collect refactoring 
of cmdline option handling with respect to projects having 
custom command line options for py.test. 
 
On Fri, Apr 08, 2005 at 09:25 +0100, Armin Rigo wrote:
> On Tue, Apr 05, 2005 at 07:38:28PM +0200, holger krekel wrote:
> > if you feel like it it would be great if you would 
> > comment on rev 10344 on the py.test branch (i took
> > care to write a hopefully understandable log message).
> 
> Well, this problem is messy (did we mention that already?) and I think you
> have found a quite reasonable solution.  The "no-API" paradigm doesn't really
> apply around conftest files anyway: if I look at PyPy's, they depend on quite
> a lot of internal py.test stuff.  Having to actually call back a py.test.xyz()
> function doesn't change much.

Except that it is more obvious how you can get at the resulting values of 
custom Option definitions.  The idea is to try to reduce the globalness 
of the py.test API (and py.test.option.SOMETHING is pretty global ...). 

> Maybe conftest doesn't have to know about the Option class?  I mean, instead
> of py.test.addoptions('group', Option(...), Option(...)) we could have
> something like multiple calls to py.test.addoption('group', ...).

Yes, well, i agree to the intention but they are practical
problems. Single calls would make it non-obvious how to get to
the "option" value container from the conftest.py side.  And
passing a list of tuples or something would deride the use of
named arguments (which is the only way to somehow maintain
readable code).  Unfortuantely, I didn't find out a way out of 
this mind-looping considerations so far. 

> I guess I'll review the rest of the py-collect branch sometime soon...

Here are a few particularly interesting areas: 

- there is a file called "py/documentation/releasescheme.txt" which 
  describes the planned approach towards releasing the py lib.  I'd 
  like PyPy to follow the same conventions so it makes double sense 
  if you take a critical look.  

- regarding reducing import mess: py.test now uses
  py.path.local().pyimport() with a previously discussed algorithm 
  of constructing a package name and consulting the root package's 
  __package__.importfrompath() to get to a canonical module import. 

  I am thinking of somehow keeping getpymodule()'s functionality of 
  loading c-modules on the fly but otherwise completly deleting 
  all stuff related to custom import hooks. This derides us of 
  having "direct remote imports" but i think that's kind of a hopeless 
  mess and somewhat unreal anyway (we can move the custom import hook 
  hacks to some private directory to be able to reinstate it more easily 
  if need be). 

  In effect, for execnet we probably want to settle on an (efficient)
  filetransfer protocol but otherwise just do local imports. 
  Are we going to cry tears not having our own custom import 
  hook anymore?  I don't think so. 

- Collectors are Items are Collectors: they merged quite a bit 
  and have uniform signatures as seen from the (previously named 'Driver') 
  Session.  The following properties are true for any collector or item 
  (usually named 'colitem' in the code): 

    assert hasattr(colitem, 'name') 
    assert colitem.parent is None or isinstance(colitem.parent, Collector) 
    res = colitem.run() 
    assert isiterable(res) or res is None 
        # if res is iterable the session recurses into it 
    if isiterable(res): 
        for x in res: 
            assert isinstance(x, CollectorOrItem) 
   
    # a colitem can be reconstructed from a root collector and a
    # list of names 
    colitems = colitem.listchain() 
    current = colitems.pop(0) 
    while colitems: 
        current = current.join(colitems.pop(0).name) 
    assert current == colitem 

  To see a concrete tree of collectors/items, you can issue:: 

        py.test --collectonly 

  which shows more output than on the current trunk. 

ok, that should be enough for starters :-) 

The idea is that after the merge of the branch i soon want 
to cut a py-0.8.0 release and beta-test the release process. 
Guaruantees regarding APIs will only become effective after 
a py-1.0.0 which i want to have before EuroPython. 

cheers, 

    holger