[py-dev] funcarg name clash / conftest load behaviour

[holger krekel]

On Fri, Jun 25, 2010 at 13:05 +0200, Frank Hempel wrote:
> Am 25.06.2010 12:05, schrieb holger krekel:
> > 
> > I understand the confusion but indeed, i really meant 
> > 
> >     py.test b/test_hello.py 
> > 
> > will cause a collection of the ROOTDIR (containing 'b' and 'a'). 
> > py.test always collects from the root now matter how you call it. 
> 
> This backs with my expectations. This means for our play-case: No matter
> whether I execute
> ~/ROOTDIR$ py.test
> or
> ~/ROOTDIR$ py.test b/test_hello.py
> it always inspects 'a' and 'b'. That's ok.
> 
> But my concern is not about how i call it (from ROOTDIR) but _from_
> _where_ i call it.

It is basically equivalent if you have a CWD of 'b' and call "py.test" 
or if you are one dir up and call "py.test b".  This is what i meant with
"no matter how you call it". 

> Because when i enter the 'b' directory and doing
> ~/ROOTDIR/b$ py.test
> it will still examine ~/ROOTDIR/a. By the way ROOTDIR does not contain a
> __init__.py in this example, what at first I guessed would be the cause
> to let py.test take all neighbor directories into account. What i found
> out is, that py.test walks up one directory from where it was started
> and then examines the directories found regardless whether if found
> __init__.py on that upper level or not. Only the walking up stops when
> there is no __init__.py found, but the last walk-up step (or the first
> step where no __init__.py was found) is still used for collecting.

Yes, it's true and documented here (only indirectly though):

    http://codespeak.net/py/dist/test/customize.html#id22

> Another example:
> 
> ~/ROOTDIR/
>     a/
>         __init__.py
>         c/
>             test_hello.py
>     b/
>         conftest.py
> 
> and I change dir to ~/ROOTDIR/a/c and call py.test from there. Then it
> walks from 'c' up to 'a', looking for a __init__.py. Because it found
> one then it walks up to ROOTDIR, does not find __init__.py there, but
> nevertheless takes 'b' into consideration. If we remove a/__init__.py
> and call py.test from ~ROOTDIR/a/c again then it only walks from 'c' up
> to 'a', does not find __init__.py and stops walking up.

Yes, what you are seeing is the algorithm behind finding the ROOTDIR. 

> So the point what makes me surprise is, that the collection process
> takes directories from an upper dir-level into account even when there
> was no __init__.py found on that level.

It internally needs to perform a collection on the ROOTDIR 
in order to "select" 'a'.  In fact, the reason behind all this is that
py.test tries to construct a *canonical* collection tree up to the command
line specified argument and this three starts from the ROOTDIR / root node 
which is indeed determined as the last non-init-containing directory. 

> I hope I could make my concern clearer now.

I think so - your analysis is right - i guess i didn't succeed yet in
explaining the logic/reasoning behind the current behaviour, hope it's
clearer now. 

best,
holger