From holger at merlinux.eu  Tue Sep  2 10:25:47 2014
From: holger at merlinux.eu (holger krekel)
Date: Tue, 2 Sep 2014 08:25:47 +0000
Subject: [pytest-dev] latest pytest and pytest-xdist
In-Reply-To: <CACTnz+E2yaysRXqrhiUB9LbGiUnMb8MS1bTk5D50Tey3JobOYw@mail.gmail.com>
References: <CACTnz+E2yaysRXqrhiUB9LbGiUnMb8MS1bTk5D50Tey3JobOYw@mail.gmail.com>
Message-ID: <20140902082547.GU28217@merlinux.eu>

Hi Anatoly,

On Fri, Aug 22, 2014 at 15:03 +0200, Anatoly Bubenkov wrote:
> Hi
> 
> anybody knows about the source of such message after test run:
> 
> Unhandled exception in thread started by <bound method
> WorkerPool._perform_spawn of <execnet.gateway_base.WorkerPool object at
> 0xf8dbe10>>

It's a notorious issue during interpreter shutdown and has haunted
execnet for a long time.  Basically some thread is still operating
while the interpreter objects (like sys.stdout etc.) are half torn
down already.  It's really hard to prevent Python from emitting
the above exceptions, got a bit better with Python3 versions i think.

best,
holger

From bubenkoff at gmail.com  Tue Sep  2 10:29:10 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Tue, 2 Sep 2014 10:29:10 +0200
Subject: [pytest-dev] latest pytest and pytest-xdist
In-Reply-To: <20140902082547.GU28217@merlinux.eu>
References: <CACTnz+E2yaysRXqrhiUB9LbGiUnMb8MS1bTk5D50Tey3JobOYw@mail.gmail.com>
 <20140902082547.GU28217@merlinux.eu>
Message-ID: <CACTnz+HXu1n46nELk5-vLU46tmh-aD7UVU0Fau9B4hST_K9xkA@mail.gmail.com>

cool, thanks for the explanation!

On 02/09/2014, holger krekel <holger at merlinux.eu> wrote:
> Hi Anatoly,
>
> On Fri, Aug 22, 2014 at 15:03 +0200, Anatoly Bubenkov wrote:
>> Hi
>>
>> anybody knows about the source of such message after test run:
>>
>> Unhandled exception in thread started by <bound method
>> WorkerPool._perform_spawn of <execnet.gateway_base.WorkerPool object at
>> 0xf8dbe10>>
>
> It's a notorious issue during interpreter shutdown and has haunted
> execnet for a long time.  Basically some thread is still operating
> while the interpreter objects (like sys.stdout etc.) are half torn
> down already.  It's really hard to prevent Python from emitting
> the above exceptions, got a bit better with Python3 versions i think.
>
> best,
> holger
>


-- 
Anatoly Bubenkov

From nicoddemus at gmail.com  Tue Sep  2 17:58:39 2014
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 2 Sep 2014 12:58:39 -0300
Subject: [pytest-dev] [TIP] pytest: Setup/TearDown with fixtures
In-Reply-To: <CAOMwXhMkJqjMbuekZcpeWBF0xczUAnhCjNoGymUn93H1-teUMw@mail.gmail.com>
References: <CAOMwXhMkJqjMbuekZcpeWBF0xczUAnhCjNoGymUn93H1-teUMw@mail.gmail.com>
Message-ID: <CA+RQFffoR8EbHJDyAi1MOuktmF9QhBzC6a4ZusWsVU-JFpe6yw@mail.gmail.com>

On Tue, Sep 2, 2014 at 10:14 AM, Laszlo Papp <lpapp at kde.org> wrote:

> n


Hi Laszlo,

People at work have asked me the same question, and for people just getting
their feet wet is usually better to introduce pytest features as close to
what they're accustomed to as possible, so their learning curve can be
smoother.

Everyone, in your opinion, what would be a good example that uses pytest
fixtures but doesn't diverge too much what someone might be used to
`XUnit`? I like Laszlo example, but I would change it to not use a
class-scoped fixture and perhaps use `yield_fixture` to show off how easy
it is to write tear-down code.

So this `XUnit` setup code:

```python
class Test(TestCase):

    def setUp(self):
        self.user = User('test-user', 'password')
        self.user.register()
        self.session = Session()
        self.session.login(self.user)

    def tearDown(self):
        self.session.logout()
        self.user.unregister()

    def test_current_user(self):
        self.assertEqual(self.session.get_current_user().name,
self.user.name)
```

Can be almost directly translated to use py.test fixtures like this:

```python
@pytest.yield_fixture
def fixture():
    class Fixture: pass
    f = Fixture()
    f.user = User('test-user', 'password')
    f.user.register()
    f.session = Session()
    f.session.login(self.user)
    yield f
    f.session.logout()
    f.user.unregister()


class Test(object):

    def test_current_user(fixture):
        assert fixture.session.get_current_user().name == fixture.user.name
```

Which can then be further improved to show off how fixtures can reuse other
fixtures:

```python
@pytest.yield_fixture
def logged_session(user):
    session = Session()
    session.login(self.user)
    yield session
    session.session.logout()


@pytest.yield_fixture
def user():
    user = User('test-user', 'password')
    user.register()
    yield user
    user.unregister()

class Test(object):

    def test_current_user(session, user):
        assert session.get_current_user().name == user.name
```

The idea here is to allow the user to map what he already knows, and
gradually introduce fixtures as a concept to make it easier to reuse
setup/tear down code in a more modular fashion.
And furthermore the example can be improved by for example parameterizing
the `user` fixture with the original `"test-user"` and another
`"anonymous"` user without password, producing new tests automatically.

Any thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140902/356a851c/attachment.html>

From bubenkoff at gmail.com  Tue Sep  2 22:41:15 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Tue, 2 Sep 2014 22:41:15 +0200
Subject: [pytest-dev] [TIP] pytest: Setup/TearDown with fixtures
In-Reply-To: <CA+RQFffoR8EbHJDyAi1MOuktmF9QhBzC6a4ZusWsVU-JFpe6yw@mail.gmail.com>
References: <CAOMwXhMkJqjMbuekZcpeWBF0xczUAnhCjNoGymUn93H1-teUMw@mail.gmail.com>
 <CA+RQFffoR8EbHJDyAi1MOuktmF9QhBzC6a4ZusWsVU-JFpe6yw@mail.gmail.com>
Message-ID: <CACTnz+EteMMgdzqZO7CDnd_OOaP+9155CeEh=h16jeczG0BnEg@mail.gmail.com>

in the 'better' example, i would remove usage of the class


On 2 September 2014 17:58, Bruno Oliveira <nicoddemus at gmail.com> wrote:

>
> On Tue, Sep 2, 2014 at 10:14 AM, Laszlo Papp <lpapp at kde.org> wrote:
>
>> n
>
>
> Hi Laszlo,
>
> People at work have asked me the same question, and for people just
> getting their feet wet is usually better to introduce pytest features as
> close to what they're accustomed to as possible, so their learning curve
> can be smoother.
>
> Everyone, in your opinion, what would be a good example that uses pytest
> fixtures but doesn't diverge too much what someone might be used to
> `XUnit`? I like Laszlo example, but I would change it to not use a
> class-scoped fixture and perhaps use `yield_fixture` to show off how easy
> it is to write tear-down code.
>
> So this `XUnit` setup code:
>
> ```python
> class Test(TestCase):
>
>     def setUp(self):
>         self.user = User('test-user', 'password')
>         self.user.register()
>         self.session = Session()
>         self.session.login(self.user)
>
>     def tearDown(self):
>         self.session.logout()
>         self.user.unregister()
>
>     def test_current_user(self):
>         self.assertEqual(self.session.get_current_user().name,
> self.user.name)
> ```
>
> Can be almost directly translated to use py.test fixtures like this:
>
> ```python
> @pytest.yield_fixture
> def fixture():
>     class Fixture: pass
>     f = Fixture()
>     f.user = User('test-user', 'password')
>     f.user.register()
>     f.session = Session()
>     f.session.login(self.user)
>     yield f
>     f.session.logout()
>     f.user.unregister()
>
>
> class Test(object):
>
>     def test_current_user(fixture):
>         assert fixture.session.get_current_user().name ==
> fixture.user.name
> ```
>
> Which can then be further improved to show off how fixtures can reuse
> other fixtures:
>
> ```python
> @pytest.yield_fixture
> def logged_session(user):
>     session = Session()
>     session.login(self.user)
>     yield session
>     session.session.logout()
>
>
> @pytest.yield_fixture
> def user():
>     user = User('test-user', 'password')
>     user.register()
>     yield user
>     user.unregister()
>
> class Test(object):
>
>     def test_current_user(session, user):
>         assert session.get_current_user().name == user.name
> ```
>
> The idea here is to allow the user to map what he already knows, and
> gradually introduce fixtures as a concept to make it easier to reuse
> setup/tear down code in a more modular fashion.
> And furthermore the example can be improved by for example parameterizing
> the `user` fixture with the original `"test-user"` and another
> `"anonymous"` user without password, producing new tests automatically.
>
> Any thoughts?
>
>
>
> _______________________________________________
> Pytest-dev mailing list
> Pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>


-- 
Anatoly Bubenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140902/eb3151d4/attachment.html>

From flub at devork.be  Wed Sep  3 22:22:40 2014
From: flub at devork.be (Floris Bruynooghe)
Date: Wed, 3 Sep 2014 21:22:40 +0100
Subject: [pytest-dev] Jython support
Message-ID: <CAAWk_DwVVxDcRW3z2MODt+8Y3M3zg1v8724YCKyUi-C89p=RLA@mail.gmail.com>

Hi all,

Do we support jython at all currently?  AFAIK the released jython is
only 2.5 while py.test no longer supports 2.5.  Of course this could
change when the new jython gets released in the following months.

The reason I ask is because testing/conftest.py contains an
"anypython" fixture which is parametrised for py25-33, pypy and
jython.  I think this should probably be 26, 27, 32, 33, 34, pypy, and
pypy3 now, so if that sounds right I could do a PR for that.

Regards,
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From holger at merlinux.eu  Thu Sep  4 08:25:25 2014
From: holger at merlinux.eu (holger krekel)
Date: Thu, 4 Sep 2014 06:25:25 +0000
Subject: [pytest-dev] Jython support
In-Reply-To: <CAAWk_DwVVxDcRW3z2MODt+8Y3M3zg1v8724YCKyUi-C89p=RLA@mail.gmail.com>
References: <CAAWk_DwVVxDcRW3z2MODt+8Y3M3zg1v8724YCKyUi-C89p=RLA@mail.gmail.com>
Message-ID: <20140904062525.GW28217@merlinux.eu>

Hi Floris,

On Wed, Sep 03, 2014 at 21:22 +0100, Floris Bruynooghe wrote:
> Hi all,
> 
> Do we support jython at all currently?  AFAIK the released jython is
> only 2.5 while py.test no longer supports 2.5.  Of course this could
> change when the new jython gets released in the following months.
> 
> The reason I ask is because testing/conftest.py contains an
> "anypython" fixture which is parametrised for py25-33, pypy and
> jython.  I think this should probably be 26, 27, 32, 33, 34, pypy, and
> pypy3 now, so if that sounds right I could do a PR for that.

I don't know and haven't tested myself pytest with Jython for a long
time.  There are some Jython 2.7 RC candidates out and i guess it would make
sense to try to run against and only support them.  I am sure that Jim 
and Frank (two core Jython core devs) would help if there is anything
that needs fixing.  However, someone needs to run and test things and
report issues here or/on the Jython trackers.

best,
holger

  
> Regards,
> Floris
> 
> -- 
> Debian GNU/Linux -- The Power of Freedom
> www.debian.org | www.gnu.org | www.kernel.org
> _______________________________________________
> Pytest-dev mailing list
> Pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
> 

From g.s.srinath89 at gmail.com  Thu Sep  4 08:45:59 2014
From: g.s.srinath89 at gmail.com (Srinath)
Date: Thu, 4 Sep 2014 12:15:59 +0530
Subject: [pytest-dev] pytest.internal test failures
Message-ID: <CADe_7JmyHwx5_XMqcvkx5-vzYf9h2UTC40o6F0zrZTdjvphxWA@mail.gmail.com>

Hi list,


*23:01:51* Traceback (most recent call last):*23:01:51*   File
"<string>", line 1, in <module>*23:01:51*   File "<string>", line 6,
in <module>*23:01:51*   File
"/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py",
line 1215, in serve*23:01:51*     SlaveGateway(io=io, id=id,
_startcount=2).serve()*23:01:51*   File
"/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py",
line 777, in serve*23:01:51*     self.join()*23:01:51*   File
"/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py",
line 735, in join*23:01:51*
self._receiverthread.join(timeout)*23:01:51*   File
"/usr/lib/python2.7/threading.py", line 668, in join*23:01:51*
self.__block.wait()*23:01:51*   File
"/usr/lib/python2.7/threading.py", line 244, in wait*23:01:51*
waiter.acquire()*23:01:51*   File "_semaphore.pyx", line 112, in
gevent._semaphore.Semaphore.acquire
(gevent/gevent._semaphore.c:3004)*23:01:51*   File
"/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/gevent/hub.py",
line 331, in switch*23:01:51*     return
greenlet.switch(self)*23:01:51* gevent.hub.LoopExit: This operation
would block forever


We keep getting this error in our CI system which raises
`pytest.internal` error. Can anyone suggest a way to solve this?


pytest version:

pytest==2.5.2
pytest-cache==0.9
pytest-capturelog==0.7
pytest-cov==1.6
pytest-figleaf==1.0
pytest-growl==0.1
pytest-pep8==1.0.4
pytest-xdist==1.8

execnet==1.1


Please help.


Also, can anyone tell which version of pytest works well with
execnet1.2? This is the version that has gevent support.


[image: Srinath GS on about.me]

Srinath GS
about.me/srinathgs
  <http://about.me/srinathgs>http://srinath.im
I write code @ Alamut
Srinath G S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140904/1bbe4b0a/attachment.html>

From bubenkoff at gmail.com  Thu Sep  4 08:57:10 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Thu, 4 Sep 2014 08:57:10 +0200
Subject: [pytest-dev] pytest.internal test failures
In-Reply-To: <CADe_7JmyHwx5_XMqcvkx5-vzYf9h2UTC40o6F0zrZTdjvphxWA@mail.gmail.com>
References: <CADe_7JmyHwx5_XMqcvkx5-vzYf9h2UTC40o6F0zrZTdjvphxWA@mail.gmail.com>
Message-ID: <CACTnz+Fm=YDdT898+edqG-U-GoMmyBFAOu2S9THeDw2g00XFnA@mail.gmail.com>

we use all 4 at latest versions: pytest, pytest-xdist, execnet, py and it
works
my suggestion is to try not using greenlets and instead use default -
threading


On 4 September 2014 08:45, Srinath <g.s.srinath89 at gmail.com> wrote:

> Hi list,
>
>
> *23:01:51* Traceback (most recent call last):*23:01:51*   File "<string>", line 1, in <module>*23:01:51*   File "<string>", line 6, in <module>*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 1215, in serve*23:01:51*     SlaveGateway(io=io, id=id, _startcount=2).serve()*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 777, in serve*23:01:51*     self.join()*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 735, in join*23:01:51*     self._receiverthread.join(timeout)*23:01:51*   File "/usr/lib/python2.7/threading.py", line 668, in join*23:01:51*     self.__block.wait()*23:01:51*   File "/usr/lib/python2.7/threading.py", line 244, in wait*23:01:51*     waiter.acquire()*23:01:51*   File "_semaphore.pyx", line 112, in gevent._semaphore.Semaphore.acquire (gevent/gevent._semaphore.c:3004)*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/gevent/hub.py", line 331, in switch*23:01:51*     return greenlet.switch(self)*23:01:51* gevent.hub.LoopExit: This operation would block forever
>
>
> We keep getting this error in our CI system which raises `pytest.internal` error. Can anyone suggest a way to solve this?
>
>
> pytest version:
>
> pytest==2.5.2
> pytest-cache==0.9
> pytest-capturelog==0.7
> pytest-cov==1.6
> pytest-figleaf==1.0
> pytest-growl==0.1
> pytest-pep8==1.0.4
> pytest-xdist==1.8
>
> execnet==1.1
>
>
> Please help.
>
>
> Also, can anyone tell which version of pytest works well with execnet1.2? This is the version that has gevent support.
>
>
> [image: Srinath GS on about.me]
>
> Srinath GS
> about.me/srinathgs
>   <http://about.me/srinathgs>http://srinath.im
> I write code @ Alamut
> Srinath G S
>
> _______________________________________________
> Pytest-dev mailing list
> Pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>


-- 
Anatoly Bubenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140904/caa955f1/attachment-0001.html>

From g.s.srinath89 at gmail.com  Thu Sep  4 09:10:00 2014
From: g.s.srinath89 at gmail.com (Srinath)
Date: Thu, 4 Sep 2014 12:40:00 +0530
Subject: [pytest-dev] pytest.internal test failures
In-Reply-To: <CACTnz+Fm=YDdT898+edqG-U-GoMmyBFAOu2S9THeDw2g00XFnA@mail.gmail.com>
References: <CADe_7JmyHwx5_XMqcvkx5-vzYf9h2UTC40o6F0zrZTdjvphxWA@mail.gmail.com>
 <CACTnz+Fm=YDdT898+edqG-U-GoMmyBFAOu2S9THeDw2g00XFnA@mail.gmail.com>
Message-ID: <CADe_7JkUFkU+n+qh57Me-Q+c1JL7W4Umu1cm2Ore=X4O6HQwFA@mail.gmail.com>

Hi Anatoly,

We use a lot of greenlets in our code. Unit Tests import them. They get
monkey patched. So, we really can't use only threading.


[image: Srinath GS on about.me]

Srinath GS
about.me/srinathgs
  <http://about.me/srinathgs>http://srinath.im
I write code @ Alamut
Srinath G S


On Thu, Sep 4, 2014 at 12:27 PM, Anatoly Bubenkov <bubenkoff at gmail.com>
wrote:

> we use all 4 at latest versions: pytest, pytest-xdist, execnet, py and it
> works
> my suggestion is to try not using greenlets and instead use default -
> threading
>
>
> On 4 September 2014 08:45, Srinath <g.s.srinath89 at gmail.com> wrote:
>
>> Hi list,
>>
>>
>> *23:01:51* Traceback (most recent call last):*23:01:51*   File "<string>", line 1, in <module>*23:01:51*   File "<string>", line 6, in <module>*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 1215, in serve*23:01:51*     SlaveGateway(io=io, id=id, _startcount=2).serve()*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 777, in serve*23:01:51*     self.join()*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 735, in join*23:01:51*     self._receiverthread.join(timeout)*23:01:51*   File "/usr/lib/python2.7/threading.py", line 668, in join*23:01:51*     self.__block.wait()*23:01:51*   File "/usr/lib/python2.7/threading.py", line 244, in wait*23:01:51*     waiter.acquire()*23:01:51*   File "_semaphore.pyx", line 112, in gevent._semaphore.Semaphore.acquire (gevent/gevent._semaphore.c:3004)*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/gevent/hub.py", line 331, in switch*23:01:51*     return greenlet.switch(self)*23:01:51* gevent.hub.LoopExit: This operation would block forever
>>
>>
>> We keep getting this error in our CI system which raises `pytest.internal` error. Can anyone suggest a way to solve this?
>>
>>
>> pytest version:
>>
>> pytest==2.5.2
>> pytest-cache==0.9
>> pytest-capturelog==0.7
>> pytest-cov==1.6
>> pytest-figleaf==1.0
>> pytest-growl==0.1
>> pytest-pep8==1.0.4
>> pytest-xdist==1.8
>>
>> execnet==1.1
>>
>>
>> Please help.
>>
>>
>> Also, can anyone tell which version of pytest works well with execnet1.2? This is the version that has gevent support.
>>
>>
>> [image: Srinath GS on about.me]
>>
>> Srinath GS
>> about.me/srinathgs
>>   <http://about.me/srinathgs>http://srinath.im
>> I write code @ Alamut
>> Srinath G S
>>
>> _______________________________________________
>> Pytest-dev mailing list
>> Pytest-dev at python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>
>>
>
>
> --
> Anatoly Bubenkov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140904/6bba8423/attachment.html>

From bubenkoff at gmail.com  Thu Sep  4 09:22:06 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Thu, 4 Sep 2014 09:22:06 +0200
Subject: [pytest-dev] pytest.internal test failures
In-Reply-To: <CADe_7JkUFkU+n+qh57Me-Q+c1JL7W4Umu1cm2Ore=X4O6HQwFA@mail.gmail.com>
References: <CADe_7JmyHwx5_XMqcvkx5-vzYf9h2UTC40o6F0zrZTdjvphxWA@mail.gmail.com>
 <CACTnz+Fm=YDdT898+edqG-U-GoMmyBFAOu2S9THeDw2g00XFnA@mail.gmail.com>
 <CADe_7JkUFkU+n+qh57Me-Q+c1JL7W4Umu1cm2Ore=X4O6HQwFA@mail.gmail.com>
Message-ID: <CACTnz+E=fVftnKneWwYi6sGQnGB5A502SCkahP372n_SN65UWQ@mail.gmail.com>

I mean the mode of the execnet, do you use threads there?


On 4 September 2014 09:10, Srinath <g.s.srinath89 at gmail.com> wrote:

> Hi Anatoly,
>
> We use a lot of greenlets in our code. Unit Tests import them. They get
> monkey patched. So, we really can't use only threading.
>
>
> [image: Srinath GS on about.me]
>
> Srinath GS
> about.me/srinathgs
>   <http://about.me/srinathgs>http://srinath.im
> I write code @ Alamut
> Srinath G S
>
>
> On Thu, Sep 4, 2014 at 12:27 PM, Anatoly Bubenkov <bubenkoff at gmail.com>
> wrote:
>
>> we use all 4 at latest versions: pytest, pytest-xdist, execnet, py and it
>> works
>> my suggestion is to try not using greenlets and instead use default -
>> threading
>>
>>
>> On 4 September 2014 08:45, Srinath <g.s.srinath89 at gmail.com> wrote:
>>
>>> Hi list,
>>>
>>>
>>> *23:01:51* Traceback (most recent call last):*23:01:51*   File "<string>", line 1, in <module>*23:01:51*   File "<string>", line 6, in <module>*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 1215, in serve*23:01:51*     SlaveGateway(io=io, id=id, _startcount=2).serve()*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 777, in serve*23:01:51*     self.join()*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 735, in join*23:01:51*     self._receiverthread.join(timeout)*23:01:51*   File "/usr/lib/python2.7/threading.py", line 668, in join*23:01:51*     self.__block.wait()*23:01:51*   File "/usr/lib/python2.7/threading.py", line 244, in wait*23:01:51*     waiter.acquire()*23:01:51*   File "_semaphore.pyx", line 112, in gevent._semaphore.Semaphore.acquire (gevent/gevent._semaphore.c:3004)*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/gevent/hub.py", line 331, in switch*23:01:51*     return greenlet.switch(self)*23:01:51* gevent.hub.LoopExit: This operation would block forever
>>>
>>>
>>> We keep getting this error in our CI system which raises `pytest.internal` error. Can anyone suggest a way to solve this?
>>>
>>>
>>> pytest version:
>>>
>>> pytest==2.5.2
>>> pytest-cache==0.9
>>> pytest-capturelog==0.7
>>> pytest-cov==1.6
>>> pytest-figleaf==1.0
>>> pytest-growl==0.1
>>> pytest-pep8==1.0.4
>>> pytest-xdist==1.8
>>>
>>> execnet==1.1
>>>
>>>
>>> Please help.
>>>
>>>
>>> Also, can anyone tell which version of pytest works well with execnet1.2? This is the version that has gevent support.
>>>
>>>
>>> [image: Srinath GS on about.me]
>>>
>>> Srinath GS
>>> about.me/srinathgs
>>>   <http://about.me/srinathgs>http://srinath.im
>>> I write code @ Alamut
>>> Srinath G S
>>>
>>> _______________________________________________
>>> Pytest-dev mailing list
>>> Pytest-dev at python.org
>>> https://mail.python.org/mailman/listinfo/pytest-dev
>>>
>>>
>>
>>
>> --
>> Anatoly Bubenkov
>>
>
>


-- 
Anatoly Bubenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140904/a9d2e358/attachment-0001.html>

From g.s.srinath89 at gmail.com  Thu Sep  4 10:02:21 2014
From: g.s.srinath89 at gmail.com (Srinath)
Date: Thu, 4 Sep 2014 13:32:21 +0530
Subject: [pytest-dev] pytest.internal test failures
In-Reply-To: <CACTnz+E=fVftnKneWwYi6sGQnGB5A502SCkahP372n_SN65UWQ@mail.gmail.com>
References: <CADe_7JmyHwx5_XMqcvkx5-vzYf9h2UTC40o6F0zrZTdjvphxWA@mail.gmail.com>
 <CACTnz+Fm=YDdT898+edqG-U-GoMmyBFAOu2S9THeDw2g00XFnA@mail.gmail.com>
 <CADe_7JkUFkU+n+qh57Me-Q+c1JL7W4Umu1cm2Ore=X4O6HQwFA@mail.gmail.com>
 <CACTnz+E=fVftnKneWwYi6sGQnGB5A502SCkahP372n_SN65UWQ@mail.gmail.com>
Message-ID: <CADe_7JmzE4ciZMwGSPxp06pZ1KYZv3TACqVMfa8M63BoDP7gUg@mail.gmail.com>

We just run py.test -n <int>. pytest automatically picks up the tests and
then run. some of the unit tests import code from components. Components do
gevent monkey patch. so, execnet although uses threading, the locking stuff
gets overridden by gevent. Hope this clarifies the use case.


[image: Srinath GS on about.me]

Srinath GS
about.me/srinathgs
  <http://about.me/srinathgs>http://srinath.im
I write code @ Alamut
Srinath G S


On Thu, Sep 4, 2014 at 12:52 PM, Anatoly Bubenkov <bubenkoff at gmail.com>
wrote:

> I mean the mode of the execnet, do you use threads there?
>
>
> On 4 September 2014 09:10, Srinath <g.s.srinath89 at gmail.com> wrote:
>
>> Hi Anatoly,
>>
>> We use a lot of greenlets in our code. Unit Tests import them. They get
>> monkey patched. So, we really can't use only threading.
>>
>>
>> [image: Srinath GS on about.me]
>>
>> Srinath GS
>> about.me/srinathgs
>>   <http://about.me/srinathgs>http://srinath.im
>> I write code @ Alamut
>> Srinath G S
>>
>>
>> On Thu, Sep 4, 2014 at 12:27 PM, Anatoly Bubenkov <bubenkoff at gmail.com>
>> wrote:
>>
>>> we use all 4 at latest versions: pytest, pytest-xdist, execnet, py and
>>> it works
>>> my suggestion is to try not using greenlets and instead use default -
>>> threading
>>>
>>>
>>> On 4 September 2014 08:45, Srinath <g.s.srinath89 at gmail.com> wrote:
>>>
>>>>  Hi list,
>>>>
>>>>
>>>> *23:01:51* Traceback (most recent call last):*23:01:51*   File "<string>", line 1, in <module>*23:01:51*   File "<string>", line 6, in <module>*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 1215, in serve*23:01:51*     SlaveGateway(io=io, id=id, _startcount=2).serve()*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 777, in serve*23:01:51*     self.join()*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 735, in join*23:01:51*     self._receiverthread.join(timeout)*23:01:51*   File "/usr/lib/python2.7/threading.py", line 668, in join*23:01:51*     self.__block.wait()*23:01:51*   File "/usr/lib/python2.7/threading.py", line 244, in wait*23:01:51*     waiter.acquire()*23:01:51*   File "_semaphore.pyx", line 112, in gevent._semaphore.Semaphore.acquire (gevent/gevent._semaphore.c:3004)*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/gevent/hub.py", line 331, in switch*23:01:51*     return greenlet.switch(self)*23:01:51* gevent.hub.LoopExit: This operation would block forever
>>>>
>>>>
>>>> We keep getting this error in our CI system which raises `pytest.internal` error. Can anyone suggest a way to solve this?
>>>>
>>>>
>>>> pytest version:
>>>>
>>>> pytest==2.5.2
>>>> pytest-cache==0.9
>>>> pytest-capturelog==0.7
>>>> pytest-cov==1.6
>>>> pytest-figleaf==1.0
>>>> pytest-growl==0.1
>>>> pytest-pep8==1.0.4
>>>> pytest-xdist==1.8
>>>>
>>>> execnet==1.1
>>>>
>>>>
>>>> Please help.
>>>>
>>>>
>>>> Also, can anyone tell which version of pytest works well with execnet1.2? This is the version that has gevent support.
>>>>
>>>>
>>>> [image: Srinath GS on about.me]
>>>>
>>>> Srinath GS
>>>> about.me/srinathgs
>>>>   <http://about.me/srinathgs>http://srinath.im
>>>> I write code @ Alamut
>>>> Srinath G S
>>>>
>>>> _______________________________________________
>>>> Pytest-dev mailing list
>>>> Pytest-dev at python.org
>>>> https://mail.python.org/mailman/listinfo/pytest-dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Anatoly Bubenkov
>>>
>>
>>
>
>
> --
> Anatoly Bubenkov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140904/7437fd4f/attachment.html>

From bubenkoff at gmail.com  Thu Sep  4 10:04:59 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Thu, 4 Sep 2014 10:04:59 +0200
Subject: [pytest-dev] pytest.internal test failures
In-Reply-To: <CADe_7JmzE4ciZMwGSPxp06pZ1KYZv3TACqVMfa8M63BoDP7gUg@mail.gmail.com>
References: <CADe_7JmyHwx5_XMqcvkx5-vzYf9h2UTC40o6F0zrZTdjvphxWA@mail.gmail.com>
 <CACTnz+Fm=YDdT898+edqG-U-GoMmyBFAOu2S9THeDw2g00XFnA@mail.gmail.com>
 <CADe_7JkUFkU+n+qh57Me-Q+c1JL7W4Umu1cm2Ore=X4O6HQwFA@mail.gmail.com>
 <CACTnz+E=fVftnKneWwYi6sGQnGB5A502SCkahP372n_SN65UWQ@mail.gmail.com>
 <CADe_7JmzE4ciZMwGSPxp06pZ1KYZv3TACqVMfa8M63BoDP7gUg@mail.gmail.com>
Message-ID: <CACTnz+Gu+emDVuaX8am1+wXDG2bS+JV77aryifSt809uTnmZTA@mail.gmail.com>

so that might very well be the issue - gevent does the patching of the
threading module which is in use of the execnet...
try to NOT use gevent patching but just use it directly (by importing and
using it's attributes), eg avoild .patch_all


On 4 September 2014 10:02, Srinath <g.s.srinath89 at gmail.com> wrote:

> We just run py.test -n <int>. pytest automatically picks up the tests and
> then run. some of the unit tests import code from components. Components do
> gevent monkey patch. so, execnet although uses threading, the locking stuff
> gets overridden by gevent. Hope this clarifies the use case.
>
>
> [image: Srinath GS on about.me]
>
> Srinath GS
> about.me/srinathgs
>   <http://about.me/srinathgs>http://srinath.im
> I write code @ Alamut
> Srinath G S
>
>
> On Thu, Sep 4, 2014 at 12:52 PM, Anatoly Bubenkov <bubenkoff at gmail.com>
> wrote:
>
>> I mean the mode of the execnet, do you use threads there?
>>
>>
>> On 4 September 2014 09:10, Srinath <g.s.srinath89 at gmail.com> wrote:
>>
>>> Hi Anatoly,
>>>
>>> We use a lot of greenlets in our code. Unit Tests import them. They get
>>> monkey patched. So, we really can't use only threading.
>>>
>>>
>>> [image: Srinath GS on about.me]
>>>
>>> Srinath GS
>>> about.me/srinathgs
>>>   <http://about.me/srinathgs>http://srinath.im
>>> I write code @ Alamut
>>> Srinath G S
>>>
>>>
>>> On Thu, Sep 4, 2014 at 12:27 PM, Anatoly Bubenkov <bubenkoff at gmail.com>
>>> wrote:
>>>
>>>> we use all 4 at latest versions: pytest, pytest-xdist, execnet, py and
>>>> it works
>>>> my suggestion is to try not using greenlets and instead use default -
>>>> threading
>>>>
>>>>
>>>> On 4 September 2014 08:45, Srinath <g.s.srinath89 at gmail.com> wrote:
>>>>
>>>>>  Hi list,
>>>>>
>>>>>
>>>>> *23:01:51* Traceback (most recent call last):*23:01:51*   File "<string>", line 1, in <module>*23:01:51*   File "<string>", line 6, in <module>*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 1215, in serve*23:01:51*     SlaveGateway(io=io, id=id, _startcount=2).serve()*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 777, in serve*23:01:51*     self.join()*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 735, in join*23:01:51*     self._receiverthread.join(timeout)*23:01:51*   File "/usr/lib/python2.7/threading.py", line 668, in join*23:01:51*     self.__block.wait()*23:01:51*   File "/usr/lib/python2.7/threading.py", line 244, in wait*23:01:51*     waiter.acquire()*23:01:51*   File "_semaphore.pyx", line 112, in gevent._semaphore.Semaphore.acquire (gevent/gevent._semaphore.c:3004)*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/gevent/hub.py", line 331, in switch*23:01:51*     return greenlet.switch(self)*23:01:51* gevent.hub.LoopExit: This operation would block forever
>>>>>
>>>>>
>>>>> We keep getting this error in our CI system which raises `pytest.internal` error. Can anyone suggest a way to solve this?
>>>>>
>>>>>
>>>>> pytest version:
>>>>>
>>>>> pytest==2.5.2
>>>>> pytest-cache==0.9
>>>>> pytest-capturelog==0.7
>>>>> pytest-cov==1.6
>>>>> pytest-figleaf==1.0
>>>>> pytest-growl==0.1
>>>>> pytest-pep8==1.0.4
>>>>> pytest-xdist==1.8
>>>>>
>>>>> execnet==1.1
>>>>>
>>>>>
>>>>> Please help.
>>>>>
>>>>>
>>>>> Also, can anyone tell which version of pytest works well with execnet1.2? This is the version that has gevent support.
>>>>>
>>>>>
>>>>> [image: Srinath GS on about.me]
>>>>>
>>>>> Srinath GS
>>>>> about.me/srinathgs
>>>>>   <http://about.me/srinathgs>http://srinath.im
>>>>> I write code @ Alamut
>>>>> Srinath G S
>>>>>
>>>>> _______________________________________________
>>>>> Pytest-dev mailing list
>>>>> Pytest-dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/pytest-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Anatoly Bubenkov
>>>>
>>>
>>>
>>
>>
>> --
>> Anatoly Bubenkov
>>
>
>


-- 
Anatoly Bubenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140904/92b0e28b/attachment-0001.html>

From g.s.srinath89 at gmail.com  Thu Sep  4 10:10:02 2014
From: g.s.srinath89 at gmail.com (Srinath)
Date: Thu, 4 Sep 2014 13:40:02 +0530
Subject: [pytest-dev] pytest.internal test failures
In-Reply-To: <CACTnz+Gu+emDVuaX8am1+wXDG2bS+JV77aryifSt809uTnmZTA@mail.gmail.com>
References: <CADe_7JmyHwx5_XMqcvkx5-vzYf9h2UTC40o6F0zrZTdjvphxWA@mail.gmail.com>
 <CACTnz+Fm=YDdT898+edqG-U-GoMmyBFAOu2S9THeDw2g00XFnA@mail.gmail.com>
 <CADe_7JkUFkU+n+qh57Me-Q+c1JL7W4Umu1cm2Ore=X4O6HQwFA@mail.gmail.com>
 <CACTnz+E=fVftnKneWwYi6sGQnGB5A502SCkahP372n_SN65UWQ@mail.gmail.com>
 <CADe_7JmzE4ciZMwGSPxp06pZ1KYZv3TACqVMfa8M63BoDP7gUg@mail.gmail.com>
 <CACTnz+Gu+emDVuaX8am1+wXDG2bS+JV77aryifSt809uTnmZTA@mail.gmail.com>
Message-ID: <CADe_7J=JMVNvJgtJ4Fuy0FsiDYq_kXAhgnYKorHB40XOwCzOxw@mail.gmail.com>

which execnet version do you use? 1.1 or 1.2? with 1.2 py.test -n <int>
doesn't even run.


[image: Srinath GS on about.me]

Srinath GS
about.me/srinathgs
  <http://about.me/srinathgs>http://srinath.im
I write code @ Alamut
Srinath G S


On Thu, Sep 4, 2014 at 1:34 PM, Anatoly Bubenkov <bubenkoff at gmail.com>
wrote:

> so that might very well be the issue - gevent does the patching of the
> threading module which is in use of the execnet...
> try to NOT use gevent patching but just use it directly (by importing and
> using it's attributes), eg avoild .patch_all
>
>
> On 4 September 2014 10:02, Srinath <g.s.srinath89 at gmail.com> wrote:
>
>> We just run py.test -n <int>. pytest automatically picks up the tests and
>> then run. some of the unit tests import code from components. Components do
>> gevent monkey patch. so, execnet although uses threading, the locking stuff
>> gets overridden by gevent. Hope this clarifies the use case.
>>
>>
>> [image: Srinath GS on about.me]
>>
>> Srinath GS
>> about.me/srinathgs
>>   <http://about.me/srinathgs>http://srinath.im
>> I write code @ Alamut
>> Srinath G S
>>
>>
>> On Thu, Sep 4, 2014 at 12:52 PM, Anatoly Bubenkov <bubenkoff at gmail.com>
>> wrote:
>>
>>> I mean the mode of the execnet, do you use threads there?
>>>
>>>
>>> On 4 September 2014 09:10, Srinath <g.s.srinath89 at gmail.com> wrote:
>>>
>>>> Hi Anatoly,
>>>>
>>>> We use a lot of greenlets in our code. Unit Tests import them. They get
>>>> monkey patched. So, we really can't use only threading.
>>>>
>>>>
>>>> [image: Srinath GS on about.me]
>>>>
>>>> Srinath GS
>>>> about.me/srinathgs
>>>>   <http://about.me/srinathgs>http://srinath.im
>>>> I write code @ Alamut
>>>> Srinath G S
>>>>
>>>>
>>>> On Thu, Sep 4, 2014 at 12:27 PM, Anatoly Bubenkov <bubenkoff at gmail.com>
>>>> wrote:
>>>>
>>>>> we use all 4 at latest versions: pytest, pytest-xdist, execnet, py and
>>>>> it works
>>>>> my suggestion is to try not using greenlets and instead use default -
>>>>> threading
>>>>>
>>>>>
>>>>> On 4 September 2014 08:45, Srinath <g.s.srinath89 at gmail.com> wrote:
>>>>>
>>>>>>  Hi list,
>>>>>>
>>>>>>
>>>>>> *23:01:51* Traceback (most recent call last):*23:01:51*   File "<string>", line 1, in <module>*23:01:51*   File "<string>", line 6, in <module>*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 1215, in serve*23:01:51*     SlaveGateway(io=io, id=id, _startcount=2).serve()*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 777, in serve*23:01:51*     self.join()*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 735, in join*23:01:51*     self._receiverthread.join(timeout)*23:01:51*   File "/usr/lib/python2.7/threading.py", line 668, in join*23:01:51*     self.__block.wait()*23:01:51*   File "/usr/lib/python2.7/threading.py", line 244, in wait*23:01:51*     waiter.acquire()*23:01:51*   File "_semaphore.pyx", line 112, in gevent._semaphore.Semaphore.acquire (gevent/gevent._semaphore.c:3004)*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/gevent/hub.py", line 331, in switch*23:01:51*     return greenlet.switch(self)*23:01:51* gevent.hub.LoopExit: This operation would block forever
>>>>>>
>>>>>>
>>>>>> We keep getting this error in our CI system which raises `pytest.internal` error. Can anyone suggest a way to solve this?
>>>>>>
>>>>>>
>>>>>> pytest version:
>>>>>>
>>>>>> pytest==2.5.2
>>>>>> pytest-cache==0.9
>>>>>> pytest-capturelog==0.7
>>>>>> pytest-cov==1.6
>>>>>> pytest-figleaf==1.0
>>>>>> pytest-growl==0.1
>>>>>> pytest-pep8==1.0.4
>>>>>> pytest-xdist==1.8
>>>>>>
>>>>>> execnet==1.1
>>>>>>
>>>>>>
>>>>>> Please help.
>>>>>>
>>>>>>
>>>>>> Also, can anyone tell which version of pytest works well with execnet1.2? This is the version that has gevent support.
>>>>>>
>>>>>>
>>>>>> [image: Srinath GS on about.me]
>>>>>>
>>>>>> Srinath GS
>>>>>> about.me/srinathgs
>>>>>>   <http://about.me/srinathgs>http://srinath.im
>>>>>> I write code @ Alamut
>>>>>> Srinath G S
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pytest-dev mailing list
>>>>>> Pytest-dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/pytest-dev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Anatoly Bubenkov
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Anatoly Bubenkov
>>>
>>
>>
>
>
> --
> Anatoly Bubenkov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140904/fcce2631/attachment-0001.html>

From holger at merlinux.eu  Thu Sep  4 10:17:44 2014
From: holger at merlinux.eu (holger krekel)
Date: Thu, 4 Sep 2014 08:17:44 +0000
Subject: [pytest-dev] pytest.internal test failures
In-Reply-To: <CADe_7J=JMVNvJgtJ4Fuy0FsiDYq_kXAhgnYKorHB40XOwCzOxw@mail.gmail.com>
References: <CADe_7JmyHwx5_XMqcvkx5-vzYf9h2UTC40o6F0zrZTdjvphxWA@mail.gmail.com>
 <CACTnz+Fm=YDdT898+edqG-U-GoMmyBFAOu2S9THeDw2g00XFnA@mail.gmail.com>
 <CADe_7JkUFkU+n+qh57Me-Q+c1JL7W4Umu1cm2Ore=X4O6HQwFA@mail.gmail.com>
 <CACTnz+E=fVftnKneWwYi6sGQnGB5A502SCkahP372n_SN65UWQ@mail.gmail.com>
 <CADe_7JmzE4ciZMwGSPxp06pZ1KYZv3TACqVMfa8M63BoDP7gUg@mail.gmail.com>
 <CACTnz+Gu+emDVuaX8am1+wXDG2bS+JV77aryifSt809uTnmZTA@mail.gmail.com>
 <CADe_7J=JMVNvJgtJ4Fuy0FsiDYq_kXAhgnYKorHB40XOwCzOxw@mail.gmail.com>
Message-ID: <20140904081744.GA28217@merlinux.eu>

On Thu, Sep 04, 2014 at 13:40 +0530, Srinath wrote:
> which execnet version do you use? 1.1 or 1.2? with 1.2 py.test -n <int>
> doesn't even run.

py.test -n works fine with execnet-1.2 for me and many others
(as long as only OS threading is involved).

However, execnet-gevent/greenlet support is relatively new and
not extensively tested and might have issues also with pytest-xdist.

best,
holger

> 
> [image: Srinath GS on about.me]
> 
> Srinath GS
> about.me/srinathgs
>   <http://about.me/srinathgs>http://srinath.im
> I write code @ Alamut
> Srinath G S
> 
> 
> On Thu, Sep 4, 2014 at 1:34 PM, Anatoly Bubenkov <bubenkoff at gmail.com>
> wrote:
> 
> > so that might very well be the issue - gevent does the patching of the
> > threading module which is in use of the execnet...
> > try to NOT use gevent patching but just use it directly (by importing and
> > using it's attributes), eg avoild .patch_all
> >
> >
> > On 4 September 2014 10:02, Srinath <g.s.srinath89 at gmail.com> wrote:
> >
> >> We just run py.test -n <int>. pytest automatically picks up the tests and
> >> then run. some of the unit tests import code from components. Components do
> >> gevent monkey patch. so, execnet although uses threading, the locking stuff
> >> gets overridden by gevent. Hope this clarifies the use case.
> >>
> >>
> >> [image: Srinath GS on about.me]
> >>
> >> Srinath GS
> >> about.me/srinathgs
> >>   <http://about.me/srinathgs>http://srinath.im
> >> I write code @ Alamut
> >> Srinath G S
> >>
> >>
> >> On Thu, Sep 4, 2014 at 12:52 PM, Anatoly Bubenkov <bubenkoff at gmail.com>
> >> wrote:
> >>
> >>> I mean the mode of the execnet, do you use threads there?
> >>>
> >>>
> >>> On 4 September 2014 09:10, Srinath <g.s.srinath89 at gmail.com> wrote:
> >>>
> >>>> Hi Anatoly,
> >>>>
> >>>> We use a lot of greenlets in our code. Unit Tests import them. They get
> >>>> monkey patched. So, we really can't use only threading.
> >>>>
> >>>>
> >>>> [image: Srinath GS on about.me]
> >>>>
> >>>> Srinath GS
> >>>> about.me/srinathgs
> >>>>   <http://about.me/srinathgs>http://srinath.im
> >>>> I write code @ Alamut
> >>>> Srinath G S
> >>>>
> >>>>
> >>>> On Thu, Sep 4, 2014 at 12:27 PM, Anatoly Bubenkov <bubenkoff at gmail.com>
> >>>> wrote:
> >>>>
> >>>>> we use all 4 at latest versions: pytest, pytest-xdist, execnet, py and
> >>>>> it works
> >>>>> my suggestion is to try not using greenlets and instead use default -
> >>>>> threading
> >>>>>
> >>>>>
> >>>>> On 4 September 2014 08:45, Srinath <g.s.srinath89 at gmail.com> wrote:
> >>>>>
> >>>>>>  Hi list,
> >>>>>>
> >>>>>>
> >>>>>> *23:01:51* Traceback (most recent call last):*23:01:51*   File "<string>", line 1, in <module>*23:01:51*   File "<string>", line 6, in <module>*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 1215, in serve*23:01:51*     SlaveGateway(io=io, id=id, _startcount=2).serve()*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 777, in serve*23:01:51*     self.join()*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 735, in join*23:01:51*     self._receiverthread.join(timeout)*23:01:51*   File "/usr/lib/python2.7/threading.py", line 668, in join*23:01:51*     self.__block.wait()*23:01:51*   File "/usr/lib/python2.7/threading.py", line 244, in wait*23:01:51*     waiter.acquire()*23:01:51*   File "_semaphore.pyx", line 112, in gev
> ent._semaphore.Semaphore.acquire (gevent/gevent._semaphore.c:3004)*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/gevent/hub.py", line 331, in switch*23:01:51*     return greenlet.switch(self)*23:01:51* gevent.hub.LoopExit: This operation would block forever
> >>>>>>
> >>>>>>
> >>>>>> We keep getting this error in our CI system which raises `pytest.internal` error. Can anyone suggest a way to solve this?
> >>>>>>
> >>>>>>
> >>>>>> pytest version:
> >>>>>>
> >>>>>> pytest==2.5.2
> >>>>>> pytest-cache==0.9
> >>>>>> pytest-capturelog==0.7
> >>>>>> pytest-cov==1.6
> >>>>>> pytest-figleaf==1.0
> >>>>>> pytest-growl==0.1
> >>>>>> pytest-pep8==1.0.4
> >>>>>> pytest-xdist==1.8
> >>>>>>
> >>>>>> execnet==1.1
> >>>>>>
> >>>>>>
> >>>>>> Please help.
> >>>>>>
> >>>>>>
> >>>>>> Also, can anyone tell which version of pytest works well with execnet1.2? This is the version that has gevent support.
> >>>>>>
> >>>>>>
> >>>>>> [image: Srinath GS on about.me]
> >>>>>>
> >>>>>> Srinath GS
> >>>>>> about.me/srinathgs
> >>>>>>   <http://about.me/srinathgs>http://srinath.im
> >>>>>> I write code @ Alamut
> >>>>>> Srinath G S
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Pytest-dev mailing list
> >>>>>> Pytest-dev at python.org
> >>>>>> https://mail.python.org/mailman/listinfo/pytest-dev
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Anatoly Bubenkov
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Anatoly Bubenkov
> >>>
> >>
> >>
> >
> >
> > --
> > Anatoly Bubenkov
> >

> _______________________________________________
> Pytest-dev mailing list
> Pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev


From bubenkoff at gmail.com  Thu Sep  4 10:12:30 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Thu, 4 Sep 2014 10:12:30 +0200
Subject: [pytest-dev] pytest.internal test failures
In-Reply-To: <CADe_7J=JMVNvJgtJ4Fuy0FsiDYq_kXAhgnYKorHB40XOwCzOxw@mail.gmail.com>
References: <CADe_7JmyHwx5_XMqcvkx5-vzYf9h2UTC40o6F0zrZTdjvphxWA@mail.gmail.com>
 <CACTnz+Fm=YDdT898+edqG-U-GoMmyBFAOu2S9THeDw2g00XFnA@mail.gmail.com>
 <CADe_7JkUFkU+n+qh57Me-Q+c1JL7W4Umu1cm2Ore=X4O6HQwFA@mail.gmail.com>
 <CACTnz+E=fVftnKneWwYi6sGQnGB5A502SCkahP372n_SN65UWQ@mail.gmail.com>
 <CADe_7JmzE4ciZMwGSPxp06pZ1KYZv3TACqVMfa8M63BoDP7gUg@mail.gmail.com>
 <CACTnz+Gu+emDVuaX8am1+wXDG2bS+JV77aryifSt809uTnmZTA@mail.gmail.com>
 <CADe_7J=JMVNvJgtJ4Fuy0FsiDYq_kXAhgnYKorHB40XOwCzOxw@mail.gmail.com>
Message-ID: <CACTnz+G7QDm7FeRQhjp0FPgV00dXWMUd46nJTWKrT0BA_-So3Q@mail.gmail.com>

execnet==1.2.0
pytest==2.6.1
py==1.4.23
pytest-xdist==1.10

but our tests don't use gevent


On 4 September 2014 10:10, Srinath <g.s.srinath89 at gmail.com> wrote:

> which execnet version do you use? 1.1 or 1.2? with 1.2 py.test -n <int>
> doesn't even run.
>
>
> [image: Srinath GS on about.me]
>
> Srinath GS
> about.me/srinathgs
>   <http://about.me/srinathgs>http://srinath.im
> I write code @ Alamut
> Srinath G S
>
>
> On Thu, Sep 4, 2014 at 1:34 PM, Anatoly Bubenkov <bubenkoff at gmail.com>
> wrote:
>
>> so that might very well be the issue - gevent does the patching of the
>> threading module which is in use of the execnet...
>> try to NOT use gevent patching but just use it directly (by importing and
>> using it's attributes), eg avoild .patch_all
>>
>>
>> On 4 September 2014 10:02, Srinath <g.s.srinath89 at gmail.com> wrote:
>>
>>> We just run py.test -n <int>. pytest automatically picks up the tests
>>> and then run. some of the unit tests import code from components.
>>> Components do gevent monkey patch. so, execnet although uses threading, the
>>> locking stuff gets overridden by gevent. Hope this clarifies the use case.
>>>
>>>
>>> [image: Srinath GS on about.me]
>>>
>>> Srinath GS
>>> about.me/srinathgs
>>>   <http://about.me/srinathgs>http://srinath.im
>>> I write code @ Alamut
>>> Srinath G S
>>>
>>>
>>> On Thu, Sep 4, 2014 at 12:52 PM, Anatoly Bubenkov <bubenkoff at gmail.com>
>>> wrote:
>>>
>>>> I mean the mode of the execnet, do you use threads there?
>>>>
>>>>
>>>> On 4 September 2014 09:10, Srinath <g.s.srinath89 at gmail.com> wrote:
>>>>
>>>>> Hi Anatoly,
>>>>>
>>>>> We use a lot of greenlets in our code. Unit Tests import them. They
>>>>> get monkey patched. So, we really can't use only threading.
>>>>>
>>>>>
>>>>> [image: Srinath GS on about.me]
>>>>>
>>>>> Srinath GS
>>>>> about.me/srinathgs
>>>>>   <http://about.me/srinathgs>http://srinath.im
>>>>> I write code @ Alamut
>>>>> Srinath G S
>>>>>
>>>>>
>>>>> On Thu, Sep 4, 2014 at 12:27 PM, Anatoly Bubenkov <bubenkoff at gmail.com
>>>>> > wrote:
>>>>>
>>>>>> we use all 4 at latest versions: pytest, pytest-xdist, execnet, py
>>>>>> and it works
>>>>>> my suggestion is to try not using greenlets and instead use default -
>>>>>> threading
>>>>>>
>>>>>>
>>>>>> On 4 September 2014 08:45, Srinath <g.s.srinath89 at gmail.com> wrote:
>>>>>>
>>>>>>>  Hi list,
>>>>>>>
>>>>>>>
>>>>>>> *23:01:51* Traceback (most recent call last):*23:01:51*   File "<string>", line 1, in <module>*23:01:51*   File "<string>", line 6, in <module>*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 1215, in serve*23:01:51*     SlaveGateway(io=io, id=id, _startcount=2).serve()*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 777, in serve*23:01:51*     self.join()*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/execnet/gateway_base.py", line 735, in join*23:01:51*     self._receiverthread.join(timeout)*23:01:51*   File "/usr/lib/python2.7/threading.py", line 668, in join*23:01:51*     self.__block.wait()*23:01:51*   File "/usr/lib/python2.7/threading.py", line 244, in wait*23:01:51*     waiter.acquire()*23:01:51*   File "_semaphore.pyx", line 112, in gevent._semaphore.Semaphore.acquire (gevent/gevent._semaphore.c:3004)*23:01:51*   File "/home/epsilon/shiningpanda/jobs/9783e24d/virtualenvs/83eb871d/local/lib/python2.7/site-packages/gevent/hub.py", line 331, in switch*23:01:51*     return greenlet.switch(self)*23:01:51* gevent.hub.LoopExit: This operation would block forever
>>>>>>>
>>>>>>>
>>>>>>> We keep getting this error in our CI system which raises `pytest.internal` error. Can anyone suggest a way to solve this?
>>>>>>>
>>>>>>>
>>>>>>> pytest version:
>>>>>>>
>>>>>>> pytest==2.5.2
>>>>>>> pytest-cache==0.9
>>>>>>> pytest-capturelog==0.7
>>>>>>> pytest-cov==1.6
>>>>>>> pytest-figleaf==1.0
>>>>>>> pytest-growl==0.1
>>>>>>> pytest-pep8==1.0.4
>>>>>>> pytest-xdist==1.8
>>>>>>>
>>>>>>> execnet==1.1
>>>>>>>
>>>>>>>
>>>>>>> Please help.
>>>>>>>
>>>>>>>
>>>>>>> Also, can anyone tell which version of pytest works well with execnet1.2? This is the version that has gevent support.
>>>>>>>
>>>>>>>
>>>>>>> [image: Srinath GS on about.me]
>>>>>>>
>>>>>>> Srinath GS
>>>>>>> about.me/srinathgs
>>>>>>>   <http://about.me/srinathgs>http://srinath.im
>>>>>>> I write code @ Alamut
>>>>>>> Srinath G S
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Pytest-dev mailing list
>>>>>>> Pytest-dev at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/pytest-dev
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Anatoly Bubenkov
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Anatoly Bubenkov
>>>>
>>>
>>>
>>
>>
>> --
>> Anatoly Bubenkov
>>
>
>


-- 
Anatoly Bubenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140904/7872885c/attachment-0001.html>

From holger at merlinux.eu  Fri Sep  5 14:00:37 2014
From: holger at merlinux.eu (holger krekel)
Date: Fri, 5 Sep 2014 12:00:37 +0000
Subject: [pytest-dev] pytest-2.6.2: fixes and freeze support
Message-ID: <20140905120037.GN28217@merlinux.eu>

pytest-2.6.2: few fixes and cx_freeze support
===========================================================================

pytest is a mature Python testing tool with more than a 1100 tests
against itself, passing on many different interpreters and platforms.
This release is drop-in compatible to 2.5.2 and 2.6.X.  It also
brings support for including pytest with cx_freeze or similar
freezing tools into your single-file app distribution.  For details
see the CHANGELOG below.

See docs at:

    http://pytest.org

As usual, you can upgrade from pypi via::

    pip install -U pytest

Thanks to all who contributed, among them:

    Floris Bruynooghe
    Benjamin Peterson
    Bruno Oliveira

have fun,
holger krekel

2.6.2
-----------

- Added function pytest.freeze_includes(), which makes it easy to embed
  pytest into executables using tools like cx_freeze.
  See docs for examples and rationale. Thanks Bruno Oliveira.

- Improve assertion rewriting cache invalidation precision.

- fixed issue561: adapt autouse fixture example for python3.

- fixed issue453: assertion rewriting issue with __repr__ containing
  "\n{", "\n}" and "\n~".

- fix issue560: correctly display code if an "else:" or "finally:" is
  followed by statements on the same line.

- Fix example in monkeypatch documentation, thanks t-8ch.

- fix issue572: correct tmpdir doc example for python3.

- Do not mark as universal wheel because Python 2.6 is different from
  other builds due to the extra argparse dependency.  Fixes issue566.
  Thanks sontek.


From ayelet at fabrixsystems.com  Mon Sep  8 16:29:07 2014
From: ayelet at fabrixsystems.com (Ayelet Regev)
Date: Mon, 08 Sep 2014 17:29:07 +0300
Subject: [pytest-dev] py.test implementation on timeline
In-Reply-To: <540DBB68.1090101@fabrixsystems.com>
References: <540DBB68.1090101@fabrixsystems.com>
Message-ID: <540DBD33.3060306@fabrixsystems.com>

Hi,

We are developing tests timeline based on py.test.
In our setup:
each test can run multiple times with different configured configuration 
parameters.
some tests thats need to be executed in parallel.
we are using xdist and starting the run-call hook each time our 
pre-required milestones are met.

our configured timeline data:

[
     {
         "test_func_name": "test_cm_delete",
         "timeline_name": "test_cm_delete_working20",
         "cfg": [
             {
                 "comment": "ChannelMapname",
                 "type": "string",
                 "name": "channel_name",
                 "value": "working_20"
             }
         ],
         "dependency": [
             {
                 "id": null,
                 "start_after": null,
                 "sync_type": "event",
                 "sync_interval": 30,
                 "sync_interval_scale": "Sec"
             }
         ]
     },
     {
         "test_func_name": "test_cm_delete",
         "timeline_name": "test_cm_delete_working21",
         "cfg": [
             {
                 "comment": "ChannelMapname",
                 "type": "string",
                 "name": "channel_name",
                 "value": "working_21"
             }
         ],
         "dependency": [
             {
                 "id": "test_cm_delete_working20",
                 "start_after": null,
                 "sync_type": "event",
                 "sync_interval": 30,
                 "sync_interval_scale": "Sec"
             }
         ]
     }
]


*our problems are:*
1) all nodes are started at once.
for each node we need to send some other "cfg" data params to execute 
the test.
we would be happy to use request object as parameter for the tests, but 
we cannot find any relation between the request and the executed test.

2) The other problems we are having related to the fact that each xdist 
slave run in diffrent memory address so we cannot change config object 
on one place to be read by all slaves during execution.
Any suggestions are welcome.




Can you assist us?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140908/45b92423/attachment.html>

From ayelet at fabrixsystems.com  Mon Sep  8 21:04:53 2014
From: ayelet at fabrixsystems.com (Ayelet Regev)
Date: Mon, 08 Sep 2014 22:04:53 +0300
Subject: [pytest-dev] py.test implementation on timeline
In-Reply-To: <540DBD33.3060306@fabrixsystems.com>
References: <540DBB68.1090101@fabrixsystems.com>
 <540DBD33.3060306@fabrixsystems.com>
Message-ID: <540DFDD5.7060802@fabrixsystems.com>

Hi,

regarding issue #1:

correct me if i'm wrong, item._request object is individual per each 
test executuion.
if this is the case i can create item._request,cfg to include my cfg 
params per each item, and to read them from the actual test function.

_*
*__*on conftest.py:*_


# Test starts hook
def pytest_runtest_call(item):
*item._request.cfg = item.cfg*
     while True:
         r = wait_for_depend_item(item)
         if r:
             break
     item.start_time = datetime.datetime.now()
     item.config.logger.info2("\n\nRun-test: %s - %s" % (item.name, 
item.cfg))



*_on t__est_cm file:_

* def test_cm_delete(request):

     cfg = request.cfg
     ....


Any comments will be welcomed.



On 08/09/14 17:29, Ayelet Regev wrote:
> Hi,
>
> We are developing tests timeline based on py.test.
> In our setup:
> each test can run multiple times with different configured 
> configuration parameters.
> some tests thats need to be executed in parallel.
> we are using xdist and starting the run-call hook each time our 
> pre-required milestones are met.
>
> our configured timeline data:
>
> [
>     {
>         "test_func_name": "test_cm_delete",
>         "timeline_name": "test_cm_delete_working20",
>         "cfg": [
>             {
>                 "comment": "ChannelMapname",
>                 "type": "string",
>                 "name": "channel_name",
>                 "value": "working_20"
>             }
>         ],
>         "dependency": [
>             {
>                 "id": null,
>                 "start_after": null,
>                 "sync_type": "event",
>                 "sync_interval": 30,
>                 "sync_interval_scale": "Sec"
>             }
>         ]
>     },
>     {
>         "test_func_name": "test_cm_delete",
>         "timeline_name": "test_cm_delete_working21",
>         "cfg": [
>             {
>                 "comment": "ChannelMapname",
>                 "type": "string",
>                 "name": "channel_name",
>                 "value": "working_21"
>             }
>         ],
>         "dependency": [
>             {
>                 "id": "test_cm_delete_working20",
>                 "start_after": null,
>                 "sync_type": "event",
>                 "sync_interval": 30,
>                 "sync_interval_scale": "Sec"
>             }
>         ]
>     }
> ]
>
>
> *our problems are:*
> 1) all nodes are started at once.
> for each node we need to send some other "cfg" data params to execute 
> the test.
> we would be happy to use request object as parameter for the tests, 
> but we cannot find any relation between the request and the executed test.
>
> 2) The other problems we are having related to the fact that each 
> xdist slave run in diffrent memory address so we cannot change config 
> object on one place to be read by all slaves during execution.
> Any suggestions are welcome.
>
>
>
>
> Can you assist us?

-- 
Best Regards,

Ayelet Regev Dabah
Email: ayelet at fabrixsystems.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140908/126313ca/attachment.html>

From ws at gocept.com  Sat Sep 13 15:50:31 2014
From: ws at gocept.com (Wolfgang Schnerring)
Date: Sat, 13 Sep 2014 13:50:31 +0000 (UTC)
Subject: [pytest-dev] Disabling timeout for pdb
Message-ID: <loom.20140913T152725-69@post.gmane.org>

Hi,

I'd really love for pytest_timeout to not perform the timeout when I'm using
pdb (more specifically, the "import pdb; pdb.set_trace()" statement; I'm
aware that pytest_timeout learned to respect the "--pdb" command line
parameter recently), because it invariably bites me and then I have to
re-run the tests with "--timeout=0", which is annoying.

So, this means I'd need to do /something/ (most probably set a flag) as part
of the pdb.set_trace() call. I gathered that pytest already wraps the
pdb.set_trace() call for its own purposes, so I guess I'd need to wrap *that*.

The easiest way to achieve that wrapping would be to subclass the
"pytestPDB" class (simply wrapping it with a function messes up the frames).
However, pytest has this magic going on where its parts are in the "_pytest"
submodule which is not a normal module but something else entirely. Which
means, as far as I can tell, I cannot "import pytest._pytest.pdb", which is
to say, I cannot access the pytestPDB class at all.

Which leaves me with two questions:
1. Am I missing something or does pytest indeed completely seal off its
internals? Does that mean pytestPDB would need to grow a plugin hook (say,
"pytest_pdb_interact", as a companion to "pytest_exception_interact")?
2. Am I approaching this wrong? How else could I go about achieving my goal
of disabling the timeout?

Thanks for your help,
Wolfgang


From nicoddemus at gmail.com  Sat Sep 13 20:53:00 2014
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Sat, 13 Sep 2014 15:53:00 -0300
Subject: [pytest-dev] Disabling timeout for pdb
In-Reply-To: <loom.20140913T152725-69@post.gmane.org>
References: <loom.20140913T152725-69@post.gmane.org>
Message-ID: <CA+RQFfe-7zH6nNfCQ0CRW_tUPE7Us-__TA+bB=xie+xmKyYMbg@mail.gmail.com>

Hi,

> 1. Am I missing something or does pytest indeed completely seal off its
internals?

Not really, you can access _pytest module directly:
>>> import _pytest.pdb
>>> _pytest.pdb.pytestPDB
<class _pytest.pdb.pytestPDB at 0x026F0500>

> 2. Am I approaching this wrong? How else could I go about achieving my
goal of disabling the timeout?

Personally I would try to implement this in pytest-timeout instead,
possibly by adding a `disable_all_timeouts()` API function would be called
automatically when `pdb.set_trace()` is called. This also leaves room for
other code to disable timeout handling if needed.

Cheers,



On Sat, Sep 13, 2014 at 10:50 AM, Wolfgang Schnerring <ws at gocept.com> wrote:

> Hi,
>
> I'd really love for pytest_timeout to not perform the timeout when I'm
> using
> pdb (more specifically, the "import pdb; pdb.set_trace()" statement; I'm
> aware that pytest_timeout learned to respect the "--pdb" command line
> parameter recently), because it invariably bites me and then I have to
> re-run the tests with "--timeout=0", which is annoying.
>
> So, this means I'd need to do /something/ (most probably set a flag) as
> part
> of the pdb.set_trace() call. I gathered that pytest already wraps the
> pdb.set_trace() call for its own purposes, so I guess I'd need to wrap
> *that*.
>
> The easiest way to achieve that wrapping would be to subclass the
> "pytestPDB" class (simply wrapping it with a function messes up the
> frames).
> However, pytest has this magic going on where its parts are in the
> "_pytest"
> submodule which is not a normal module but something else entirely. Which
> means, as far as I can tell, I cannot "import pytest._pytest.pdb", which is
> to say, I cannot access the pytestPDB class at all.
>
> Which leaves me with two questions:
> 1. Am I missing something or does pytest indeed completely seal off its
> internals? Does that mean pytestPDB would need to grow a plugin hook (say,
> "pytest_pdb_interact", as a companion to "pytest_exception_interact")?
> 2. Am I approaching this wrong? How else could I go about achieving my goal
> of disabling the timeout?
>
> Thanks for your help,
> Wolfgang
>
> _______________________________________________
> Pytest-dev mailing list
> Pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140913/aa930a38/attachment.html>

From holger at merlinux.eu  Sun Sep 14 17:00:43 2014
From: holger at merlinux.eu (holger krekel)
Date: Sun, 14 Sep 2014 15:00:43 +0000
Subject: [pytest-dev] Disabling timeout for pdb
In-Reply-To: <CA+RQFfe-7zH6nNfCQ0CRW_tUPE7Us-__TA+bB=xie+xmKyYMbg@mail.gmail.com>
References: <loom.20140913T152725-69@post.gmane.org>
 <CA+RQFfe-7zH6nNfCQ0CRW_tUPE7Us-__TA+bB=xie+xmKyYMbg@mail.gmail.com>
Message-ID: <20140914150043.GW28217@merlinux.eu>

Hi Wolfgang, Bruno,

On Sat, Sep 13, 2014 at 15:53 -0300, Bruno Oliveira wrote:
> Hi,
> 
> > 1. Am I missing something or does pytest indeed completely seal off its
> internals?
> 
> Not really, you can access _pytest module directly:
> >>> import _pytest.pdb
> >>> _pytest.pdb.pytestPDB
> <class _pytest.pdb.pytestPDB at 0x026F0500>

Right, pytest's functionality is implemented in core builtin 
plugins living at _pytest/*.py (except for core.py which is the plugin
mechanism itself).  Core and 3rd party plugins expose functions/objects
to be exposed at "pytest.*" via the pytest_namespace hook.  This
approach has advantages but also disadvantages in that it's not easy to
just read the source and discover how pytest startup actually happens.

> > 2. Am I approaching this wrong? How else could I go about achieving my
> goal of disabling the timeout?
> 
> Personally I would try to implement this in pytest-timeout instead,
> possibly by adding a `disable_all_timeouts()` API function would be called
> automatically when `pdb.set_trace()` is called. This also leaves room for
> other code to disable timeout handling if needed.

What we probabl need is a new hook, "pytest_enter_pdb" maybe, which
pytest-timeout can implement to switch off timeout  handling.
pytest would call this hook in the "pdb.set_trace()" interception 
code around _pytest/pdb.py:34.

best,
holger

From nicoddemus at gmail.com  Sun Sep 14 17:58:17 2014
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Sun, 14 Sep 2014 12:58:17 -0300
Subject: [pytest-dev] Disabling timeout for pdb
In-Reply-To: <20140914150043.GW28217@merlinux.eu>
References: <loom.20140913T152725-69@post.gmane.org>
 <CA+RQFfe-7zH6nNfCQ0CRW_tUPE7Us-__TA+bB=xie+xmKyYMbg@mail.gmail.com>
 <20140914150043.GW28217@merlinux.eu>
Message-ID: <CA+RQFfcyk3RNxpDsW+jjr2Sc_sbCc0DZq_a_Gk9+miuGChAsOA@mail.gmail.com>

Hi,

> What we probabl need is a new hook, "pytest_enter_pdb" maybe, which
> pytest-timeout can implement to switch off timeout  handling.
> pytest would call this hook in the "pdb.set_trace()" interception
> code around _pytest/pdb.py:34.

I like this idea, seems simple enough to implement. :)

Cheers,

On Sun, Sep 14, 2014 at 12:00 PM, holger krekel <holger at merlinux.eu> wrote:

> Hi Wolfgang, Bruno,
>
> On Sat, Sep 13, 2014 at 15:53 -0300, Bruno Oliveira wrote:
> > Hi,
> >
> > > 1. Am I missing something or does pytest indeed completely seal off its
> > internals?
> >
> > Not really, you can access _pytest module directly:
> > >>> import _pytest.pdb
> > >>> _pytest.pdb.pytestPDB
> > <class _pytest.pdb.pytestPDB at 0x026F0500>
>
> Right, pytest's functionality is implemented in core builtin
> plugins living at _pytest/*.py (except for core.py which is the plugin
> mechanism itself).  Core and 3rd party plugins expose functions/objects
> to be exposed at "pytest.*" via the pytest_namespace hook.  This
> approach has advantages but also disadvantages in that it's not easy to
> just read the source and discover how pytest startup actually happens.
>
> > > 2. Am I approaching this wrong? How else could I go about achieving my
> > goal of disabling the timeout?
> >
> > Personally I would try to implement this in pytest-timeout instead,
> > possibly by adding a `disable_all_timeouts()` API function would be
> called
> > automatically when `pdb.set_trace()` is called. This also leaves room for
> > other code to disable timeout handling if needed.
>
> What we probabl need is a new hook, "pytest_enter_pdb" maybe, which
> pytest-timeout can implement to switch off timeout  handling.
> pytest would call this hook in the "pdb.set_trace()" interception
> code around _pytest/pdb.py:34.
>
> best,
> holger
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140914/293321d8/attachment.html>

From ws at gocept.com  Mon Sep 15 08:19:50 2014
From: ws at gocept.com (Wolfgang Schnerring)
Date: Mon, 15 Sep 2014 08:19:50 +0200
Subject: [pytest-dev] Disabling timeout for pdb
References: <loom.20140913T152725-69@post.gmane.org>
 <CA+RQFfe-7zH6nNfCQ0CRW_tUPE7Us-__TA+bB=xie+xmKyYMbg@mail.gmail.com>
 <20140914150043.GW28217@merlinux.eu>
Message-ID: <20140915081950.3fe453f1@widnar>

Hi,

thanks for your feedback!

* Bruno Oliveira [2014-09-13 15:53]:
> > 1. Am I missing something or does pytest indeed completely seal off its internals?
> Not really, you can access _pytest module directly:
> >>> import _pytest.pdb
> >>> _pytest.pdb.pytestPDB
> <class _pytest.pdb.pytestPDB at 0x026F0500>

Right. Trust me to miss the absolutely obvious way of doing it. ;)

So, using this, I guess I could implement the feature from within the
pytest_timeout plugin, by subclassing pytestPDB and overriding the
"pytest.set_trace" binding by providing a pytest_namespace() that points to the
subclassed version. And then I'd probably have to re-monkeypatch
"pdb.set_trace" while I'm at it, or else that will still point to the pytestPDB
instance set up by core pytest. Wellll. Doable, but ugly, so...

* holger krekel [2014-09-14 15:00]:
> What we probabl need is a new hook, "pytest_enter_pdb" maybe, which
> pytest-timeout can implement to switch off timeout  handling.
> pytest would call this hook in the "pdb.set_trace()" interception 
> code around _pytest/pdb.py:34.

... an explicit hook like this would probably be better.
If that's alright with you I could give this a try. That'll necessitate changes
in both pytest and pytest_timeout, but I do think it's the cleaner solution.

Wolfgang


From ws at gocept.com  Mon Sep 15 08:21:30 2014
From: ws at gocept.com (Wolfgang Schnerring)
Date: Mon, 15 Sep 2014 08:21:30 +0200
Subject: [pytest-dev] conftest.py ordering depends on the current directory?
Message-ID: <20140915082130.23489b55@widnar>

Hi,

if you have a nested module structure with nested conftest files
that (re)define the same fixture name, my expectation is that the
definition of the "closest" conftest file is used -- and usually this
works fine (yay! :-).

For example (please see the attached tarball), if
    * something/conftest.py defines fixture "one" as 1
    * something/submodule/conftest.py defines fixture "one" as 2
then I think this should mean that tests in
    * something and something/tests should get "1", while
    * something/submodule and something/submodule/tests should get "2"

However, this seems to depend on the current working directory or
something. If the py.test binary is in another directory, say next to
the sources, then:
    * "cd ..; py.test package" works, while
    * "py.test ../package" does not
(You can try these with the attached tarball by going into the runner
directory and calling "make working" or "make notworking").

Can somebody tell me what's going on here? Is this intentional? Am I
missing something?

Thanks for your help,
Wolfgang
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reproduction.tar.gz
Type: application/gzip
Size: 997 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140915/0d7d04d4/attachment.bin>

From holger at merlinux.eu  Mon Sep 15 09:13:02 2014
From: holger at merlinux.eu (holger krekel)
Date: Mon, 15 Sep 2014 07:13:02 +0000
Subject: [pytest-dev] Disabling timeout for pdb
In-Reply-To: <20140915081950.3fe453f1@widnar>
References: <loom.20140913T152725-69@post.gmane.org>
 <CA+RQFfe-7zH6nNfCQ0CRW_tUPE7Us-__TA+bB=xie+xmKyYMbg@mail.gmail.com>
 <20140914150043.GW28217@merlinux.eu>
 <20140915081950.3fe453f1@widnar>
Message-ID: <20140915071302.GY28217@merlinux.eu>

Hi Wolfgang,

On Mon, Sep 15, 2014 at 08:19 +0200, Wolfgang Schnerring wrote:
> Hi,
> 
> thanks for your feedback!
> 
> * Bruno Oliveira [2014-09-13 15:53]:
> > > 1. Am I missing something or does pytest indeed completely seal off its internals?
> > Not really, you can access _pytest module directly:
> > >>> import _pytest.pdb
> > >>> _pytest.pdb.pytestPDB
> > <class _pytest.pdb.pytestPDB at 0x026F0500>
> 
> Right. Trust me to miss the absolutely obvious way of doing it. ;)
> 
> So, using this, I guess I could implement the feature from within the
> pytest_timeout plugin, by subclassing pytestPDB and overriding the
> "pytest.set_trace" binding by providing a pytest_namespace() that points to the
> subclassed version. And then I'd probably have to re-monkeypatch
> "pdb.set_trace" while I'm at it, or else that will still point to the pytestPDB
> instance set up by core pytest. Wellll. Doable, but ugly, so...
> 
> * holger krekel [2014-09-14 15:00]:
> > What we probabl need is a new hook, "pytest_enter_pdb" maybe, which
> > pytest-timeout can implement to switch off timeout  handling.
> > pytest would call this hook in the "pdb.set_trace()" interception 
> > code around _pytest/pdb.py:34.
> 
> ... an explicit hook like this would probably be better.
> If that's alright with you I could give this a try. That'll necessitate changes
> in both pytest and pytest_timeout, but I do think it's the cleaner solution.

Sure, don't hesitate to ask back any questions.  FYI _pytest/hookspec.py
defines hooks and pluginmanager.hook.pytest_*() is how to call them when
you have a pluginmanager reference (config.hook and item.ihook also
allow to call hooks as a shortcut).

cheers,
holger

> Wolfgang
> 
> _______________________________________________
> Pytest-dev mailing list
> Pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
> 

From holger at merlinux.eu  Mon Sep 15 12:47:57 2014
From: holger at merlinux.eu (holger krekel)
Date: Mon, 15 Sep 2014 10:47:57 +0000
Subject: [pytest-dev] conftest.py ordering depends on the current
 directory?
In-Reply-To: <20140915082130.23489b55@widnar>
References: <20140915082130.23489b55@widnar>
Message-ID: <20140915104757.GZ28217@merlinux.eu>

Hi Wolfgang,

On Mon, Sep 15, 2014 at 08:21 +0200, Wolfgang Schnerring wrote:
> Hi,
> 
> if you have a nested module structure with nested conftest files
> that (re)define the same fixture name, my expectation is that the
> definition of the "closest" conftest file is used -- and usually this
> works fine (yay! :-).

so far so good :)

> For example (please see the attached tarball), if
>     * something/conftest.py defines fixture "one" as 1
>     * something/submodule/conftest.py defines fixture "one" as 2
> then I think this should mean that tests in
>     * something and something/tests should get "1", while
>     * something/submodule and something/submodule/tests should get "2"
> 
> However, this seems to depend on the current working directory or
> something. If the py.test binary is in another directory, say next to
> the sources, then:
>     * "cd ..; py.test package" works, while
>     * "py.test ../package" does not
> (You can try these with the attached tarball by going into the runner
> directory and calling "make working" or "make notworking").
> 
> Can somebody tell me what's going on here? Is this intentional? Am I
> missing something?

You win :) It's a real bug and thanks for the replicatable example.
I fixed it here https://bitbucket.org/hpk42/pytest/pull-request/202/fix-conftest-related-fixture-visibility/diff
and you can install it with::

    pip install --pre -U -i https://devpi.net/hpk/dev/ pytest

best,
holger

From ws at gocept.com  Mon Sep 15 13:26:55 2014
From: ws at gocept.com (Wolfgang Schnerring)
Date: Mon, 15 Sep 2014 13:26:55 +0200
Subject: [pytest-dev] conftest.py ordering depends on the current
	directory?
References: <20140915082130.23489b55@widnar>
 <20140915104757.GZ28217@merlinux.eu>
Message-ID: <20140915132655.6c060c4d@widnar>

Hi Holger,

* holger krekel [2014-09-15 10:47]:
> You win :) It's a real bug and thanks for the replicatable example.
> I fixed it here https://bitbucket.org/hpk42/pytest/pull-request/202/fix-conftest-related-fixture-visibility/diff

Wow, that was quick! Thank you very much! :)

Wolfgang


From holger at merlinux.eu  Mon Sep 15 13:50:00 2014
From: holger at merlinux.eu (holger krekel)
Date: Mon, 15 Sep 2014 11:50:00 +0000
Subject: [pytest-dev] conftest.py ordering depends on the current
 directory?
In-Reply-To: <20140915132655.6c060c4d@widnar>
References: <20140915082130.23489b55@widnar>
 <20140915104757.GZ28217@merlinux.eu>
 <20140915132655.6c060c4d@widnar>
Message-ID: <20140915115000.GB28217@merlinux.eu>

Hi Wolfgang,

On Mon, Sep 15, 2014 at 13:26 +0200, Wolfgang Schnerring wrote:
> Hi Holger,
> 
> * holger krekel [2014-09-15 10:47]:
> > You win :) It's a real bug and thanks for the replicatable example.
> > I fixed it here https://bitbucket.org/hpk42/pytest/pull-request/202/fix-conftest-related-fixture-visibility/diff
> 
> Wow, that was quick! Thank you very much! :)

Was a bit by chance -- originally i wanted to ask you to file a bug issue
and decided to "quickly" look into the issue in order to highlight where
the problem likely is to ease a PR by someone else.  When trying to state/
pinpoint the problem somewhat precisely, i looked a bit further ... and 
further ... and after more head scratching eventually just changed 
2 LOCs only 1-2 hours later ...

If you hadn't provided an easy way to reproduce the problem that
wouldn't have happened, though.  The only way you could have done even
better is with a PR that adds an xfailing test directly :)

cheers,
holger

From ws at gocept.com  Mon Sep 15 14:15:27 2014
From: ws at gocept.com (Wolfgang Schnerring)
Date: Mon, 15 Sep 2014 14:15:27 +0200
Subject: [pytest-dev] conftest.py ordering depends on the current
	directory?
References: <20140915082130.23489b55@widnar>
 <20140915104757.GZ28217@merlinux.eu>
 <20140915132655.6c060c4d@widnar>
 <20140915115000.GB28217@merlinux.eu>
Message-ID: <20140915141527.4a949f02@widnar>

Hello Holger,

* holger krekel [2014-09-15 13:50]:
> ... and after more head scratching eventually just changed 2 LOCs only 1-2 hours later ...

I know how these kind of bugs feel... research/analayse/headscratch/headdesk
for several hours, and the actual fix required is to change a line or two.

> The only way you could have done even
> better is with a PR that adds an xfailing test directly :)

I'll try to do that the next time :), however I must confess the pytest
internals (and, correspondingly, its selftests) are still quite arcane to me,
even though I'v dug through there in search of various stuff on several
occasions now. So... I'd love to get a more in-depth introduction, at a sprint
sometime maybe?

Wolfgang


From holger at merlinux.eu  Mon Sep 15 14:46:11 2014
From: holger at merlinux.eu (holger krekel)
Date: Mon, 15 Sep 2014 12:46:11 +0000
Subject: [pytest-dev] conftest.py ordering depends on the current
 directory?
In-Reply-To: <20140915141527.4a949f02@widnar>
References: <20140915082130.23489b55@widnar>
 <20140915104757.GZ28217@merlinux.eu>
 <20140915132655.6c060c4d@widnar>
 <20140915115000.GB28217@merlinux.eu>
 <20140915141527.4a949f02@widnar>
Message-ID: <20140915124611.GD28217@merlinux.eu>

Hi Wolfgang,

On Mon, Sep 15, 2014 at 14:15 +0200, Wolfgang Schnerring wrote:
> Hello Holger,
> 
> * holger krekel [2014-09-15 13:50]:
> > ... and after more head scratching eventually just changed 2 LOCs only 1-2 hours later ...
> 
> I know how these kind of bugs feel... research/analayse/headscratch/headdesk
> for several hours, and the actual fix required is to change a line or two.

I guess you know about https://vine.co/v/hPXTA6l9AqQ :)
(also posted on twitter)

> > The only way you could have done even
> > better is with a PR that adds an xfailing test directly :)
> 
> I'll try to do that the next time :), however I must confess the pytest
> internals (and, correspondingly, its selftests) are still quite arcane to me,
> even though I'v dug through there in search of various stuff on several
> occasions now. So... I'd love to get a more in-depth introduction, at a sprint
> sometime maybe?

Sure, or you can try to grab e.g. Floris, Ronny, Anatoly on an occassion
as they know quite a bit as well.  Most self tests are quite functional,
btw, for example if you look at the test i added mapping the example that
you gave.  I.e. writing a test does not require knowing details of the
internals that much.

best,
holger



> Wolfgang
> 
> _______________________________________________
> Pytest-dev mailing list
> Pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
> 

From ayelet at fabrixsystems.com  Wed Sep 17 15:18:05 2014
From: ayelet at fabrixsystems.com (Ayelet Regev)
Date: Wed, 17 Sep 2014 16:18:05 +0300
Subject: [pytest-dev] Question on item result
Message-ID: <54198A0C.1000505@fabrixsystems.com>

Hi,

I want to be able to get the result from each item at teardown.
What should i look for?

-- 
Best Regards,

Ayelet Regev Dabah
Email: ayelet at fabrixsystems.com


From holger at merlinux.eu  Wed Sep 17 16:28:45 2014
From: holger at merlinux.eu (Holger Krekel)
Date: Wed, 17 Sep 2014 16:28:45 +0200
Subject: [pytest-dev] Question on item result
In-Reply-To: <54198A0C.1000505@fabrixsystems.com>
References: <54198A0C.1000505@fabrixsystems.com>
Message-ID: <61efc209-91dd-4910-8004-9eb62b84e532@email.android.com>

You might adapt this example: http://pytest.org/latest/example/simple.html#making-test-result-information-available-in-fixtures

On September 17, 2014 3:18:05 PM CEST, Ayelet Regev <ayelet at fabrixsystems.com> wrote:
>Hi,
>
>I want to be able to get the result from each item at teardown.
>What should i look for?
>
>-- 
>Best Regards,
>
>Ayelet Regev Dabah
>Email: ayelet at fabrixsystems.com
>
>_______________________________________________
>Pytest-dev mailing list
>Pytest-dev at python.org
>https://mail.python.org/mailman/listinfo/pytest-dev

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140917/5692f0f3/attachment.html>

From ayelet at fabrixsystems.com  Wed Sep 17 16:50:27 2014
From: ayelet at fabrixsystems.com (Ayelet Regev)
Date: Wed, 17 Sep 2014 17:50:27 +0300
Subject: [pytest-dev] Question on item result
In-Reply-To: <61efc209-91dd-4910-8004-9eb62b84e532@email.android.com>
References: <54198A0C.1000505@fabrixsystems.com>
 <61efc209-91dd-4910-8004-9eb62b84e532@email.android.com>
Message-ID: <54199FB3.1040204@fabrixsystems.com>

i am using this hook...

i have 1 test with 2 configurations provided using item._request.cfg

then when im running the tests using xdist, i see that 
"slaveoutput["exitstatus"] is aware of the failure. but report.outcome 
climing both have "passed"



def test_cm_delete(request):
     cfg = request.cfg
     if cfg.get("channel_name") == "working_20":
         assert True
     else:
         assert False


def pytest_runtest_makereport(__multicall__, item, call):
     report = __multicall__.execute()
     if call.when == "teardown" :
         try:
*item.config.logger.info2("item %s with cfg %s - Report OUTCOME : %s" % 
(item.name,item._request.cfg,report.outcome))*
         except:
             pass
     return report


def pytest_testnodedown(node, error):
*node.config.logger.info2("slaveoutput of node %s" % (node.slaveoutput))*





log:


[2014-09-17 17:44:56,209][MainThread] Run-test: test_cm_delete - 
[{'comment': u'ChannelMapname', 'name': u'channel_name', 'defaultvalue': 
u'bbbbbb', 'value': u'working_21', 'choices': 
u'functionnametosendtoknownURLwithargsofactivityandfuncname', 'type': 
u'string'}]
[2014-09-17 17:44:56,217][MainThread] Teardown: test_cm_delete - 
[{'comment': u'ChannelMapname', 'name': u'channel_name', 'defaultvalue': 
u'bbbbbb', 'value': u'working_21', 'choices': 
u'functionnametosendtoknownURLwithargsofactivityandfuncname', 'type': 
u'string'}]
[2014-09-17 17:44:56,218][MainThread] *item test_cm_delete with cfg 
{u'channel_name': u'working_21'} - Report OUTCOME : passed*
[2014-09-17 17:44:56,225][MainThread] *slaveoutput of node 
{'exitstatus': 1}*
[2014-09-17 17:45:00,218][MainThread] Run-test: test_cm_delete - 
[{'comment': u'ChannelMapname', 'name': u'channel_name', 'defaultvalue': 
u'aaaaaaaaaaaaa', 'value': u'working_20', 'choices': u'functionname to 
send to known URL with args of activity and funcname', 'type': u'string'}]
[2014-09-17 17:45:00,219][MainThread] Teardown: test_cm_delete - 
[{'comment': u'ChannelMapname', 'name': u'channel_name', 'defaultvalue': 
u'aaaaaaaaaaaaa', 'value': u'working_20', 'choices': u'functionname to 
send to known URL with args of activity and funcname', 'type': u'string'}]
[2014-09-17 17:45:00,220][MainThread] *item test_cm_delete with cfg 
{u'channel_name': u'working_20'} - Report OUTCOME : passed*
[2014-09-17 17:45:00,226][MainThread]*slaveoutput of node {'exitstatus': 0}*


console output:

platform linux2 -- Python 2.7.6 -- py-1.4.23 -- pytest-2.6.1 -- 
/usr/bin/python
plugins: xdist, timeout, cov
[gw0] linux2 Python 2.7.6 cwd: 
/home/ayelet/Scripts/sysu/root/var/sysu/cache/Activities
[gw1] linux2 Python 2.7.6 cwd: 
/home/ayelet/Scripts/sysu/root/var/sysu/cache/Activities
[gw0] Python 2.7.6 (default, Mar 22 2014, 22:59:56)  -- [GCC 4.8.2]
[gw1] Python 2.7.6 (default, Mar 22 2014, 22:59:56)  -- [GCC 4.8.2]
gw0 [2] / gw1 [2]
scheduling tests via LoadScheduling

Ingest/ChannelMap/delete_cm/test_delete_cm.py::test_cm_delete
*[gw0] FAILED 
Ingest/ChannelMap/delete_cm/test_delete_cm.py::test_cm_delete **
**[gw1] PASSED 
Ingest/ChannelMap/delete_cm/test_delete_cm.py::test_cm_delete *

============================================================================ 
FAILURES 
=============================================================================
_________________________________________________________________________ test_cm_delete 
__________________________________________________________________________
[gw0] linux2 -- Python 2.7.6 /usr/bin/python
request = <FixtureRequest for <Function 'test_cm_delete'>>

     def test_cm_delete(request):
         cfg = request.cfg
         servers_data = request.config.properties["Servers"]
         #request.config.logger.info2("AYELET WAS HERE %s" % (cfg))
         request.basa = "BASA"
         #assert delete_cm(cfg,servers_data) == 200
         if cfg.get("channel_name") == "working_20":
             assert True
         else:
 >           assert False
E           assert False

Ingest/ChannelMap/delete_cm/test_delete_cm.py:22: AssertionError
*=============================================================== 1 
failed, 1 passed in 6.23 seconds 
================================================================*




On 17/09/14 17:28, Holger Krekel wrote:
> You might adapt this example: 
> http://pytest.org/latest/example/simple.html#making-test-result-information-available-in-fixtures
>
> On September 17, 2014 3:18:05 PM CEST, Ayelet Regev 
> <ayelet at fabrixsystems.com> wrote:
>
>     Hi,
>
>     I want to be able to get the result from each item at teardown.
>     What should i look for?
>
>
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity. 

-- 
Best Regards,

Ayelet Regev Dabah
Email: ayelet at fabrixsystems.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140917/6033f99f/attachment.html>

From ayelet at fabrixsystems.com  Wed Sep 17 17:38:06 2014
From: ayelet at fabrixsystems.com (Ayelet Regev)
Date: Wed, 17 Sep 2014 18:38:06 +0300
Subject: [pytest-dev] Question on item result
In-Reply-To: <54199FB3.1040204@fabrixsystems.com>
References: <54198A0C.1000505@fabrixsystems.com>
 <61efc209-91dd-4910-8004-9eb62b84e532@email.android.com>
 <54199FB3.1040204@fabrixsystems.com>
Message-ID: <5419AADE.7060903@fabrixsystems.com>

thanks!!!

your suggestion was very helpful.
to use*item.rep_call.outcome* and not *report.outcome*



def pytest_runtest_makereport(__multicall__, item, call):

     report = __multicall__.execute()
     setattr(item, "rep_" + report.when, report)
     if call.when == "teardown" :
         try:
             item.config.logger.info2((item.rep_call.outcome))
         except:
             pass
     return report


On 17/09/14 17:50, Ayelet Regev wrote:
> i am using this hook...
>
> i have 1 test with 2 configurations provided using item._request.cfg
>
> then when im running the tests using xdist, i see that 
> "slaveoutput["exitstatus"] is aware of the failure. but report.outcome 
> climing both have "passed"
>
>
>
> def test_cm_delete(request):
>     cfg = request.cfg
>     if cfg.get("channel_name") == "working_20":
>         assert True
>     else:
>         assert False
>
>
> def pytest_runtest_makereport(__multicall__, item, call):
>     report = __multicall__.execute()
>     if call.when == "teardown" :
>         try:
> *item.config.logger.info2("item %s with cfg %s - Report OUTCOME : %s" 
> % (item.name,item._request.cfg,report.outcome))*
>         except:
>             pass
>     return report
>
>
> def pytest_testnodedown(node, error):
> *node.config.logger.info2("slaveoutput of node %s" % (node.slaveoutput))*
>
>
>
>
>
> log:
>
>
> [2014-09-17 17:44:56,209][MainThread] Run-test: test_cm_delete - 
> [{'comment': u'ChannelMapname', 'name': u'channel_name', 
> 'defaultvalue': u'bbbbbb', 'value': u'working_21', 'choices': 
> u'functionnametosendtoknownURLwithargsofactivityandfuncname', 'type': 
> u'string'}]
> [2014-09-17 17:44:56,217][MainThread] Teardown: test_cm_delete - 
> [{'comment': u'ChannelMapname', 'name': u'channel_name', 
> 'defaultvalue': u'bbbbbb', 'value': u'working_21', 'choices': 
> u'functionnametosendtoknownURLwithargsofactivityandfuncname', 'type': 
> u'string'}]
> [2014-09-17 17:44:56,218][MainThread] *item test_cm_delete with cfg 
> {u'channel_name': u'working_21'} - Report OUTCOME : passed*
> [2014-09-17 17:44:56,225][MainThread] *slaveoutput of node 
> {'exitstatus': 1}*
> [2014-09-17 17:45:00,218][MainThread] Run-test: test_cm_delete - 
> [{'comment': u'ChannelMapname', 'name': u'channel_name', 
> 'defaultvalue': u'aaaaaaaaaaaaa', 'value': u'working_20', 'choices': 
> u'functionname to send to known URL with args of activity and 
> funcname', 'type': u'string'}]
> [2014-09-17 17:45:00,219][MainThread] Teardown: test_cm_delete - 
> [{'comment': u'ChannelMapname', 'name': u'channel_name', 
> 'defaultvalue': u'aaaaaaaaaaaaa', 'value': u'working_20', 'choices': 
> u'functionname to send to known URL with args of activity and 
> funcname', 'type': u'string'}]
> [2014-09-17 17:45:00,220][MainThread] *item test_cm_delete with cfg 
> {u'channel_name': u'working_20'} - Report OUTCOME : passed*
> [2014-09-17 17:45:00,226][MainThread]*slaveoutput of node 
> {'exitstatus': 0}*
>
>
> console output:
>
> platform linux2 -- Python 2.7.6 -- py-1.4.23 -- pytest-2.6.1 -- 
> /usr/bin/python
> plugins: xdist, timeout, cov
> [gw0] linux2 Python 2.7.6 cwd: 
> /home/ayelet/Scripts/sysu/root/var/sysu/cache/Activities
> [gw1] linux2 Python 2.7.6 cwd: 
> /home/ayelet/Scripts/sysu/root/var/sysu/cache/Activities
> [gw0] Python 2.7.6 (default, Mar 22 2014, 22:59:56)  -- [GCC 4.8.2]
> [gw1] Python 2.7.6 (default, Mar 22 2014, 22:59:56)  -- [GCC 4.8.2]
> gw0 [2] / gw1 [2]
> scheduling tests via LoadScheduling
>
> Ingest/ChannelMap/delete_cm/test_delete_cm.py::test_cm_delete
> *[gw0] FAILED 
> Ingest/ChannelMap/delete_cm/test_delete_cm.py::test_cm_delete **
> **[gw1] PASSED 
> Ingest/ChannelMap/delete_cm/test_delete_cm.py::test_cm_delete *
>
> ============================================================================ 
> FAILURES 
> =============================================================================
> _________________________________________________________________________ 
> test_cm_delete 
> __________________________________________________________________________
> [gw0] linux2 -- Python 2.7.6 /usr/bin/python
> request = <FixtureRequest for <Function 'test_cm_delete'>>
>
>     def test_cm_delete(request):
>         cfg = request.cfg
>         servers_data = request.config.properties["Servers"]
>         #request.config.logger.info2("AYELET WAS HERE %s" % (cfg))
>         request.basa = "BASA"
>         #assert delete_cm(cfg,servers_data) == 200
>         if cfg.get("channel_name") == "working_20":
>             assert True
>         else:
> >           assert False
> E           assert False
>
> Ingest/ChannelMap/delete_cm/test_delete_cm.py:22: AssertionError
> *=============================================================== 1 
> failed, 1 passed in 6.23 seconds 
> ================================================================*
>
>
>
>
> On 17/09/14 17:28, Holger Krekel wrote:
>> You might adapt this example: 
>> http://pytest.org/latest/example/simple.html#making-test-result-information-available-in-fixtures
>>
>> On September 17, 2014 3:18:05 PM CEST, Ayelet Regev 
>> <ayelet at fabrixsystems.com> wrote:
>>
>>     Hi,
>>
>>     I want to be able to get the result from each item at teardown.
>>     What should i look for?
>>
>>
>> -- 
>> Sent from my Android device with K-9 Mail. Please excuse my brevity. 
>
> -- 
> Best Regards,
>
> Ayelet Regev Dabah
> Email:ayelet at fabrixsystems.com

-- 
Best Regards,

Ayelet Regev Dabah
Email: ayelet at fabrixsystems.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140917/1f15f9da/attachment-0001.html>

From ayelet at fabrixsystems.com  Wed Sep 17 18:32:20 2014
From: ayelet at fabrixsystems.com (Ayelet Regev)
Date: Wed, 17 Sep 2014 19:32:20 +0300
Subject: [pytest-dev] xdist and data sharing during execution in parallel
Message-ID: <5419B794.2070905@fabrixsystems.com>

Hi,

I'm creating a time-line based on pytest.
im using xdist with multiple slaves (in the amount of the tests). Each 
test is started by time and dependency. which mean some of the gateways 
will be waiting for others to be "Done".

for that, io need some data sharing between them all, and cannot use 
"slaveoutput".

i created my own dict object using file handler, and i want to create 
instance once on master and share it will all slaves.

but i cannot pass object to "slaveinput"

Do you have any advice?


*
**def pytest_configure(config):*

     config.global_time_line_json = config.getoption("timeline",None)
     unicode_to_ascii(config.global_time_line_json)
     if config.global_time_line_json is None:
         raise Exception("no timeline data was provided to command")
     config.properties = config.getoption("properties")
     unicode_to_ascii(config.properties)
     logfile = config.properties.get("logfile",None)
     if logfile is None:
         raise Exception("no logfile path was provided to command under 
properties")
     config.flow_dir = config.properties.get("flow_dir",None)
     logfile_basename = os.path.basename(logfile)
     _logger = Logger(config.flow_dir,logfile_basename)
     config.logger = _logger.logger()
     config.active_dir = "%s/%s" % (config.flow_dir,ACTIVE_DIR)
*if not hasattr(config,"slaveinput"):**
**        config.logger.info2("Master")**
**        config.global_data = PersistentDict('%s/%s' % 
(config.active_dir,FLOW_JSON), 'c', format='json')*

*def pytest_configure_node(node):*
     # runs only on Master
     node.config.logger.info2("on Master sending data to Slave")
*node.slaveinput["global_data"] = node.config.global_data*

-- 
Best Regards,

Ayelet Regev Dabah
Email: ayelet at fabrixsystems.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140917/58f4901f/attachment.html>

From ws at gocept.com  Thu Sep 18 15:05:14 2014
From: ws at gocept.com (Wolfgang Schnerring)
Date: Thu, 18 Sep 2014 15:05:14 +0200
Subject: [pytest-dev] Disabling timeout for pdb
References: <loom.20140913T152725-69@post.gmane.org>
 <CA+RQFfe-7zH6nNfCQ0CRW_tUPE7Us-__TA+bB=xie+xmKyYMbg@mail.gmail.com>
 <20140914150043.GW28217@merlinux.eu>
 <20140915081950.3fe453f1@widnar>
 <20140915071302.GY28217@merlinux.eu>
Message-ID: <20140918150514.6e413184@widnar>

Hello!

* holger krekel [2014-09-15 07:13]:
> > > What we probabl need is a new hook, "pytest_enter_pdb" maybe, which
> > > pytest-timeout can implement to switch off timeout  handling.
> > > pytest would call this hook in the "pdb.set_trace()" interception 
> > > code around _pytest/pdb.py:34.
> > If that's alright with you I could give this a try. That'll necessitate
> > changes in both pytest and pytest_timeout, but I do think it's the cleaner
> > solution.
> Sure, don't hesitate to ask back any questions.  FYI _pytest/hookspec.py
> defines hooks and pluginmanager.hook.pytest_*() is how to call them when
> you have a pluginmanager reference (config.hook and item.ihook also
> allow to call hooks as a shortcut).

Thanks for the pointer, this made my work rather easier!

So, here's my shot at this:
https://bitbucket.org/hpk42/pytest/pull-request/204/diff
https://bitbucket.org/flub/pytest-timeout/pull-request/3/diff

Feedback is welcome. :)

Wolfgang


From holger at merlinux.eu  Thu Sep 18 20:21:52 2014
From: holger at merlinux.eu (holger krekel)
Date: Thu, 18 Sep 2014 18:21:52 +0000
Subject: [pytest-dev] pytest-xdist-1.11: restarting crash nodes,
	fixture cache fix
Message-ID: <20140918182152.GK3692@merlinux.eu>


I just released pytest-xdist-1.11, the distributed testing plugin for pytest.
It introduces automatic restarting of crashed nodes, courtesy of a 
complete PR from Floris Bruynooghe.  This also works well together with
pytest-timeout by the same author: When one or more test functions hang
or crash, the overall test run will still complete and report about the
incidents.  See the changelog below for more changes and the pypi
project page for what pytest-xdist offers in general:

    https://pypi.python.org/pypi/pytest-xdist/

Thanks also to an undisclosed company who partly funded the work
and to Andreas Pelme for contributing analysis of a fixture caching
failure including a test.

best,
Holger Krekel


1.11
-------------------------

- fix pytest/xdist issue485 (also depends on py-1.4.22):
  attach stdout/stderr on --boxed processes that die.

- fix pytest/xdist issue503: make sure that a node has usually
  two items to execute to avoid scoped fixtures to be torn down
  pre-maturely (fixture teardown/setup is "nextitem" sensitive).
  Thanks to Andreas Pelme for bug analysis and failing test.

- restart crashed nodes by internally refactoring setup handling
  of nodes.  Also includes better code documentation.  
  Many thanks to Floris Bruynooghe for the complete PR.


From bubenkoff at gmail.com  Thu Sep 18 20:23:44 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Thu, 18 Sep 2014 20:23:44 +0200
Subject: [pytest-dev] pytest-xdist-1.11: restarting crash nodes,
 fixture cache fix
In-Reply-To: <20140918182152.GK3692@merlinux.eu>
References: <20140918182152.GK3692@merlinux.eu>
Message-ID: <CACTnz+GsmJ8uTbgANqgddskTDHc8vB80aUBEQVtAVXaQxnsYSQ@mail.gmail.com>

Great!
thanks a lot everyone involved

On 18 September 2014 20:21, holger krekel <holger at merlinux.eu> wrote:

>
> I just released pytest-xdist-1.11, the distributed testing plugin for
> pytest.
> It introduces automatic restarting of crashed nodes, courtesy of a
> complete PR from Floris Bruynooghe.  This also works well together with
> pytest-timeout by the same author: When one or more test functions hang
> or crash, the overall test run will still complete and report about the
> incidents.  See the changelog below for more changes and the pypi
> project page for what pytest-xdist offers in general:
>
>     https://pypi.python.org/pypi/pytest-xdist/
>
> Thanks also to an undisclosed company who partly funded the work
> and to Andreas Pelme for contributing analysis of a fixture caching
> failure including a test.
>
> best,
> Holger Krekel
>
>
> 1.11
> -------------------------
>
> - fix pytest/xdist issue485 (also depends on py-1.4.22):
>   attach stdout/stderr on --boxed processes that die.
>
> - fix pytest/xdist issue503: make sure that a node has usually
>   two items to execute to avoid scoped fixtures to be torn down
>   pre-maturely (fixture teardown/setup is "nextitem" sensitive).
>   Thanks to Andreas Pelme for bug analysis and failing test.
>
> - restart crashed nodes by internally refactoring setup handling
>   of nodes.  Also includes better code documentation.
>   Many thanks to Floris Bruynooghe for the complete PR.
>
> _______________________________________________
> Pytest-dev mailing list
> Pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>



-- 
Anatoly Bubenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140918/d36f47e4/attachment.html>

From bubenkoff at gmail.com  Thu Sep 18 20:24:45 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Thu, 18 Sep 2014 20:24:45 +0200
Subject: [pytest-dev] pytest-xdist-1.11: restarting crash nodes,
 fixture cache fix
In-Reply-To: <CACTnz+GsmJ8uTbgANqgddskTDHc8vB80aUBEQVtAVXaQxnsYSQ@mail.gmail.com>
References: <20140918182152.GK3692@merlinux.eu>
 <CACTnz+GsmJ8uTbgANqgddskTDHc8vB80aUBEQVtAVXaQxnsYSQ@mail.gmail.com>
Message-ID: <CACTnz+GicEjqowQg_-8GpLGFEVDdCFbNgHq+7DXxaEQTshjUKg@mail.gmail.com>

so, this is again guaranteed that there will be only one session per test
run on any test slave?

On 18 September 2014 20:23, Anatoly Bubenkov <bubenkoff at gmail.com> wrote:

> Great!
> thanks a lot everyone involved
>
> On 18 September 2014 20:21, holger krekel <holger at merlinux.eu> wrote:
>
>>
>> I just released pytest-xdist-1.11, the distributed testing plugin for
>> pytest.
>> It introduces automatic restarting of crashed nodes, courtesy of a
>> complete PR from Floris Bruynooghe.  This also works well together with
>> pytest-timeout by the same author: When one or more test functions hang
>> or crash, the overall test run will still complete and report about the
>> incidents.  See the changelog below for more changes and the pypi
>> project page for what pytest-xdist offers in general:
>>
>>     https://pypi.python.org/pypi/pytest-xdist/
>>
>> Thanks also to an undisclosed company who partly funded the work
>> and to Andreas Pelme for contributing analysis of a fixture caching
>> failure including a test.
>>
>> best,
>> Holger Krekel
>>
>>
>> 1.11
>> -------------------------
>>
>> - fix pytest/xdist issue485 (also depends on py-1.4.22):
>>   attach stdout/stderr on --boxed processes that die.
>>
>> - fix pytest/xdist issue503: make sure that a node has usually
>>   two items to execute to avoid scoped fixtures to be torn down
>>   pre-maturely (fixture teardown/setup is "nextitem" sensitive).
>>   Thanks to Andreas Pelme for bug analysis and failing test.
>>
>> - restart crashed nodes by internally refactoring setup handling
>>   of nodes.  Also includes better code documentation.
>>   Many thanks to Floris Bruynooghe for the complete PR.
>>
>> _______________________________________________
>> Pytest-dev mailing list
>> Pytest-dev at python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>
>
>
>
> --
> Anatoly Bubenkov
>



-- 
Anatoly Bubenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140918/23015305/attachment.html>

From holger at merlinux.eu  Thu Sep 18 20:31:51 2014
From: holger at merlinux.eu (holger krekel)
Date: Thu, 18 Sep 2014 18:31:51 +0000
Subject: [pytest-dev] pytest-xdist-1.11: restarting crash nodes,
 fixture cache fix
In-Reply-To: <CACTnz+GicEjqowQg_-8GpLGFEVDdCFbNgHq+7DXxaEQTshjUKg@mail.gmail.com>
References: <20140918182152.GK3692@merlinux.eu>
 <CACTnz+GsmJ8uTbgANqgddskTDHc8vB80aUBEQVtAVXaQxnsYSQ@mail.gmail.com>
 <CACTnz+GicEjqowQg_-8GpLGFEVDdCFbNgHq+7DXxaEQTshjUKg@mail.gmail.com>
Message-ID: <20140918183151.GM3692@merlinux.eu>

On Thu, Sep 18, 2014 at 20:24 +0200, Anatoly Bubenkov wrote:
> so, this is again guaranteed that there will be only one session per test
> run on any test slave?

there is always one session object only but i think you are asking if a
session-scoped fixture will only be instantiated once per testing
subprocess, right?  In general this should be the case if i am not missing
something (when you use a test randomization plugin, then it's probably
not the case).

best,
holger 

> On 18 September 2014 20:23, Anatoly Bubenkov <bubenkoff at gmail.com> wrote:
> 
> > Great!
> > thanks a lot everyone involved
> >
> > On 18 September 2014 20:21, holger krekel <holger at merlinux.eu> wrote:
> >
> >>
> >> I just released pytest-xdist-1.11, the distributed testing plugin for
> >> pytest.
> >> It introduces automatic restarting of crashed nodes, courtesy of a
> >> complete PR from Floris Bruynooghe.  This also works well together with
> >> pytest-timeout by the same author: When one or more test functions hang
> >> or crash, the overall test run will still complete and report about the
> >> incidents.  See the changelog below for more changes and the pypi
> >> project page for what pytest-xdist offers in general:
> >>
> >>     https://pypi.python.org/pypi/pytest-xdist/
> >>
> >> Thanks also to an undisclosed company who partly funded the work
> >> and to Andreas Pelme for contributing analysis of a fixture caching
> >> failure including a test.
> >>
> >> best,
> >> Holger Krekel
> >>
> >>
> >> 1.11
> >> -------------------------
> >>
> >> - fix pytest/xdist issue485 (also depends on py-1.4.22):
> >>   attach stdout/stderr on --boxed processes that die.
> >>
> >> - fix pytest/xdist issue503: make sure that a node has usually
> >>   two items to execute to avoid scoped fixtures to be torn down
> >>   pre-maturely (fixture teardown/setup is "nextitem" sensitive).
> >>   Thanks to Andreas Pelme for bug analysis and failing test.
> >>
> >> - restart crashed nodes by internally refactoring setup handling
> >>   of nodes.  Also includes better code documentation.
> >>   Many thanks to Floris Bruynooghe for the complete PR.
> >>
> >> _______________________________________________
> >> Pytest-dev mailing list
> >> Pytest-dev at python.org
> >> https://mail.python.org/mailman/listinfo/pytest-dev
> >>
> >
> >
> >
> > --
> > Anatoly Bubenkov
> >
> 
> 
> 
> -- 
> Anatoly Bubenkov

From bubenkoff at gmail.com  Thu Sep 18 20:35:59 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Thu, 18 Sep 2014 20:35:59 +0200
Subject: [pytest-dev] pytest-xdist-1.11: restarting crash nodes,
 fixture cache fix
In-Reply-To: <20140918183151.GM3692@merlinux.eu>
References: <20140918182152.GK3692@merlinux.eu>
 <CACTnz+GsmJ8uTbgANqgddskTDHc8vB80aUBEQVtAVXaQxnsYSQ@mail.gmail.com>
 <CACTnz+GicEjqowQg_-8GpLGFEVDdCFbNgHq+7DXxaEQTshjUKg@mail.gmail.com>
 <20140918183151.GM3692@merlinux.eu>
Message-ID: <CACTnz+E2SyKUPX_bp_eTJY4JWiiL_p58YNZYzG-2WJ1CP6ZShQ@mail.gmail.com>

yes per testing subprocess, as i've already asked in the comments section
on the paylogic developer portal, im waiting for your confirmation that's
NOT by design that we were getting multiple test sessions per test
subprocess
so i'll need to fix the article then
BTW: now im reading the code again, it looks like even with randomization
plugin it should not matter?

On 18 September 2014 20:31, holger krekel <holger at merlinux.eu> wrote:

> On Thu, Sep 18, 2014 at 20:24 +0200, Anatoly Bubenkov wrote:
> > so, this is again guaranteed that there will be only one session per test
> > run on any test slave?
>
> there is always one session object only but i think you are asking if a
> session-scoped fixture will only be instantiated once per testing
> subprocess, right?  In general this should be the case if i am not missing
> something (when you use a test randomization plugin, then it's probably
> not the case).
>
> best,
> holger
>
> > On 18 September 2014 20:23, Anatoly Bubenkov <bubenkoff at gmail.com>
> wrote:
> >
> > > Great!
> > > thanks a lot everyone involved
> > >
> > > On 18 September 2014 20:21, holger krekel <holger at merlinux.eu> wrote:
> > >
> > >>
> > >> I just released pytest-xdist-1.11, the distributed testing plugin for
> > >> pytest.
> > >> It introduces automatic restarting of crashed nodes, courtesy of a
> > >> complete PR from Floris Bruynooghe.  This also works well together
> with
> > >> pytest-timeout by the same author: When one or more test functions
> hang
> > >> or crash, the overall test run will still complete and report about
> the
> > >> incidents.  See the changelog below for more changes and the pypi
> > >> project page for what pytest-xdist offers in general:
> > >>
> > >>     https://pypi.python.org/pypi/pytest-xdist/
> > >>
> > >> Thanks also to an undisclosed company who partly funded the work
> > >> and to Andreas Pelme for contributing analysis of a fixture caching
> > >> failure including a test.
> > >>
> > >> best,
> > >> Holger Krekel
> > >>
> > >>
> > >> 1.11
> > >> -------------------------
> > >>
> > >> - fix pytest/xdist issue485 (also depends on py-1.4.22):
> > >>   attach stdout/stderr on --boxed processes that die.
> > >>
> > >> - fix pytest/xdist issue503: make sure that a node has usually
> > >>   two items to execute to avoid scoped fixtures to be torn down
> > >>   pre-maturely (fixture teardown/setup is "nextitem" sensitive).
> > >>   Thanks to Andreas Pelme for bug analysis and failing test.
> > >>
> > >> - restart crashed nodes by internally refactoring setup handling
> > >>   of nodes.  Also includes better code documentation.
> > >>   Many thanks to Floris Bruynooghe for the complete PR.
> > >>
> > >> _______________________________________________
> > >> Pytest-dev mailing list
> > >> Pytest-dev at python.org
> > >> https://mail.python.org/mailman/listinfo/pytest-dev
> > >>
> > >
> > >
> > >
> > > --
> > > Anatoly Bubenkov
> > >
> >
> >
> >
> > --
> > Anatoly Bubenkov
>



-- 
Anatoly Bubenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140918/a9e0ae65/attachment.html>

From holger at merlinux.eu  Thu Sep 18 20:46:00 2014
From: holger at merlinux.eu (holger krekel)
Date: Thu, 18 Sep 2014 18:46:00 +0000
Subject: [pytest-dev] pytest-xdist-1.11: restarting crash nodes,
 fixture cache fix
In-Reply-To: <CACTnz+E2SyKUPX_bp_eTJY4JWiiL_p58YNZYzG-2WJ1CP6ZShQ@mail.gmail.com>
References: <20140918182152.GK3692@merlinux.eu>
 <CACTnz+GsmJ8uTbgANqgddskTDHc8vB80aUBEQVtAVXaQxnsYSQ@mail.gmail.com>
 <CACTnz+GicEjqowQg_-8GpLGFEVDdCFbNgHq+7DXxaEQTshjUKg@mail.gmail.com>
 <20140918183151.GM3692@merlinux.eu>
 <CACTnz+E2SyKUPX_bp_eTJY4JWiiL_p58YNZYzG-2WJ1CP6ZShQ@mail.gmail.com>
Message-ID: <20140918184600.GN3692@merlinux.eu>

On Thu, Sep 18, 2014 at 20:35 +0200, Anatoly Bubenkov wrote:
> yes per testing subprocess, as i've already asked in the comments section
> on the paylogic developer portal, im waiting for your confirmation that's
> NOT by design that we were getting multiple test sessions per test
> subprocess
> so i'll need to fix the article then

yes, it's not by design.  It was more an implementation incident.

> BTW: now im reading the code again, it looks like even with randomization
> plugin it should not matter?

pytest relies on the following property of test collections: if a test
at index I1 uses a session-scoped fixture X and at an index I2>I1 X is not
used than for any I3>I2 X will not be used, either.  If this is not
true for any given testing process then the fixture will be torn down
and setup again (at I3).  pytest groups tests so in general this property
is true (see here:
https://pytest.org/latest/fixture.html#automatic-grouping-of-tests-by-fixture-instances for how it groups).

If you have multiple parametrized session-scoped fixtures (not very common)
or item randomization the above property is likely not true but that already
is true then for single-process execution.

best,
holger

> On 18 September 2014 20:31, holger krekel <holger at merlinux.eu> wrote:
> 
> > On Thu, Sep 18, 2014 at 20:24 +0200, Anatoly Bubenkov wrote:
> > > so, this is again guaranteed that there will be only one session per test
> > > run on any test slave?
> >
> > there is always one session object only but i think you are asking if a
> > session-scoped fixture will only be instantiated once per testing
> > subprocess, right?  In general this should be the case if i am not missing
> > something (when you use a test randomization plugin, then it's probably
> > not the case).
> >
> > best,
> > holger
> >
> > > On 18 September 2014 20:23, Anatoly Bubenkov <bubenkoff at gmail.com>
> > wrote:
> > >
> > > > Great!
> > > > thanks a lot everyone involved
> > > >
> > > > On 18 September 2014 20:21, holger krekel <holger at merlinux.eu> wrote:
> > > >
> > > >>
> > > >> I just released pytest-xdist-1.11, the distributed testing plugin for
> > > >> pytest.
> > > >> It introduces automatic restarting of crashed nodes, courtesy of a
> > > >> complete PR from Floris Bruynooghe.  This also works well together
> > with
> > > >> pytest-timeout by the same author: When one or more test functions
> > hang
> > > >> or crash, the overall test run will still complete and report about
> > the
> > > >> incidents.  See the changelog below for more changes and the pypi
> > > >> project page for what pytest-xdist offers in general:
> > > >>
> > > >>     https://pypi.python.org/pypi/pytest-xdist/
> > > >>
> > > >> Thanks also to an undisclosed company who partly funded the work
> > > >> and to Andreas Pelme for contributing analysis of a fixture caching
> > > >> failure including a test.
> > > >>
> > > >> best,
> > > >> Holger Krekel
> > > >>
> > > >>
> > > >> 1.11
> > > >> -------------------------
> > > >>
> > > >> - fix pytest/xdist issue485 (also depends on py-1.4.22):
> > > >>   attach stdout/stderr on --boxed processes that die.
> > > >>
> > > >> - fix pytest/xdist issue503: make sure that a node has usually
> > > >>   two items to execute to avoid scoped fixtures to be torn down
> > > >>   pre-maturely (fixture teardown/setup is "nextitem" sensitive).
> > > >>   Thanks to Andreas Pelme for bug analysis and failing test.
> > > >>
> > > >> - restart crashed nodes by internally refactoring setup handling
> > > >>   of nodes.  Also includes better code documentation.
> > > >>   Many thanks to Floris Bruynooghe for the complete PR.
> > > >>
> > > >> _______________________________________________
> > > >> Pytest-dev mailing list
> > > >> Pytest-dev at python.org
> > > >> https://mail.python.org/mailman/listinfo/pytest-dev
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Anatoly Bubenkov
> > > >
> > >
> > >
> > >
> > > --
> > > Anatoly Bubenkov
> >
> 
> 
> 
> -- 
> Anatoly Bubenkov

From bubenkoff at gmail.com  Thu Sep 18 20:51:53 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Thu, 18 Sep 2014 20:51:53 +0200
Subject: [pytest-dev] pytest-xdist-1.11: restarting crash nodes,
 fixture cache fix
In-Reply-To: <20140918184600.GN3692@merlinux.eu>
References: <20140918182152.GK3692@merlinux.eu>
 <CACTnz+GsmJ8uTbgANqgddskTDHc8vB80aUBEQVtAVXaQxnsYSQ@mail.gmail.com>
 <CACTnz+GicEjqowQg_-8GpLGFEVDdCFbNgHq+7DXxaEQTshjUKg@mail.gmail.com>
 <20140918183151.GM3692@merlinux.eu>
 <CACTnz+E2SyKUPX_bp_eTJY4JWiiL_p58YNZYzG-2WJ1CP6ZShQ@mail.gmail.com>
 <20140918184600.GN3692@merlinux.eu>
Message-ID: <CACTnz+FMHdUdmSQ1nztpuAGX6ybOkXU6oXsD43fcvvk0HTL56w@mail.gmail.com>

hmm, but that grouping is not important for session scoped fixtures, right?
i mean, what's the sense of tearing down the session-scoped fixture, even
if most likely it will be not used by any test, earlier than the end of the
session?
it should be ok for that fixture to live till the end of the session, and
then any randomization should not matter
i agree that for modules and classes grouping is nice, though


On 18 September 2014 20:46, holger krekel <holger at merlinux.eu> wrote:

> On Thu, Sep 18, 2014 at 20:35 +0200, Anatoly Bubenkov wrote:
> > yes per testing subprocess, as i've already asked in the comments section
> > on the paylogic developer portal, im waiting for your confirmation that's
> > NOT by design that we were getting multiple test sessions per test
> > subprocess
> > so i'll need to fix the article then
>
> yes, it's not by design.  It was more an implementation incident.
>
> > BTW: now im reading the code again, it looks like even with randomization
> > plugin it should not matter?
>
> pytest relies on the following property of test collections: if a test
> at index I1 uses a session-scoped fixture X and at an index I2>I1 X is not
> used than for any I3>I2 X will not be used, either.  If this is not
> true for any given testing process then the fixture will be torn down
> and setup again (at I3).  pytest groups tests so in general this property
> is true (see here:
>
> https://pytest.org/latest/fixture.html#automatic-grouping-of-tests-by-fixture-instances
> for how it groups).
>
> If you have multiple parametrized session-scoped fixtures (not very common)
> or item randomization the above property is likely not true but that
> already
> is true then for single-process execution.
>
> best,
> holger
>
> > On 18 September 2014 20:31, holger krekel <holger at merlinux.eu> wrote:
> >
> > > On Thu, Sep 18, 2014 at 20:24 +0200, Anatoly Bubenkov wrote:
> > > > so, this is again guaranteed that there will be only one session per
> test
> > > > run on any test slave?
> > >
> > > there is always one session object only but i think you are asking if a
> > > session-scoped fixture will only be instantiated once per testing
> > > subprocess, right?  In general this should be the case if i am not
> missing
> > > something (when you use a test randomization plugin, then it's probably
> > > not the case).
> > >
> > > best,
> > > holger
> > >
> > > > On 18 September 2014 20:23, Anatoly Bubenkov <bubenkoff at gmail.com>
> > > wrote:
> > > >
> > > > > Great!
> > > > > thanks a lot everyone involved
> > > > >
> > > > > On 18 September 2014 20:21, holger krekel <holger at merlinux.eu>
> wrote:
> > > > >
> > > > >>
> > > > >> I just released pytest-xdist-1.11, the distributed testing plugin
> for
> > > > >> pytest.
> > > > >> It introduces automatic restarting of crashed nodes, courtesy of a
> > > > >> complete PR from Floris Bruynooghe.  This also works well together
> > > with
> > > > >> pytest-timeout by the same author: When one or more test functions
> > > hang
> > > > >> or crash, the overall test run will still complete and report
> about
> > > the
> > > > >> incidents.  See the changelog below for more changes and the pypi
> > > > >> project page for what pytest-xdist offers in general:
> > > > >>
> > > > >>     https://pypi.python.org/pypi/pytest-xdist/
> > > > >>
> > > > >> Thanks also to an undisclosed company who partly funded the work
> > > > >> and to Andreas Pelme for contributing analysis of a fixture
> caching
> > > > >> failure including a test.
> > > > >>
> > > > >> best,
> > > > >> Holger Krekel
> > > > >>
> > > > >>
> > > > >> 1.11
> > > > >> -------------------------
> > > > >>
> > > > >> - fix pytest/xdist issue485 (also depends on py-1.4.22):
> > > > >>   attach stdout/stderr on --boxed processes that die.
> > > > >>
> > > > >> - fix pytest/xdist issue503: make sure that a node has usually
> > > > >>   two items to execute to avoid scoped fixtures to be torn down
> > > > >>   pre-maturely (fixture teardown/setup is "nextitem" sensitive).
> > > > >>   Thanks to Andreas Pelme for bug analysis and failing test.
> > > > >>
> > > > >> - restart crashed nodes by internally refactoring setup handling
> > > > >>   of nodes.  Also includes better code documentation.
> > > > >>   Many thanks to Floris Bruynooghe for the complete PR.
> > > > >>
> > > > >> _______________________________________________
> > > > >> Pytest-dev mailing list
> > > > >> Pytest-dev at python.org
> > > > >> https://mail.python.org/mailman/listinfo/pytest-dev
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Anatoly Bubenkov
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Anatoly Bubenkov
> > >
> >
> >
> >
> > --
> > Anatoly Bubenkov
>



-- 
Anatoly Bubenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140918/913813a9/attachment-0001.html>

From holger at merlinux.eu  Thu Sep 18 20:56:24 2014
From: holger at merlinux.eu (holger krekel)
Date: Thu, 18 Sep 2014 18:56:24 +0000
Subject: [pytest-dev] pytest-xdist-1.11: restarting crash nodes,
 fixture cache fix
In-Reply-To: <CACTnz+FMHdUdmSQ1nztpuAGX6ybOkXU6oXsD43fcvvk0HTL56w@mail.gmail.com>
References: <20140918182152.GK3692@merlinux.eu>
 <CACTnz+GsmJ8uTbgANqgddskTDHc8vB80aUBEQVtAVXaQxnsYSQ@mail.gmail.com>
 <CACTnz+GicEjqowQg_-8GpLGFEVDdCFbNgHq+7DXxaEQTshjUKg@mail.gmail.com>
 <20140918183151.GM3692@merlinux.eu>
 <CACTnz+E2SyKUPX_bp_eTJY4JWiiL_p58YNZYzG-2WJ1CP6ZShQ@mail.gmail.com>
 <20140918184600.GN3692@merlinux.eu>
 <CACTnz+FMHdUdmSQ1nztpuAGX6ybOkXU6oXsD43fcvvk0HTL56w@mail.gmail.com>
Message-ID: <20140918185624.GP3692@merlinux.eu>

On Thu, Sep 18, 2014 at 20:51 +0200, Anatoly Bubenkov wrote:
> hmm, but that grouping is not important for session scoped fixtures, right?
> i mean, what's the sense of tearing down the session-scoped fixture, even
> if most likely it will be not used by any test, earlier than the end of the
> session?

Parametrized session-scoped fixtures, for example, may depend on being torn
down, not all be active at the same time.  In any case, it's part of a
general scheme to teardown fixtures as early as possible, not as late as
possible.  We can discuss/play with that and introduce an option which
prohibits it, possibly.

best,
holger

P.S: i bet you are using gmail, right? (because of your top-level 
posting style -- i often prefer inlined comments because it allows to
get statements in context).

> it should be ok for that fixture to live till the end of the session, and
> then any randomization should not matter
> i agree that for modules and classes grouping is nice, though
> 
> 
> On 18 September 2014 20:46, holger krekel <holger at merlinux.eu> wrote:
> 
> > On Thu, Sep 18, 2014 at 20:35 +0200, Anatoly Bubenkov wrote:
> > > yes per testing subprocess, as i've already asked in the comments section
> > > on the paylogic developer portal, im waiting for your confirmation that's
> > > NOT by design that we were getting multiple test sessions per test
> > > subprocess
> > > so i'll need to fix the article then
> >
> > yes, it's not by design.  It was more an implementation incident.
> >
> > > BTW: now im reading the code again, it looks like even with randomization
> > > plugin it should not matter?
> >
> > pytest relies on the following property of test collections: if a test
> > at index I1 uses a session-scoped fixture X and at an index I2>I1 X is not
> > used than for any I3>I2 X will not be used, either.  If this is not
> > true for any given testing process then the fixture will be torn down
> > and setup again (at I3).  pytest groups tests so in general this property
> > is true (see here:
> >
> > https://pytest.org/latest/fixture.html#automatic-grouping-of-tests-by-fixture-instances
> > for how it groups).
> >
> > If you have multiple parametrized session-scoped fixtures (not very common)
> > or item randomization the above property is likely not true but that
> > already
> > is true then for single-process execution.
> >
> > best,
> > holger
> >
> > > On 18 September 2014 20:31, holger krekel <holger at merlinux.eu> wrote:
> > >
> > > > On Thu, Sep 18, 2014 at 20:24 +0200, Anatoly Bubenkov wrote:
> > > > > so, this is again guaranteed that there will be only one session per
> > test
> > > > > run on any test slave?
> > > >
> > > > there is always one session object only but i think you are asking if a
> > > > session-scoped fixture will only be instantiated once per testing
> > > > subprocess, right?  In general this should be the case if i am not
> > missing
> > > > something (when you use a test randomization plugin, then it's probably
> > > > not the case).
> > > >
> > > > best,
> > > > holger
> > > >
> > > > > On 18 September 2014 20:23, Anatoly Bubenkov <bubenkoff at gmail.com>
> > > > wrote:
> > > > >
> > > > > > Great!
> > > > > > thanks a lot everyone involved
> > > > > >
> > > > > > On 18 September 2014 20:21, holger krekel <holger at merlinux.eu>
> > wrote:
> > > > > >
> > > > > >>
> > > > > >> I just released pytest-xdist-1.11, the distributed testing plugin
> > for
> > > > > >> pytest.
> > > > > >> It introduces automatic restarting of crashed nodes, courtesy of a
> > > > > >> complete PR from Floris Bruynooghe.  This also works well together
> > > > with
> > > > > >> pytest-timeout by the same author: When one or more test functions
> > > > hang
> > > > > >> or crash, the overall test run will still complete and report
> > about
> > > > the
> > > > > >> incidents.  See the changelog below for more changes and the pypi
> > > > > >> project page for what pytest-xdist offers in general:
> > > > > >>
> > > > > >>     https://pypi.python.org/pypi/pytest-xdist/
> > > > > >>
> > > > > >> Thanks also to an undisclosed company who partly funded the work
> > > > > >> and to Andreas Pelme for contributing analysis of a fixture
> > caching
> > > > > >> failure including a test.
> > > > > >>
> > > > > >> best,
> > > > > >> Holger Krekel
> > > > > >>
> > > > > >>
> > > > > >> 1.11
> > > > > >> -------------------------
> > > > > >>
> > > > > >> - fix pytest/xdist issue485 (also depends on py-1.4.22):
> > > > > >>   attach stdout/stderr on --boxed processes that die.
> > > > > >>
> > > > > >> - fix pytest/xdist issue503: make sure that a node has usually
> > > > > >>   two items to execute to avoid scoped fixtures to be torn down
> > > > > >>   pre-maturely (fixture teardown/setup is "nextitem" sensitive).
> > > > > >>   Thanks to Andreas Pelme for bug analysis and failing test.
> > > > > >>
> > > > > >> - restart crashed nodes by internally refactoring setup handling
> > > > > >>   of nodes.  Also includes better code documentation.
> > > > > >>   Many thanks to Floris Bruynooghe for the complete PR.
> > > > > >>
> > > > > >> _______________________________________________
> > > > > >> Pytest-dev mailing list
> > > > > >> Pytest-dev at python.org
> > > > > >> https://mail.python.org/mailman/listinfo/pytest-dev
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Anatoly Bubenkov
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Anatoly Bubenkov
> > > >
> > >
> > >
> > >
> > > --
> > > Anatoly Bubenkov
> >
> 
> 
> 
> -- 
> Anatoly Bubenkov

From bubenkoff at gmail.com  Thu Sep 18 21:00:36 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Thu, 18 Sep 2014 21:00:36 +0200
Subject: [pytest-dev] pytest-xdist-1.11: restarting crash nodes,
 fixture cache fix
In-Reply-To: <20140918185624.GP3692@merlinux.eu>
References: <20140918182152.GK3692@merlinux.eu>
 <CACTnz+GsmJ8uTbgANqgddskTDHc8vB80aUBEQVtAVXaQxnsYSQ@mail.gmail.com>
 <CACTnz+GicEjqowQg_-8GpLGFEVDdCFbNgHq+7DXxaEQTshjUKg@mail.gmail.com>
 <20140918183151.GM3692@merlinux.eu>
 <CACTnz+E2SyKUPX_bp_eTJY4JWiiL_p58YNZYzG-2WJ1CP6ZShQ@mail.gmail.com>
 <20140918184600.GN3692@merlinux.eu>
 <CACTnz+FMHdUdmSQ1nztpuAGX6ybOkXU6oXsD43fcvvk0HTL56w@mail.gmail.com>
 <20140918185624.GP3692@merlinux.eu>
Message-ID: <CACTnz+GujFRuP2u_wTSSengB5Xo9Ehy1fBp0BhqWjdk4TpPPWA@mail.gmail.com>

On 18 September 2014 20:56, holger krekel <holger at merlinux.eu> wrote:

> On Thu, Sep 18, 2014 at 20:51 +0200, Anatoly Bubenkov wrote:
> > hmm, but that grouping is not important for session scoped fixtures,
> right?
> > i mean, what's the sense of tearing down the session-scoped fixture, even
> > if most likely it will be not used by any test, earlier than the end of
> the
> > session?
>
> Parametrized session-scoped fixtures, for example, may depend on being torn
> down, not all be active at the same time.  In any case, it's part of a
> general scheme to teardown fixtures as early as possible, not as late as
> possible.  We can discuss/play with that and introduce an option which
> prohibits it, possibly.
>
> ok i see now a bit more, so, the solution, proposed in an article is still
actual, because there's no strict guarantee
but the reasoning was described in a wrong way - i'll fix that, thanks!


> best,
> holger
>
> P.S: i bet you are using gmail, right? (because of your top-level
> posting style -- i often prefer inlined comments because it allows to
> get statements in context).
>
i liked that way earlier also, not anymore :)
but in pytest-dev at least i'll try to keep this style, np


>
> > it should be ok for that fixture to live till the end of the session, and
> > then any randomization should not matter
> > i agree that for modules and classes grouping is nice, though
> >
> >
> > On 18 September 2014 20:46, holger krekel <holger at merlinux.eu> wrote:
> >
> > > On Thu, Sep 18, 2014 at 20:35 +0200, Anatoly Bubenkov wrote:
> > > > yes per testing subprocess, as i've already asked in the comments
> section
> > > > on the paylogic developer portal, im waiting for your confirmation
> that's
> > > > NOT by design that we were getting multiple test sessions per test
> > > > subprocess
> > > > so i'll need to fix the article then
> > >
> > > yes, it's not by design.  It was more an implementation incident.
> > >
> > > > BTW: now im reading the code again, it looks like even with
> randomization
> > > > plugin it should not matter?
> > >
> > > pytest relies on the following property of test collections: if a test
> > > at index I1 uses a session-scoped fixture X and at an index I2>I1 X is
> not
> > > used than for any I3>I2 X will not be used, either.  If this is not
> > > true for any given testing process then the fixture will be torn down
> > > and setup again (at I3).  pytest groups tests so in general this
> property
> > > is true (see here:
> > >
> > >
> https://pytest.org/latest/fixture.html#automatic-grouping-of-tests-by-fixture-instances
> > > for how it groups).
> > >
> > > If you have multiple parametrized session-scoped fixtures (not very
> common)
> > > or item randomization the above property is likely not true but that
> > > already
> > > is true then for single-process execution.
> > >
> > > best,
> > > holger
> > >
> > > > On 18 September 2014 20:31, holger krekel <holger at merlinux.eu>
> wrote:
> > > >
> > > > > On Thu, Sep 18, 2014 at 20:24 +0200, Anatoly Bubenkov wrote:
> > > > > > so, this is again guaranteed that there will be only one session
> per
> > > test
> > > > > > run on any test slave?
> > > > >
> > > > > there is always one session object only but i think you are asking
> if a
> > > > > session-scoped fixture will only be instantiated once per testing
> > > > > subprocess, right?  In general this should be the case if i am not
> > > missing
> > > > > something (when you use a test randomization plugin, then it's
> probably
> > > > > not the case).
> > > > >
> > > > > best,
> > > > > holger
> > > > >
> > > > > > On 18 September 2014 20:23, Anatoly Bubenkov <
> bubenkoff at gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > Great!
> > > > > > > thanks a lot everyone involved
> > > > > > >
> > > > > > > On 18 September 2014 20:21, holger krekel <holger at merlinux.eu>
> > > wrote:
> > > > > > >
> > > > > > >>
> > > > > > >> I just released pytest-xdist-1.11, the distributed testing
> plugin
> > > for
> > > > > > >> pytest.
> > > > > > >> It introduces automatic restarting of crashed nodes, courtesy
> of a
> > > > > > >> complete PR from Floris Bruynooghe.  This also works well
> together
> > > > > with
> > > > > > >> pytest-timeout by the same author: When one or more test
> functions
> > > > > hang
> > > > > > >> or crash, the overall test run will still complete and report
> > > about
> > > > > the
> > > > > > >> incidents.  See the changelog below for more changes and the
> pypi
> > > > > > >> project page for what pytest-xdist offers in general:
> > > > > > >>
> > > > > > >>     https://pypi.python.org/pypi/pytest-xdist/
> > > > > > >>
> > > > > > >> Thanks also to an undisclosed company who partly funded the
> work
> > > > > > >> and to Andreas Pelme for contributing analysis of a fixture
> > > caching
> > > > > > >> failure including a test.
> > > > > > >>
> > > > > > >> best,
> > > > > > >> Holger Krekel
> > > > > > >>
> > > > > > >>
> > > > > > >> 1.11
> > > > > > >> -------------------------
> > > > > > >>
> > > > > > >> - fix pytest/xdist issue485 (also depends on py-1.4.22):
> > > > > > >>   attach stdout/stderr on --boxed processes that die.
> > > > > > >>
> > > > > > >> - fix pytest/xdist issue503: make sure that a node has usually
> > > > > > >>   two items to execute to avoid scoped fixtures to be torn
> down
> > > > > > >>   pre-maturely (fixture teardown/setup is "nextitem"
> sensitive).
> > > > > > >>   Thanks to Andreas Pelme for bug analysis and failing test.
> > > > > > >>
> > > > > > >> - restart crashed nodes by internally refactoring setup
> handling
> > > > > > >>   of nodes.  Also includes better code documentation.
> > > > > > >>   Many thanks to Floris Bruynooghe for the complete PR.
> > > > > > >>
> > > > > > >> _______________________________________________
> > > > > > >> Pytest-dev mailing list
> > > > > > >> Pytest-dev at python.org
> > > > > > >> https://mail.python.org/mailman/listinfo/pytest-dev
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Anatoly Bubenkov
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Anatoly Bubenkov
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Anatoly Bubenkov
> > >
> >
> >
> >
> > --
> > Anatoly Bubenkov
>



-- 
Anatoly Bubenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140918/fd8d1f65/attachment-0001.html>

From holger at merlinux.eu  Thu Sep 18 21:08:46 2014
From: holger at merlinux.eu (holger krekel)
Date: Thu, 18 Sep 2014 19:08:46 +0000
Subject: [pytest-dev] pytest-xdist-1.11: restarting crash nodes,
 fixture cache fix
In-Reply-To: <CACTnz+GujFRuP2u_wTSSengB5Xo9Ehy1fBp0BhqWjdk4TpPPWA@mail.gmail.com>
References: <20140918182152.GK3692@merlinux.eu>
 <CACTnz+GsmJ8uTbgANqgddskTDHc8vB80aUBEQVtAVXaQxnsYSQ@mail.gmail.com>
 <CACTnz+GicEjqowQg_-8GpLGFEVDdCFbNgHq+7DXxaEQTshjUKg@mail.gmail.com>
 <20140918183151.GM3692@merlinux.eu>
 <CACTnz+E2SyKUPX_bp_eTJY4JWiiL_p58YNZYzG-2WJ1CP6ZShQ@mail.gmail.com>
 <20140918184600.GN3692@merlinux.eu>
 <CACTnz+FMHdUdmSQ1nztpuAGX6ybOkXU6oXsD43fcvvk0HTL56w@mail.gmail.com>
 <20140918185624.GP3692@merlinux.eu>
 <CACTnz+GujFRuP2u_wTSSengB5Xo9Ehy1fBp0BhqWjdk4TpPPWA@mail.gmail.com>
Message-ID: <20140918190846.GQ3692@merlinux.eu>

On Thu, Sep 18, 2014 at 21:00 +0200, Anatoly Bubenkov wrote:
> On 18 September 2014 20:56, holger krekel <holger at merlinux.eu> wrote:
> 
> > On Thu, Sep 18, 2014 at 20:51 +0200, Anatoly Bubenkov wrote:
> > > hmm, but that grouping is not important for session scoped fixtures,
> > right?
> > > i mean, what's the sense of tearing down the session-scoped fixture, even
> > > if most likely it will be not used by any test, earlier than the end of
> > the
> > > session?
> >
> > Parametrized session-scoped fixtures, for example, may depend on being torn
> > down, not all be active at the same time.  In any case, it's part of a
> > general scheme to teardown fixtures as early as possible, not as late as
> > possible.  We can discuss/play with that and introduce an option which
> > prohibits it, possibly.
> >
> ok i see now a bit more, so, the solution, proposed in an article is still
> actual, because there's no strict guarantee
> but the reasoning was described in a wrong way - i'll fix that, thanks!

For others, the actual article is here:
http://developer.paylogic.com/articles/pytest-xdist-and-session-scoped-fixtures.html

I'd recommend to check if pytest-xdist-1.11 doesn't already solve the problem.

> > best,
> > holger
> >
> > P.S: i bet you are using gmail, right? (because of your top-level
> > posting style -- i often prefer inlined comments because it allows to
> > get statements in context).
> >
> i liked that way earlier also, not anymore :)
> but in pytest-dev at least i'll try to keep this style, np

Well, it allows to have discussions on more than one point more easily.
E.g. in this mail we are discussing two things and it's easy for
others to join the thread with my mail here and see what is being
discussed without having to reread the whole thread.

cheers,
holger



> 
> >
> > > it should be ok for that fixture to live till the end of the session, and
> > > then any randomization should not matter
> > > i agree that for modules and classes grouping is nice, though
> > >
> > >
> > > On 18 September 2014 20:46, holger krekel <holger at merlinux.eu> wrote:
> > >
> > > > On Thu, Sep 18, 2014 at 20:35 +0200, Anatoly Bubenkov wrote:
> > > > > yes per testing subprocess, as i've already asked in the comments
> > section
> > > > > on the paylogic developer portal, im waiting for your confirmation
> > that's
> > > > > NOT by design that we were getting multiple test sessions per test
> > > > > subprocess
> > > > > so i'll need to fix the article then
> > > >
> > > > yes, it's not by design.  It was more an implementation incident.
> > > >
> > > > > BTW: now im reading the code again, it looks like even with
> > randomization
> > > > > plugin it should not matter?
> > > >
> > > > pytest relies on the following property of test collections: if a test
> > > > at index I1 uses a session-scoped fixture X and at an index I2>I1 X is
> > not
> > > > used than for any I3>I2 X will not be used, either.  If this is not
> > > > true for any given testing process then the fixture will be torn down
> > > > and setup again (at I3).  pytest groups tests so in general this
> > property
> > > > is true (see here:
> > > >
> > > >
> > https://pytest.org/latest/fixture.html#automatic-grouping-of-tests-by-fixture-instances
> > > > for how it groups).
> > > >
> > > > If you have multiple parametrized session-scoped fixtures (not very
> > common)
> > > > or item randomization the above property is likely not true but that
> > > > already
> > > > is true then for single-process execution.
> > > >
> > > > best,
> > > > holger
> > > >
> > > > > On 18 September 2014 20:31, holger krekel <holger at merlinux.eu>
> > wrote:
> > > > >
> > > > > > On Thu, Sep 18, 2014 at 20:24 +0200, Anatoly Bubenkov wrote:
> > > > > > > so, this is again guaranteed that there will be only one session
> > per
> > > > test
> > > > > > > run on any test slave?
> > > > > >
> > > > > > there is always one session object only but i think you are asking
> > if a
> > > > > > session-scoped fixture will only be instantiated once per testing
> > > > > > subprocess, right?  In general this should be the case if i am not
> > > > missing
> > > > > > something (when you use a test randomization plugin, then it's
> > probably
> > > > > > not the case).
> > > > > >
> > > > > > best,
> > > > > > holger
> > > > > >
> > > > > > > On 18 September 2014 20:23, Anatoly Bubenkov <
> > bubenkoff at gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > Great!
> > > > > > > > thanks a lot everyone involved
> > > > > > > >
> > > > > > > > On 18 September 2014 20:21, holger krekel <holger at merlinux.eu>
> > > > wrote:
> > > > > > > >
> > > > > > > >>
> > > > > > > >> I just released pytest-xdist-1.11, the distributed testing
> > plugin
> > > > for
> > > > > > > >> pytest.
> > > > > > > >> It introduces automatic restarting of crashed nodes, courtesy
> > of a
> > > > > > > >> complete PR from Floris Bruynooghe.  This also works well
> > together
> > > > > > with
> > > > > > > >> pytest-timeout by the same author: When one or more test
> > functions
> > > > > > hang
> > > > > > > >> or crash, the overall test run will still complete and report
> > > > about
> > > > > > the
> > > > > > > >> incidents.  See the changelog below for more changes and the
> > pypi
> > > > > > > >> project page for what pytest-xdist offers in general:
> > > > > > > >>
> > > > > > > >>     https://pypi.python.org/pypi/pytest-xdist/
> > > > > > > >>
> > > > > > > >> Thanks also to an undisclosed company who partly funded the
> > work
> > > > > > > >> and to Andreas Pelme for contributing analysis of a fixture
> > > > caching
> > > > > > > >> failure including a test.
> > > > > > > >>
> > > > > > > >> best,
> > > > > > > >> Holger Krekel
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> 1.11
> > > > > > > >> -------------------------
> > > > > > > >>
> > > > > > > >> - fix pytest/xdist issue485 (also depends on py-1.4.22):
> > > > > > > >>   attach stdout/stderr on --boxed processes that die.
> > > > > > > >>
> > > > > > > >> - fix pytest/xdist issue503: make sure that a node has usually
> > > > > > > >>   two items to execute to avoid scoped fixtures to be torn
> > down
> > > > > > > >>   pre-maturely (fixture teardown/setup is "nextitem"
> > sensitive).
> > > > > > > >>   Thanks to Andreas Pelme for bug analysis and failing test.
> > > > > > > >>
> > > > > > > >> - restart crashed nodes by internally refactoring setup
> > handling
> > > > > > > >>   of nodes.  Also includes better code documentation.
> > > > > > > >>   Many thanks to Floris Bruynooghe for the complete PR.
> > > > > > > >>
> > > > > > > >> _______________________________________________
> > > > > > > >> Pytest-dev mailing list
> > > > > > > >> Pytest-dev at python.org
> > > > > > > >> https://mail.python.org/mailman/listinfo/pytest-dev
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Anatoly Bubenkov
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Anatoly Bubenkov
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Anatoly Bubenkov
> > > >
> > >
> > >
> > >
> > > --
> > > Anatoly Bubenkov
> >
> 
> 
> 
> -- 
> Anatoly Bubenkov

From flub at devork.be  Thu Sep 18 22:44:19 2014
From: flub at devork.be (Floris Bruynooghe)
Date: Thu, 18 Sep 2014 21:44:19 +0100
Subject: [pytest-dev] pytest-xdist-1.11: restarting crash nodes,
 fixture cache fix
In-Reply-To: <CAAWk_Dz5MCbCorvJ2K27+yH-+YhwOP+apviO-=vuXuCfkYrQhQ@mail.gmail.com>
References: <20140918182152.GK3692@merlinux.eu>
 <CACTnz+GsmJ8uTbgANqgddskTDHc8vB80aUBEQVtAVXaQxnsYSQ@mail.gmail.com>
 <CACTnz+GicEjqowQg_-8GpLGFEVDdCFbNgHq+7DXxaEQTshjUKg@mail.gmail.com>
 <20140918183151.GM3692@merlinux.eu>
 <CACTnz+E2SyKUPX_bp_eTJY4JWiiL_p58YNZYzG-2WJ1CP6ZShQ@mail.gmail.com>
 <20140918184600.GN3692@merlinux.eu>
 <CACTnz+FMHdUdmSQ1nztpuAGX6ybOkXU6oXsD43fcvvk0HTL56w@mail.gmail.com>
 <CAAWk_Dz5MCbCorvJ2K27+yH-+YhwOP+apviO-=vuXuCfkYrQhQ@mail.gmail.com>
Message-ID: <CAAWk_Dyo7WkAPWqp=e4q3_isiNSU5Gn1eBK0SLjxPxB_u+HVwQ@mail.gmail.com>

[Oops, lost the list on this reply - sorry]

On 18 September 2014 21:43, Floris Bruynooghe <flub at devork.be> wrote:
> On 18 September 2014 19:51, Anatoly Bubenkov <bubenkoff at gmail.com> wrote:
>> hmm, but that grouping is not important for session scoped fixtures, right?
>> i mean, what's the sense of tearing down the session-scoped fixture, even if
>> most likely it will be not used by any test, earlier than the end of the
>> session?
>
> I think you could subvert py.test's tear-fixtures-down-early by making
> your session scoped fixture an autouse fixture, that way all tests
> will need it to run and it won't be torn down early.  However only
> tests explicitly requesting the fixture will be bothered with it's
> existence and value.

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From bubenkoff at gmail.com  Fri Sep 19 08:56:58 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Fri, 19 Sep 2014 08:56:58 +0200
Subject: [pytest-dev] pytest-xdist-1.11: restarting crash nodes,
 fixture cache fix
In-Reply-To: <CAAWk_Dyo7WkAPWqp=e4q3_isiNSU5Gn1eBK0SLjxPxB_u+HVwQ@mail.gmail.com>
References: <20140918182152.GK3692@merlinux.eu>
 <CACTnz+GsmJ8uTbgANqgddskTDHc8vB80aUBEQVtAVXaQxnsYSQ@mail.gmail.com>
 <CACTnz+GicEjqowQg_-8GpLGFEVDdCFbNgHq+7DXxaEQTshjUKg@mail.gmail.com>
 <20140918183151.GM3692@merlinux.eu>
 <CACTnz+E2SyKUPX_bp_eTJY4JWiiL_p58YNZYzG-2WJ1CP6ZShQ@mail.gmail.com>
 <20140918184600.GN3692@merlinux.eu>
 <CACTnz+FMHdUdmSQ1nztpuAGX6ybOkXU6oXsD43fcvvk0HTL56w@mail.gmail.com>
 <CAAWk_Dz5MCbCorvJ2K27+yH-+YhwOP+apviO-=vuXuCfkYrQhQ@mail.gmail.com>
 <CAAWk_Dyo7WkAPWqp=e4q3_isiNSU5Gn1eBK0SLjxPxB_u+HVwQ@mail.gmail.com>
Message-ID: <CACTnz+FnesfCgg8P3oFdG0sPxy3Bs-JWVciCCmx3UDKs_8X8UA@mail.gmail.com>

On 18 September 2014 22:44, Floris Bruynooghe <flub at devork.be> wrote:

>
> > I think you could subvert py.test's tear-fixtures-down-early by making
> > your session scoped fixture an autouse fixture, that way all tests
> > will need it to run and it won't be torn down early.  However only
> > tests explicitly requesting the fixture will be bothered with it's
> > existence and value.
>

that's very nice idea, actually!
but with this approach we kinda eliminate the beauty of the dependency
injection
also imagine: we have 5 application fixtures, which are heavy to start
then we have distributed test run, where are groups of the tests using
mostly one application fixture per group
for certain test slave it will have no sense to set up all the application
fixtures, if this slave works on a set of tests including only one-two test
groups

-- 
Anatoly Bubenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140919/54a7c5b8/attachment.html>

From andreas at pelme.se  Fri Sep 19 09:06:48 2014
From: andreas at pelme.se (Andreas Pelme)
Date: Fri, 19 Sep 2014 09:06:48 +0200
Subject: [pytest-dev] pytest-xdist-1.11: restarting crash nodes,
	fixture cache fix
In-Reply-To: <20140918185624.GP3692@merlinux.eu>
References: <20140918182152.GK3692@merlinux.eu>
 <CACTnz+GsmJ8uTbgANqgddskTDHc8vB80aUBEQVtAVXaQxnsYSQ@mail.gmail.com>
 <CACTnz+GicEjqowQg_-8GpLGFEVDdCFbNgHq+7DXxaEQTshjUKg@mail.gmail.com>
 <20140918183151.GM3692@merlinux.eu>
 <CACTnz+E2SyKUPX_bp_eTJY4JWiiL_p58YNZYzG-2WJ1CP6ZShQ@mail.gmail.com>
 <20140918184600.GN3692@merlinux.eu>
 <CACTnz+FMHdUdmSQ1nztpuAGX6ybOkXU6oXsD43fcvvk0HTL56w@mail.gmail.com>
 <20140918185624.GP3692@merlinux.eu>
Message-ID: <87BF3B2A-B803-4FD5-88B8-195CDC806A0E@pelme.se>

Hi,

First: Thanks for the fixes and release, my test suite runs fine with the new version!


On 18 sep 2014, at 20:56, holger krekel <holger at merlinux.eu> wrote:
> On Thu, Sep 18, 2014 at 20:51 +0200, Anatoly Bubenkov wrote:
>> hmm, but that grouping is not important for session scoped fixtures, right?
>> i mean, what's the sense of tearing down the session-scoped fixture, even
>> if most likely it will be not used by any test, earlier than the end of the
>> session?
> 
> Parametrized session-scoped fixtures, for example, may depend on being torn
> down, not all be active at the same time.  In any case, it's part of a
> general scheme to teardown fixtures as early as possible, not as late as
> possible.  We can discuss/play with that and introduce an option which
> prohibits it, possibly.


I?d like an option/hint (in a sense similar to pytest.mark.trylast) to tell pytest to tear down fixtures as late as possible. Or a higher level scope than session, that is cached until the end of the entire test run.

I?ve was not aware of this situation until I hit issue 503, and have always assumed that session fixtures cannot be teared down more than once.

pytest-django?s internal fixtures and other fixtures I?ve written depends on having a single invocation for session fixtures. The teardown bugs in these fixtures can (and should) of course be fixed to work properly multiple times.

Even if these fixtures were correct, from a performance point of view, tearing down some of these fixtures is a big issue, since session fixtures are typically very slow in the first place.

Cheers,
Andreas


From holger at merlinux.eu  Fri Sep 19 09:52:31 2014
From: holger at merlinux.eu (holger krekel)
Date: Fri, 19 Sep 2014 07:52:31 +0000
Subject: [pytest-dev] pytest-xdist-1.11: restarting crash nodes,
 fixture cache fix
In-Reply-To: <87BF3B2A-B803-4FD5-88B8-195CDC806A0E@pelme.se>
References: <20140918182152.GK3692@merlinux.eu>
 <CACTnz+GsmJ8uTbgANqgddskTDHc8vB80aUBEQVtAVXaQxnsYSQ@mail.gmail.com>
 <CACTnz+GicEjqowQg_-8GpLGFEVDdCFbNgHq+7DXxaEQTshjUKg@mail.gmail.com>
 <20140918183151.GM3692@merlinux.eu>
 <CACTnz+E2SyKUPX_bp_eTJY4JWiiL_p58YNZYzG-2WJ1CP6ZShQ@mail.gmail.com>
 <20140918184600.GN3692@merlinux.eu>
 <CACTnz+FMHdUdmSQ1nztpuAGX6ybOkXU6oXsD43fcvvk0HTL56w@mail.gmail.com>
 <20140918185624.GP3692@merlinux.eu>
 <87BF3B2A-B803-4FD5-88B8-195CDC806A0E@pelme.se>
Message-ID: <20140919075231.GR3692@merlinux.eu>

Hi Andreas, all,

On Fri, Sep 19, 2014 at 09:06 +0200, Andreas Pelme wrote:
> Hi,
> 
> First: Thanks for the fixes and release, my test suite runs fine with the new version!
> 
> On 18 sep 2014, at 20:56, holger krekel <holger at merlinux.eu> wrote:
> > On Thu, Sep 18, 2014 at 20:51 +0200, Anatoly Bubenkov wrote:
> >> hmm, but that grouping is not important for session scoped fixtures, right?
> >> i mean, what's the sense of tearing down the session-scoped fixture, even
> >> if most likely it will be not used by any test, earlier than the end of the
> >> session?
> > 
> > Parametrized session-scoped fixtures, for example, may depend on being torn
> > down, not all be active at the same time.  In any case, it's part of a
> > general scheme to teardown fixtures as early as possible, not as late as
> > possible.  We can discuss/play with that and introduce an option which
> > prohibits it, possibly.
> 
> 
> I?d like an option/hint (in a sense similar to pytest.mark.trylast) to tell pytest to tear down fixtures as late as possible. Or a higher level scope than session, that is cached until the end of the entire test run.

Interesting idea.  Maybe we could add something to the fixture decorator, e.g.:

    @pytest.fixture(scope="session", lateteardown=True)

> I?ve was not aware of this situation until I hit issue 503, and have always assumed that session fixtures cannot be teared down more than once.
> 
> pytest-django?s internal fixtures and other fixtures I?ve written depends on having a single invocation for session fixtures. The teardown bugs in these fixtures can (and should) of course be fixed to work properly multiple times.
> 
> Even if these fixtures were correct, from a performance point of view, tearing down some of these fixtures is a big issue, since session fixtures are typically very slow in the first place.

I'd like to see if with pytest-xdist-1.11 there still is a problem.
Let's try to make everything work by default without adding new options.
We might just allow non-parametrized session fixtures to survive
until the end of a session (or rather a process: i now think that
"session" should have been named "process" because it better avoids
misconceptions when things run distributed).  A "non parametrized
session fixture" means that it is itself not parametrized and none of
its fixture dependencies is, neither (recursive definition).  We should
be able to determine this property at collection time and thus postpone 
teardown accordingly.

I presume that with module and class scope people don't presume that
a fixture survives until the end of a process so eager teardown is less
of a problem, there, right?

best,
holger

From bubenkoff at gmail.com  Fri Sep 19 10:07:29 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Fri, 19 Sep 2014 10:07:29 +0200
Subject: [pytest-dev] pytest-xdist-1.11: restarting crash nodes,
 fixture cache fix
In-Reply-To: <20140919075231.GR3692@merlinux.eu>
References: <20140918182152.GK3692@merlinux.eu>
 <CACTnz+GsmJ8uTbgANqgddskTDHc8vB80aUBEQVtAVXaQxnsYSQ@mail.gmail.com>
 <CACTnz+GicEjqowQg_-8GpLGFEVDdCFbNgHq+7DXxaEQTshjUKg@mail.gmail.com>
 <20140918183151.GM3692@merlinux.eu>
 <CACTnz+E2SyKUPX_bp_eTJY4JWiiL_p58YNZYzG-2WJ1CP6ZShQ@mail.gmail.com>
 <20140918184600.GN3692@merlinux.eu>
 <CACTnz+FMHdUdmSQ1nztpuAGX6ybOkXU6oXsD43fcvvk0HTL56w@mail.gmail.com>
 <20140918185624.GP3692@merlinux.eu>
 <87BF3B2A-B803-4FD5-88B8-195CDC806A0E@pelme.se>
 <20140919075231.GR3692@merlinux.eu>
Message-ID: <CACTnz+GNcUtYgEEXSY7LeBsmmgBvY=9wnUamczisZW6SAGK1PQ@mail.gmail.com>

On 19 September 2014 09:52, holger krekel <holger at merlinux.eu> wrote:

> Hi Andreas, all,
>
> On Fri, Sep 19, 2014 at 09:06 +0200, Andreas Pelme wrote:
> > Hi,
> >
> > First: Thanks for the fixes and release, my test suite runs fine with
> the new version!
> >
> > On 18 sep 2014, at 20:56, holger krekel <holger at merlinux.eu> wrote:
> > > On Thu, Sep 18, 2014 at 20:51 +0200, Anatoly Bubenkov wrote:
> > >> hmm, but that grouping is not important for session scoped fixtures,
> right?
> > >> i mean, what's the sense of tearing down the session-scoped fixture,
> even
> > >> if most likely it will be not used by any test, earlier than the end
> of the
> > >> session?
> > >
> > > Parametrized session-scoped fixtures, for example, may depend on being
> torn
> > > down, not all be active at the same time.  In any case, it's part of a
> > > general scheme to teardown fixtures as early as possible, not as late
> as
> > > possible.  We can discuss/play with that and introduce an option which
> > > prohibits it, possibly.
> >
> >
> > I?d like an option/hint (in a sense similar to pytest.mark.trylast) to
> tell pytest to tear down fixtures as late as possible. Or a higher level
> scope than session, that is cached until the end of the entire test run.
>
> Interesting idea.  Maybe we could add something to the fixture decorator,
> e.g.:
>
>     @pytest.fixture(scope="session", lateteardown=True)
>
how about:
@pytest.fixture(scope="<scope>", teardown='<(early or demand (default)) |
(session or late, not sure)>')

the teardown 'session' will clearly tell the user when this fixture will be
teared down
'late' also works, but not so clear

teardown 'demand' clearly tells that it's teardown will depend on the
demand of the fixture from the tests
'early' - same as with 'late'


>
> > I?ve was not aware of this situation until I hit issue 503, and have
> always assumed that session fixtures cannot be teared down more than once.
> >
> > pytest-django?s internal fixtures and other fixtures I?ve written
> depends on having a single invocation for session fixtures. The teardown
> bugs in these fixtures can (and should) of course be fixed to work properly
> multiple times.
> >
> > Even if these fixtures were correct, from a performance point of view,
> tearing down some of these fixtures is a big issue, since session fixtures
> are typically very slow in the first place.
>
> I'd like to see if with pytest-xdist-1.11 there still is a problem.
> Let's try to make everything work by default without adding new options.
> We might just allow non-parametrized session fixtures to survive
> until the end of a session (or rather a process: i now think that
> "session" should have been named "process" because it better avoids
> misconceptions when things run distributed).  A "non parametrized
> session fixture" means that it is itself not parametrized and none of
> its fixture dependencies is, neither (recursive definition).  We should
> be able to determine this property at collection time and thus postpone
> teardown accordingly.
>
session is rather good name, because if it will be the process, a lot of
questions will arise why pytest has session everywhere internally :)
also sometimes it's probably needed to start multiple sessions, who knows?

>
> I presume that with module and class scope people don't presume that
> a fixture survives until the end of a process so eager teardown is less
> of a problem, there, right?
>
> agree


-- 
Anatoly Bubenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140919/4ea95154/attachment.html>

From andreas at pelme.se  Mon Sep 22 22:03:53 2014
From: andreas at pelme.se (Andreas Pelme)
Date: Mon, 22 Sep 2014 22:03:53 +0200
Subject: [pytest-dev] pytest-xdist-1.11: restarting crash nodes,
	fixture cache fix
In-Reply-To: <20140919075231.GR3692@merlinux.eu>
References: <20140918182152.GK3692@merlinux.eu>
 <CACTnz+GsmJ8uTbgANqgddskTDHc8vB80aUBEQVtAVXaQxnsYSQ@mail.gmail.com>
 <CACTnz+GicEjqowQg_-8GpLGFEVDdCFbNgHq+7DXxaEQTshjUKg@mail.gmail.com>
 <20140918183151.GM3692@merlinux.eu>
 <CACTnz+E2SyKUPX_bp_eTJY4JWiiL_p58YNZYzG-2WJ1CP6ZShQ@mail.gmail.com>
 <20140918184600.GN3692@merlinux.eu>
 <CACTnz+FMHdUdmSQ1nztpuAGX6ybOkXU6oXsD43fcvvk0HTL56w@mail.gmail.com>
 <20140918185624.GP3692@merlinux.eu>
 <87BF3B2A-B803-4FD5-88B8-195CDC806A0E@pelme.se>
 <20140919075231.GR3692@merlinux.eu>
Message-ID: <10088445-C88F-4221-9DDB-87FA4C1F71F8@pelme.se>

Hi Holger,

On 19 sep 2014, at 09:52, holger krekel <holger at merlinux.eu> wrote:
> I presume that with module and class scope people don't presume that
> a fixture survives until the end of a process so eager teardown is less
> of a problem, there, right?


I have not fully grasped how fixture teardown currently happens in pytest. To explore it, I came up with this example:

import pytest


@pytest.yield_fixture(scope='class')
def fix():
    print 'fixture setup'
    yield
    print 'fixture teardown'



class TestFoo():
    def test_a(self, fix):
        print 'test_a'

    def test_b(self):
        print 'test_b'

    def test_c(self, fix):
        print 'test_c'


It gives me the output (with the latest pytest from PyPI):

fixture setup
test_a
test_b
test_c
fixture teardown

I.e. even though test_b does not actively request the fixture, it is active during the test.

Is this even considered to be a bug or a feature? :-) This behavior may be considered a bug since it makes test suites brittle - if the fixture does not contain a value itself, it can probably be neglected to actually properly request the fixture, but test_b will still accidentally have ?fix? available. Bugs like this will only show itself when running a subset of the test suite (and with xdist!).

I would prefer (I think) if all fixtures where torn down when they are not requested (in my example, before test_b is run, to ensure test_b is only run with its own fixtures).

However, if all teardowns worked like this, the efficiency will be very bad since there will be a lot of teardowns. I think these fixtures that should be allowed to stay alive, should be explicitly declared like that, like the option to pytest.fixture() suggested earlier.

I think this makes sense regardless of whether the fixture is class, module or session scoped. Having different semantics depending on the scope would be confusing. Fixture authors must be aware and decide whether or not a fixture may accidentally be available to wrong tests. I have a hard time to see how we can solve this properly without a flag or some kind of distinction for this.

I am probably missing a lot of details here, what are your thoughts on this?

Cheers,
Andreas


From bubenkoff at gmail.com  Mon Sep 22 22:31:00 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Mon, 22 Sep 2014 22:31:00 +0200
Subject: [pytest-dev] pytest-xdist-1.11: restarting crash nodes,
 fixture cache fix
In-Reply-To: <10088445-C88F-4221-9DDB-87FA4C1F71F8@pelme.se>
References: <20140918182152.GK3692@merlinux.eu>
 <CACTnz+GsmJ8uTbgANqgddskTDHc8vB80aUBEQVtAVXaQxnsYSQ@mail.gmail.com>
 <CACTnz+GicEjqowQg_-8GpLGFEVDdCFbNgHq+7DXxaEQTshjUKg@mail.gmail.com>
 <20140918183151.GM3692@merlinux.eu>
 <CACTnz+E2SyKUPX_bp_eTJY4JWiiL_p58YNZYzG-2WJ1CP6ZShQ@mail.gmail.com>
 <20140918184600.GN3692@merlinux.eu>
 <CACTnz+FMHdUdmSQ1nztpuAGX6ybOkXU6oXsD43fcvvk0HTL56w@mail.gmail.com>
 <20140918185624.GP3692@merlinux.eu>
 <87BF3B2A-B803-4FD5-88B8-195CDC806A0E@pelme.se>
 <20140919075231.GR3692@merlinux.eu>
 <10088445-C88F-4221-9DDB-87FA4C1F71F8@pelme.se>
Message-ID: <CACTnz+F1mQ8FqX1PgTwVgkWkh66xQ9vw2T_TCWWMycdyTWb1TA@mail.gmail.com>

+1 for making tear downs consistent and clear for all the scopes
Having teardown argument solves it to me
On Sep 22, 2014 10:03 PM, "Andreas Pelme" <andreas at pelme.se> wrote:

> Hi Holger,
>
> On 19 sep 2014, at 09:52, holger krekel <holger at merlinux.eu> wrote:
> > I presume that with module and class scope people don't presume that
> > a fixture survives until the end of a process so eager teardown is less
> > of a problem, there, right?
>
>
> I have not fully grasped how fixture teardown currently happens in pytest.
> To explore it, I came up with this example:
>
> import pytest
>
>
> @pytest.yield_fixture(scope='class')
> def fix():
>     print 'fixture setup'
>     yield
>     print 'fixture teardown'
>
>
>
> class TestFoo():
>     def test_a(self, fix):
>         print 'test_a'
>
>     def test_b(self):
>         print 'test_b'
>
>     def test_c(self, fix):
>         print 'test_c'
>
>
> It gives me the output (with the latest pytest from PyPI):
>
> fixture setup
> test_a
> test_b
> test_c
> fixture teardown
>
> I.e. even though test_b does not actively request the fixture, it is
> active during the test.
>
> Is this even considered to be a bug or a feature? :-) This behavior may be
> considered a bug since it makes test suites brittle - if the fixture does
> not contain a value itself, it can probably be neglected to actually
> properly request the fixture, but test_b will still accidentally have ?fix?
> available. Bugs like this will only show itself when running a subset of
> the test suite (and with xdist!).
>
> I would prefer (I think) if all fixtures where torn down when they are not
> requested (in my example, before test_b is run, to ensure test_b is only
> run with its own fixtures).
>
> However, if all teardowns worked like this, the efficiency will be very
> bad since there will be a lot of teardowns. I think these fixtures that
> should be allowed to stay alive, should be explicitly declared like that,
> like the option to pytest.fixture() suggested earlier.
>
> I think this makes sense regardless of whether the fixture is class,
> module or session scoped. Having different semantics depending on the scope
> would be confusing. Fixture authors must be aware and decide whether or not
> a fixture may accidentally be available to wrong tests. I have a hard time
> to see how we can solve this properly without a flag or some kind of
> distinction for this.
>
> I am probably missing a lot of details here, what are your thoughts on
> this?
>
> Cheers,
> Andreas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140922/26c5fe6e/attachment.html>

From bubenkoff at gmail.com  Tue Sep 23 01:05:21 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Tue, 23 Sep 2014 01:05:21 +0200
Subject: [pytest-dev] pytest-xdist-1.11: restarting crash nodes,
 fixture cache fix
In-Reply-To: <CACTnz+F1mQ8FqX1PgTwVgkWkh66xQ9vw2T_TCWWMycdyTWb1TA@mail.gmail.com>
References: <20140918182152.GK3692@merlinux.eu>
 <CACTnz+GsmJ8uTbgANqgddskTDHc8vB80aUBEQVtAVXaQxnsYSQ@mail.gmail.com>
 <CACTnz+GicEjqowQg_-8GpLGFEVDdCFbNgHq+7DXxaEQTshjUKg@mail.gmail.com>
 <20140918183151.GM3692@merlinux.eu>
 <CACTnz+E2SyKUPX_bp_eTJY4JWiiL_p58YNZYzG-2WJ1CP6ZShQ@mail.gmail.com>
 <20140918184600.GN3692@merlinux.eu>
 <CACTnz+FMHdUdmSQ1nztpuAGX6ybOkXU6oXsD43fcvvk0HTL56w@mail.gmail.com>
 <20140918185624.GP3692@merlinux.eu>
 <87BF3B2A-B803-4FD5-88B8-195CDC806A0E@pelme.se>
 <20140919075231.GR3692@merlinux.eu>
 <10088445-C88F-4221-9DDB-87FA4C1F71F8@pelme.se>
 <CACTnz+F1mQ8FqX1PgTwVgkWkh66xQ9vw2T_TCWWMycdyTWb1TA@mail.gmail.com>
 <CACTnz+F1mQ8FqX1PgTwVgkWkh66xQ9vw2T_TCWWMycdyTWb1TA@mail.gmail.com>
Message-ID: <CACTnz+HNYxCC0yBAdO+kbNsHnTEFkPnw-TBtjTnA0ooMSjeffQ@mail.gmail.com>

well, then it contradicts with the grouping efforts Holger mentioned
but personally i do like the simplicity, which always works
so by removing the grouping we can solve real-life issue
BTW: what was the actual reason for the grouping efforts?

On 23 September 2014 00:54, Ronny Pfannschmidt <ich at ronnypfannschmidt.de>
wrote:

> The current semantic is teardown on leaving the scope, I don't think
> anything else makes more sense
>
> At least I'm not convinced usage dependent teardown is a good idea
>
> Sent from my android device.
>
>
> -----Original Message-----
> From: Anatoly Bubenkov <bubenkoff at gmail.com>
> To: Andreas Pelme <andreas at pelme.se>
> Cc: pytest-dev <pytest-dev at python.org>
> Sent: Mo., 22 Sep. 2014 22:31
> Subject: Re: [pytest-dev] pytest-xdist-1.11: restarting crash nodes,
> fixture cache fix
>
> +1 for making tear downs consistent and clear for all the scopes
> Having teardown argument solves it to me
> On Sep 22, 2014 10:03 PM, "Andreas Pelme" <andreas at pelme.se> wrote:
>
>> Hi Holger,
>>
>> On 19 sep 2014, at 09:52, holger krekel <holger at merlinux.eu> wrote:
>> > I presume that with module and class scope people don't presume that
>> > a fixture survives until the end of a process so eager teardown is less
>> > of a problem, there, right?
>>
>>
>> I have not fully grasped how fixture teardown currently happens in
>> pytest. To explore it, I came up with this example:
>>
>> import pytest
>>
>>
>> @pytest.yield_fixture(scope='class')
>> def fix():
>>     print 'fixture setup'
>>     yield
>>     print 'fixture teardown'
>>
>>
>>
>> class TestFoo():
>>     def test_a(self, fix):
>>         print 'test_a'
>>
>>     def test_b(self):
>>         print 'test_b'
>>
>>     def test_c(self, fix):
>>         print 'test_c'
>>
>>
>> It gives me the output (with the latest pytest from PyPI):
>>
>> fixture setup
>> test_a
>> test_b
>> test_c
>> fixture teardown
>>
>> I.e. even though test_b does not actively request the fixture, it is
>> active during the test.
>>
>> Is this even considered to be a bug or a feature? :-) This behavior may
>> be considered a bug since it makes test suites brittle - if the fixture
>> does not contain a value itself, it can probably be neglected to actually
>> properly request the fixture, but test_b will still accidentally have ?fix?
>> available. Bugs like this will only show itself when running a subset of
>> the test suite (and with xdist!).
>>
>> I would prefer (I think) if all fixtures where torn down when they are
>> not requested (in my example, before test_b is run, to ensure test_b is
>> only run with its own fixtures).
>>
>> However, if all teardowns worked like this, the efficiency will be very
>> bad since there will be a lot of teardowns. I think these fixtures that
>> should be allowed to stay alive, should be explicitly declared like that,
>> like the option to pytest.fixture() suggested earlier.
>>
>> I think this makes sense regardless of whether the fixture is class,
>> module or session scoped. Having different semantics depending on the scope
>> would be confusing. Fixture authors must be aware and decide whether or not
>> a fixture may accidentally be available to wrong tests. I have a hard time
>> to see how we can solve this properly without a flag or some kind of
>> distinction for this.
>>
>> I am probably missing a lot of details here, what are your thoughts on
>> this?
>>
>> Cheers,
>> Andreas
>>
>>


-- 
Anatoly Bubenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140923/dde163bf/attachment-0001.html>

From holger at merlinux.eu  Tue Sep 23 11:42:57 2014
From: holger at merlinux.eu (holger krekel)
Date: Tue, 23 Sep 2014 09:42:57 +0000
Subject: [pytest-dev] pytest-xdist-1.11: restarting crash nodes,
 fixture cache fix
In-Reply-To: <10088445-C88F-4221-9DDB-87FA4C1F71F8@pelme.se>
References: <CACTnz+GsmJ8uTbgANqgddskTDHc8vB80aUBEQVtAVXaQxnsYSQ@mail.gmail.com>
 <CACTnz+GicEjqowQg_-8GpLGFEVDdCFbNgHq+7DXxaEQTshjUKg@mail.gmail.com>
 <20140918183151.GM3692@merlinux.eu>
 <CACTnz+E2SyKUPX_bp_eTJY4JWiiL_p58YNZYzG-2WJ1CP6ZShQ@mail.gmail.com>
 <20140918184600.GN3692@merlinux.eu>
 <CACTnz+FMHdUdmSQ1nztpuAGX6ybOkXU6oXsD43fcvvk0HTL56w@mail.gmail.com>
 <20140918185624.GP3692@merlinux.eu>
 <87BF3B2A-B803-4FD5-88B8-195CDC806A0E@pelme.se>
 <20140919075231.GR3692@merlinux.eu>
 <10088445-C88F-4221-9DDB-87FA4C1F71F8@pelme.se>
Message-ID: <20140923094257.GF7954@merlinux.eu>

Hi Andreas,

On Mon, Sep 22, 2014 at 22:03 +0200, Andreas Pelme wrote:
> Hi Holger,
> 
> On 19 sep 2014, at 09:52, holger krekel <holger at merlinux.eu> wrote:
> > I presume that with module and class scope people don't presume that
> > a fixture survives until the end of a process so eager teardown is less
> > of a problem, there, right?
> 
> 
> I have not fully grasped how fixture teardown currently happens in pytest. To explore it, I came up with this example:
> 
> import pytest
> 
> 
> @pytest.yield_fixture(scope='class')
> def fix():
>     print 'fixture setup'
>     yield
>     print 'fixture teardown'
> 
> 
> 
> class TestFoo():
>     def test_a(self, fix):
>         print 'test_a'
> 
>     def test_b(self):
>         print 'test_b'
> 
>     def test_c(self, fix):
>         print 'test_c'
> 
> 
> It gives me the output (with the latest pytest from PyPI):
> 
> fixture setup
> test_a
> test_b
> test_c
> fixture teardown
> 
> I.e. even though test_b does not actively request the fixture, it is active during the test.

A few addiotional notes:

- test_b does not have a reference to the fixture so can not "use" it

- "py.test -k test_b" would not see an activated "fix"

- it would be a programming mistake for test_b to depend on fix without
  declaring it.

> Is this even considered to be a bug or a feature? :-)

Let me ask back: how exactly is it a problem?

> This behavior may be considered a bug since it makes test suites
> brittle - if the fixture does not contain a value itself, it can
> probably be neglected to actually properly request the fixture, but
> test_b will still accidentally have ?fix? available. 

How does "test_b" have "fix" available?

> will only show itself when running a subset of the test suite (and
> with xdist!).
> 
> I would prefer (I think) if all fixtures where torn down when they are not requested (in my example, before test_b is run, to ensure test_b is only run with its own fixtures).
> 
> However, if all teardowns worked like this, the efficiency will be very bad since there will be a lot of teardowns. I think these fixtures that should be allowed to stay alive, should be explicitly declared like that, like the option to pytest.fixture() suggested earlier.

It would be a somewhat backward incompatible change and probably break some
test suites.

> I think this makes sense regardless of whether the fixture is class,
> module or session scoped. Having different semantics depending on the
> scope would be confusing. Fixture authors must be aware and decide
> whether or not a fixture may accidentally be available to wrong tests.
> I have a hard time to see how we can solve this properly without a
> flag or some kind of distinction for this.
> 
> I am probably missing a lot of details here, what are your thoughts on this?

I am not quite sure what the exact real-life problem is that 
we are trying to solve. Is something breaking that shouldn't, currently?

Maybe the next step is to try to document the fixture setup/teardown
logic more precisely because i am not even sure myself about the details.
xdist certainly has less guarantees than single-process pytest.

best,
holger

From nicoddemus at gmail.com  Wed Sep 24 06:30:44 2014
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Wed, 24 Sep 2014 01:30:44 -0300
Subject: [pytest-dev] xdist and data sharing during execution in parallel
In-Reply-To: <5419B794.2070905@fabrixsystems.com>
References: <5419B794.2070905@fabrixsystems.com>
Message-ID: <CA+RQFfft5J8KMckYJnUFeZwtK9Zj5A3knRg1SNxm5O3V1HNFgg@mail.gmail.com>

Hi Ayelet,

According to
http://codespeak.net/execnet/example/hybridpython.html#dumps-loads-examples,
execnet only supports built-in types, so trying to send
`node.config.global_data` to the slaves won't work.

I'm assuming that `PersistentDict` is similar to `shelve`, so another
option would be to try to construct a new instance of `PersistentDict` on
each slave that share the same underlying file.

Also can you provide some examples on how do you plan to use that shared
`PersistentDict` in each slave?

Cheers,


On Wed, Sep 17, 2014 at 1:32 PM, Ayelet Regev <ayelet at fabrixsystems.com>
wrote:

>  Hi,
>
> I'm creating a time-line based on pytest.
> im using xdist with multiple slaves (in the amount of the tests). Each
> test is started by time and dependency. which mean some of the gateways
> will be waiting for others to be "Done".
>
> for that, io need some data sharing between them all, and cannot use
> "slaveoutput".
>
> i created my own dict object using file handler, and i want to create
> instance once on master and share it will all slaves.
>
> but i cannot pass object to "slaveinput"
>
> Do you have any advice?
>
>
>
> *def pytest_configure(config):*
>
>     config.global_time_line_json = config.getoption("timeline",None)
>     unicode_to_ascii(config.global_time_line_json)
>     if config.global_time_line_json is None:
>         raise Exception("no timeline data was provided to command")
>     config.properties = config.getoption("properties")
>     unicode_to_ascii(config.properties)
>     logfile = config.properties.get("logfile",None)
>     if logfile is None:
>         raise Exception("no logfile path was provided to command under
> properties")
>     config.flow_dir = config.properties.get("flow_dir",None)
>     logfile_basename = os.path.basename(logfile)
>     _logger = Logger(config.flow_dir,logfile_basename)
>     config.logger = _logger.logger()
>     config.active_dir = "%s/%s" % (config.flow_dir,ACTIVE_DIR)
>     *if not hasattr(config,"slaveinput"):*
> *        config.logger.info2("Master")*
> *        config.global_data = PersistentDict('%s/%s' %
> (config.active_dir,FLOW_JSON), 'c', format='json')*
>
> *def pytest_configure_node(node):*
>     # runs only on Master
>     node.config.logger.info2("on Master sending data to Slave")
>    * node.slaveinput["global_data"] = node.config.global_data*
>
> --
> Best Regards,
>
> Ayelet Regev Dabah
> Email: ayelet at fabrixsystems.com
>
>
> _______________________________________________
> Pytest-dev mailing list
> Pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140924/b2083ff8/attachment.html>

From bubenkoff at gmail.com  Wed Sep 24 08:57:58 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Wed, 24 Sep 2014 08:57:58 +0200
Subject: [pytest-dev] xdist and data sharing during execution in parallel
In-Reply-To: <5419B794.2070905@fabrixsystems.com>
References: <5419B794.2070905@fabrixsystems.com>
Message-ID: <CACTnz+EM3=EBgs7WpDMfVyDe-mdThF0MectbK07krAWWoFekJA@mail.gmail.com>

I would just use something like redis for that, seriously
Don't overcomplicate things in pytest-xdist
As a side note, if you need the communication between the tests, then
you're probably doing something wrong, as it's the rule of thumb - tests
cannot share state with other tests

On 17 September 2014 18:32, Ayelet Regev <ayelet at fabrixsystems.com> wrote:

>  Hi,
>
> I'm creating a time-line based on pytest.
> im using xdist with multiple slaves (in the amount of the tests). Each
> test is started by time and dependency. which mean some of the gateways
> will be waiting for others to be "Done".
>
> for that, io need some data sharing between them all, and cannot use
> "slaveoutput".
>
> i created my own dict object using file handler, and i want to create
> instance once on master and share it will all slaves.
>
> but i cannot pass object to "slaveinput"
>
> Do you have any advice?
>
>
>
> *def pytest_configure(config):*
>
>     config.global_time_line_json = config.getoption("timeline",None)
>     unicode_to_ascii(config.global_time_line_json)
>     if config.global_time_line_json is None:
>         raise Exception("no timeline data was provided to command")
>     config.properties = config.getoption("properties")
>     unicode_to_ascii(config.properties)
>     logfile = config.properties.get("logfile",None)
>     if logfile is None:
>         raise Exception("no logfile path was provided to command under
> properties")
>     config.flow_dir = config.properties.get("flow_dir",None)
>     logfile_basename = os.path.basename(logfile)
>     _logger = Logger(config.flow_dir,logfile_basename)
>     config.logger = _logger.logger()
>     config.active_dir = "%s/%s" % (config.flow_dir,ACTIVE_DIR)
>     *if not hasattr(config,"slaveinput"):*
> *        config.logger.info2("Master")*
> *        config.global_data = PersistentDict('%s/%s' %
> (config.active_dir,FLOW_JSON), 'c', format='json')*
>
> *def pytest_configure_node(node):*
>     # runs only on Master
>     node.config.logger.info2("on Master sending data to Slave")
>    * node.slaveinput["global_data"] = node.config.global_data*
>
> --
> Best Regards,
>
> Ayelet Regev Dabah
> Email: ayelet at fabrixsystems.com
>
>
> _______________________________________________
> Pytest-dev mailing list
> Pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>


-- 
Anatoly Bubenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140924/21cfe62c/attachment.html>

From holger at merlinux.eu  Wed Sep 24 15:02:45 2014
From: holger at merlinux.eu (holger krekel)
Date: Wed, 24 Sep 2014 13:02:45 +0000
Subject: [pytest-dev] pytest-2.6.3: some fixes
Message-ID: <20140924130245.GM7954@merlinux.eu>

pytest-2.6.3: fixes and little improvements
===========================================================================

pytest is a mature Python testing tool with more than a 1100 tests
against itself, passing on many different interpreters and platforms.
This release is drop-in compatible to 2.5.2 and 2.6.X.
See below for the changes and see docs at:

    http://pytest.org

As usual, you can upgrade from pypi via::

    pip install -U pytest

Thanks to all who contributed, among them:

    Floris Bruynooghe
    Oleg Sinyavskiy
    Uwe Schmitt
    Charles Cloud
    Wolfgang Schnerring

have fun,
holger krekel

Changes 2.6.3
======================

- fix issue575: xunit-xml was reporting collection errors as failures
  instead of errors, thanks Oleg Sinyavskiy.

- fix issue582: fix setuptools example, thanks Laszlo Papp and Ronny
  Pfannschmidt.

- Fix infinite recursion bug when pickling capture.EncodedFile, thanks
  Uwe Schmitt.

- fix issue589: fix bad interaction with numpy and others when showing
  exceptions.  Check for precise "maximum recursion depth exceed" exception
  instead of presuming any RuntimeError is that one (implemented in py
  dep).  Thanks Charles Cloud for analysing the issue.

- fix conftest related fixture visibility issue: when running with a
  CWD outside a test package pytest would get fixture discovery wrong.
  Thanks to Wolfgang Schnerring for figuring out a reproducable example.

- Introduce pytest_enter_pdb hook (needed e.g. by pytest_timeout to cancel the
  timeout when interactively entering pdb).  Thanks Wolfgang Schnerring.

- check xfail/skip also with non-python function test items. Thanks
  Floris Bruynooghe.


From holger at merlinux.eu  Wed Sep 24 15:55:19 2014
From: holger at merlinux.eu (holger krekel)
Date: Wed, 24 Sep 2014 13:55:19 +0000
Subject: [pytest-dev] tox-1.8: parametrized/generative environments
Message-ID: <20140924135519.GP7954@merlinux.eu>

tox 1.8: Generative/combinatorial environments specs
=============================================================================

I am happy to announce tox 1.8 which implements parametrized environments
and should otherwise be fully backward compatible to tox-1.7.2.

See https://tox.testrun.org/latest/config.html#generating-environments-conditional-settings
for examples and the new backward compatible syntax in your tox.ini file.

Many thanks to Alexander Schepanovski for implementing and refining
it based on the specifcation draft.

More documentation about tox in general:

    http://tox.testrun.org/

Installation:

    pip install -U tox

code hosting and issue tracking on bitbucket:

    https://bitbucket.org/hpk42/tox

What is tox?
----------------

tox standardizes and automates tedious test activities driven from a
simple ``tox.ini`` file, including:

* creation and management of different virtualenv environments
  with different Python interpreters
* packaging and installing your package into each of them
* running your test tool of choice, be it nose, py.test or unittest2 or other tools such as "sphinx" doc checks
* testing dev packages against each other without needing to upload to PyPI

best,
Holger Krekel, merlinux GmbH


Changes 1.8 (compared to 1.7.2)
---------------------------------------

- new multi-dimensional configuration support.  Many thanks to
  Alexander Schepanovski for the complete PR with docs.
  And to Mike Bayer and others for testing and feedback.

- fix issue148: remove "__PYVENV_LAUNCHER__" from os.environ when starting
  subprocesses. Thanks Steven Myint.

- fix issue152: set VIRTUAL_ENV when running test commands,
  thanks Florian Ludwig.

- better report if we can't get version_info from an interpreter
  executable. Thanks Floris Bruynooghe.

From carl at oddbird.net  Wed Sep 24 19:24:31 2014
From: carl at oddbird.net (Carl Meyer)
Date: Wed, 24 Sep 2014 11:24:31 -0600
Subject: [pytest-dev] [TIP] tox-1.8: parametrized/generative environments
In-Reply-To: <20140924135519.GP7954@merlinux.eu>
References: <20140924135519.GP7954@merlinux.eu>
Message-ID: <5422FE4F.8080204@oddbird.net>

The parametrization feature allows me to reduce a 378-line tox.ini to 31
lines. Very nice, thanks to all who worked on it!

Carl

On 09/24/2014 07:55 AM, holger krekel wrote:
> tox 1.8: Generative/combinatorial environments specs
> =============================================================================
> 
> I am happy to announce tox 1.8 which implements parametrized environments
> and should otherwise be fully backward compatible to tox-1.7.2.
> 
> See https://tox.testrun.org/latest/config.html#generating-environments-conditional-settings
> for examples and the new backward compatible syntax in your tox.ini file.
> 
> Many thanks to Alexander Schepanovski for implementing and refining
> it based on the specifcation draft.
> 
> More documentation about tox in general:
> 
>     http://tox.testrun.org/
> 
> Installation:
> 
>     pip install -U tox
> 
> code hosting and issue tracking on bitbucket:
> 
>     https://bitbucket.org/hpk42/tox
> 
> What is tox?
> ----------------
> 
> tox standardizes and automates tedious test activities driven from a
> simple ``tox.ini`` file, including:
> 
> * creation and management of different virtualenv environments
>   with different Python interpreters
> * packaging and installing your package into each of them
> * running your test tool of choice, be it nose, py.test or unittest2 or other tools such as "sphinx" doc checks
> * testing dev packages against each other without needing to upload to PyPI
> 
> best,
> Holger Krekel, merlinux GmbH
> 
> 
> Changes 1.8 (compared to 1.7.2)
> ---------------------------------------
> 
> - new multi-dimensional configuration support.  Many thanks to
>   Alexander Schepanovski for the complete PR with docs.
>   And to Mike Bayer and others for testing and feedback.
> 
> - fix issue148: remove "__PYVENV_LAUNCHER__" from os.environ when starting
>   subprocesses. Thanks Steven Myint.
> 
> - fix issue152: set VIRTUAL_ENV when running test commands,
>   thanks Florian Ludwig.
> 
> - better report if we can't get version_info from an interpreter
>   executable. Thanks Floris Bruynooghe.
> 
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
> 

From david at stb-tester.com  Thu Sep 25 10:06:55 2014
From: david at stb-tester.com (=?ISO-8859-1?Q?David=20R=F6thlisberger?=)
Date: Thu, 25 Sep 2014 09:06:55 +0100
Subject: [pytest-dev] Is it valid to use --boxed with --capture=no?
Message-ID: <1411632415.975429.171562001.3CDC66F9@webmail.messagingengine.com>

Is it valid to use --boxed with --capture=no? It fails with
UnicodeEncodeError. More details at
https://bitbucket.org/hpk42/pytest/issue/573 but I'm asking here since I
haven't received an anwer on the bitbucket issue in a month. :-)

The reason I want to do that is that I'm looking into using pytest as
the test-runner for my (open source) system for testing set-top boxes &
TVs, and I need to capture (and timestamp) the std{err,out} logs myself.
Some more background on that at
http://stb-tester.com/blog/2014/09/25/upcoming-features-new-test-runner.html

Thanks,
Dave.

From holger at merlinux.eu  Thu Sep 25 11:19:16 2014
From: holger at merlinux.eu (holger krekel)
Date: Thu, 25 Sep 2014 09:19:16 +0000
Subject: [pytest-dev] Is it valid to use --boxed with --capture=no?
In-Reply-To: <1411632415.975429.171562001.3CDC66F9@webmail.messagingengine.com>
References: <1411632415.975429.171562001.3CDC66F9@webmail.messagingengine.com>
Message-ID: <20140925091916.GW7954@merlinux.eu>

On Thu, Sep 25, 2014 at 09:06 +0100, David R?thlisberger wrote:
> Is it valid to use --boxed with --capture=no? It fails with
> UnicodeEncodeError. More details at
> https://bitbucket.org/hpk42/pytest/issue/573 but I'm asking here since I
> haven't received an anwer on the bitbucket issue in a month. :-)

Maybe because "unicode" appeared in the issue description :)

The "--boxed" option does its own stdout/stderr capturing and i think
"--capture=no" does not influence it properly.  I guess it needs to
be fixed in pytest-xdist (which implements --boxed).

In any case, could you please update the issue using the latest 
pytest-2.6.3 and pytest-xdist-1.11?

> The reason I want to do that is that I'm looking into using pytest as
> the test-runner for my (open source) system for testing set-top boxes &
> TVs, and I need to capture (and timestamp) the std{err,out} logs myself.
> Some more background on that at
> http://stb-tester.com/blog/2014/09/25/upcoming-features-new-test-runner.html

I read the post but not sure i understand the exact requirements.
Do you need to timestamp the captured output as one big thing or per line?
Could you give a somewhat real-life example of what you would like to customize
in a pytest run?

best,
holger

From david at stb-tester.com  Thu Sep 25 12:39:55 2014
From: david at stb-tester.com (=?ISO-8859-1?Q?David=20R=F6thlisberger?=)
Date: Thu, 25 Sep 2014 11:39:55 +0100
Subject: [pytest-dev] Is it valid to use --boxed with --capture=no?
In-Reply-To: <20140925091916.GW7954@merlinux.eu>
References: <1411632415.975429.171562001.3CDC66F9@webmail.messagingengine.com>
 <20140925091916.GW7954@merlinux.eu>
Message-ID: <1411641595.1010982.171604221.64B3B114@webmail.messagingengine.com>

Hi Holger, thanks for your quick response.

> > Is it valid to use --boxed with --capture=no? It fails with
> > UnicodeEncodeError. More details at
> > https://bitbucket.org/hpk42/pytest/issue/573
>
> In any case, could you please update the issue using the latest 
> pytest-2.6.3 and pytest-xdist-1.11?

Done. The issue remains the same.


> Do you need to timestamp the captured output as one big thing or per line?

I add a timestamp to each line, similar to the "ts" utility from
moreutils[1] but in-process in python.

I do this by "dup2"ing stdout & stderr to a a named pipe. There's a
thread reading from the pipe, timestamping each line and writing it to
a logfile.

[1] http://manpages.ubuntu.com/manpages/trusty/man1/ts.1.html


> Could you give a somewhat real-life example of what you would like to
> customize in a pytest run?

This may be more detail than you care about, but here goes:

Stb-tester tests set-top boxes by capturing video from the set-top box
(using video-capture hardware) and sending infrared signals to the
set-top box (using a usb infrared emitter). The user's tests are written
in python.

With pytest I have a function-scope fixture that passes in an object
that the user's test can use to access the video-processing and
infrared-control functions.

For each test run I also make a video recording of the set-top box's
output. The timestamps in the log allow the user to correlate the logs
to particular points in the video.

The user can also capture other logs during a test run (for example logs
from processes running on the set-top box itself) so the timestamps are
also necessary to correlate these logs with stb-tester's logs of what
the test script is doing.

I'd like to be able to capture (and timestamp) any stdout & stderr
output written by the user's script. If this turns out to be too hard I
could provide the user's script a function like "stb_tester.log(...)"
which does the timestamping and writes to a file, but that would be an
incompatible break for my users -- their scripts currently use "print"
for logging, and unless they change their scripts that logging would be
lost when they upgrade stb-tester to the new version that uses pytest.

I need to use "--boxed" to run each test in a different process, because
very occasionally I get segfaults from the video-capture and
image-processing libraries that I use, and I don't want that to bring
down the rest of the tests.

Cheers,
Dave.

From jh at solute.de  Thu Sep 25 12:35:25 2014
From: jh at solute.de (Jens Hoffmann)
Date: Thu, 25 Sep 2014 12:35:25 +0200
Subject: [pytest-dev] top-level conftest.py not recognized when running
	tests in sub-directories
Message-ID: <5423EFED.30208@solute.de>

Hi,


we are working with pytest 2.6.2 and I run into a problem with my 
conftest session fixture setup.

My project structure looks something like this:

.
??? project
? ??? module
? ??? foo.py
??? test
??? conftest.py
??? module
??? test_foo.py


conftest.py contains a single fixture with scope="session" and 
autouse=True, setting up some database that is needed for every single 
unittest. So also test_foo.py depends on that database setup.

Now some py.test runs:

$ py.test
=> conftest.py called, database setup properly, tests pass

$ py.test test/module
=> tests fail, fixture in conftest.py not executed

$ py.test test/module/test_foo.py
=> tests fail, fixture in conftest.py not executed

$ py.test -k MyTestClassContainedInTestFooDotPy
=> tests fail, fixture in conftest.py not executed


Now my question/problem: Are all these outcoms expected behaviour? I 
hoped that all the runs would pass, that is execute my session fixture 
so that I wont need to always run my whole test suite.


Thank you for your answer,
Jens


From bubenkoff at gmail.com  Thu Sep 25 13:09:53 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Thu, 25 Sep 2014 13:09:53 +0200
Subject: [pytest-dev] top-level conftest.py not recognized when running
 tests in sub-directories
In-Reply-To: <5423EFED.30208@solute.de>
References: <5423EFED.30208@solute.de>
Message-ID: <CACTnz+HZP4Tox0kJz1DKNt3G+SsoZ2vfkGzu452C9jxnRAP9Xw@mail.gmail.com>

did you add __init__.py in all folders?

On 25 September 2014 12:35, Jens Hoffmann <jh at solute.de> wrote:

> Hi,
>
>
> we are working with pytest 2.6.2 and I run into a problem with my conftest
> session fixture setup.
>
> My project structure looks something like this:
>
> .
> ??? project
> ? ??? module
> ? ??? foo.py
> ??? test
> ??? conftest.py
> ??? module
> ??? test_foo.py
>
>
> conftest.py contains a single fixture with scope="session" and
> autouse=True, setting up some database that is needed for every single
> unittest. So also test_foo.py depends on that database setup.
>
> Now some py.test runs:
>
> $ py.test
> => conftest.py called, database setup properly, tests pass
>
> $ py.test test/module
> => tests fail, fixture in conftest.py not executed
>
> $ py.test test/module/test_foo.py
> => tests fail, fixture in conftest.py not executed
>
> $ py.test -k MyTestClassContainedInTestFooDotPy
> => tests fail, fixture in conftest.py not executed
>
>
> Now my question/problem: Are all these outcoms expected behaviour? I hoped
> that all the runs would pass, that is execute my session fixture so that I
> wont need to always run my whole test suite.
>
>
> Thank you for your answer,
> Jens
>
> _______________________________________________
> Pytest-dev mailing list
> Pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>



-- 
Anatoly Bubenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140925/c3009c41/attachment.html>

From jh at solute.de  Thu Sep 25 13:14:08 2014
From: jh at solute.de (Jens Hoffmann)
Date: Thu, 25 Sep 2014 13:14:08 +0200
Subject: [pytest-dev] top-level conftest.py not recognized when running
 tests in sub-directories
In-Reply-To: <CACTnz+HZP4Tox0kJz1DKNt3G+SsoZ2vfkGzu452C9jxnRAP9Xw@mail.gmail.com>
References: <5423EFED.30208@solute.de>
 <CACTnz+HZP4Tox0kJz1DKNt3G+SsoZ2vfkGzu452C9jxnRAP9Xw@mail.gmail.com>
Message-ID: <5423F900.9040606@solute.de>

Yes, the directories test and test/module all contain a __init__.py; 
sorry, that I didnt mention this important info.

So from your question I guess that you expect py.test to find and 
execute conftest.py in all the cases shown?


Jens


On 09/25/2014 01:09 PM, Anatoly Bubenkov wrote:
> did you add __init__.py in all folders?
>
> On 25 September 2014 12:35, Jens Hoffmann <jh at solute.de 
> <mailto:jh at solute.de>> wrote:
>
>     Hi,
>
>
>     we are working with pytest 2.6.2 and I run into a problem with my
>     conftest session fixture setup.
>
>     My project structure looks something like this:
>
>     .
>     ??? project
>     ? ??? module
>     ? ??? foo.py
>     ??? test
>     ??? conftest.py
>     ??? module
>     ??? test_foo.py
>
>
>     conftest.py contains a single fixture with scope="session" and
>     autouse=True, setting up some database that is needed for every
>     single unittest. So also test_foo.py depends on that database setup.
>
>     Now some py.test runs:
>
>     $ py.test
>     => conftest.py called, database setup properly, tests pass
>
>     $ py.test test/module
>     => tests fail, fixture in conftest.py not executed
>
>     $ py.test test/module/test_foo.py
>     => tests fail, fixture in conftest.py not executed
>
>     $ py.test -k MyTestClassContainedInTestFooDotPy
>     => tests fail, fixture in conftest.py not executed
>
>
>     Now my question/problem: Are all these outcoms expected behaviour?
>     I hoped that all the runs would pass, that is execute my session
>     fixture so that I wont need to always run my whole test suite.
>
>
>     Thank you for your answer,
>     Jens
>
>     _______________________________________________
>     Pytest-dev mailing list
>     Pytest-dev at python.org <mailto:Pytest-dev at python.org>
>     https://mail.python.org/mailman/listinfo/pytest-dev
>
>
>
>
> -- 
> Anatoly Bubenkov

-- 
Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute gmbh 
Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24 Fax: +49 
(0)721 - 86956-66 E-Mail: rsc at solute.de Web: http://www.billiger.de 
Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe Registergericht: 
Amtsgericht Mannheim Registernummer: HRB 110579 
Umsatzsteueridentifikationsnummer: DE234663798 
http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140925/7ff6d560/attachment.html>

From bubenkoff at gmail.com  Thu Sep 25 13:18:35 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Thu, 25 Sep 2014 13:18:35 +0200
Subject: [pytest-dev] top-level conftest.py not recognized when running
 tests in sub-directories
In-Reply-To: <5423F900.9040606@solute.de>
References: <5423EFED.30208@solute.de>
 <CACTnz+HZP4Tox0kJz1DKNt3G+SsoZ2vfkGzu452C9jxnRAP9Xw@mail.gmail.com>
 <5423F900.9040606@solute.de>
Message-ID: <CACTnz+HWGDeGFuOfQ7m1iB7B+S4JUuh0N0c4yFzsUmmTn5Qdgw@mail.gmail.com>

please upload fully reproducable small example somewhere
or, ideally, create a test and have a PR with it

On 25 September 2014 13:14, Jens Hoffmann <jh at solute.de> wrote:

>  Yes, the directories test and test/module all contain a __init__.py;
> sorry, that I didnt mention this important info.
>
> So from your question I guess that you expect py.test to find and execute
> conftest.py in all the cases shown?
>
>
> Jens
>
>
>
> On 09/25/2014 01:09 PM, Anatoly Bubenkov wrote:
>
> did you add __init__.py in all folders?
>
> On 25 September 2014 12:35, Jens Hoffmann <jh at solute.de> wrote:
>
>> Hi,
>>
>>
>> we are working with pytest 2.6.2 and I run into a problem with my
>> conftest session fixture setup.
>>
>> My project structure looks something like this:
>>
>> .
>> ??? project
>> ? ??? module
>> ? ??? foo.py
>> ??? test
>> ??? conftest.py
>> ??? module
>> ??? test_foo.py
>>
>>
>> conftest.py contains a single fixture with scope="session" and
>> autouse=True, setting up some database that is needed for every single
>> unittest. So also test_foo.py depends on that database setup.
>>
>> Now some py.test runs:
>>
>> $ py.test
>> => conftest.py called, database setup properly, tests pass
>>
>> $ py.test test/module
>> => tests fail, fixture in conftest.py not executed
>>
>> $ py.test test/module/test_foo.py
>> => tests fail, fixture in conftest.py not executed
>>
>> $ py.test -k MyTestClassContainedInTestFooDotPy
>> => tests fail, fixture in conftest.py not executed
>>
>>
>> Now my question/problem: Are all these outcoms expected behaviour? I
>> hoped that all the runs would pass, that is execute my session fixture so
>> that I wont need to always run my whole test suite.
>>
>>
>> Thank you for your answer,
>> Jens
>>
>> _______________________________________________
>> Pytest-dev mailing list
>> Pytest-dev at python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>
>
>
>
>  --
> Anatoly Bubenkov
>
>
> --
> Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute gmbh
> Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24 Fax: +49
> (0)721 - 86956-66 E-Mail: rsc at solute.de Web: http://www.billiger.de
> Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe Registergericht:
> Amtsgericht Mannheim Registernummer: HRB 110579
> Umsatzsteueridentifikationsnummer: DE234663798
> http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>



-- 
Anatoly Bubenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140925/7d50caf3/attachment-0001.html>

From jh at solute.de  Thu Sep 25 14:01:43 2014
From: jh at solute.de (Jens Hoffmann)
Date: Thu, 25 Sep 2014 14:01:43 +0200
Subject: [pytest-dev] top-level conftest.py not recognized when running
 tests in sub-directories
In-Reply-To: <CACTnz+HWGDeGFuOfQ7m1iB7B+S4JUuh0N0c4yFzsUmmTn5Qdgw@mail.gmail.com>
References: <5423EFED.30208@solute.de>	<CACTnz+HZP4Tox0kJz1DKNt3G+SsoZ2vfkGzu452C9jxnRAP9Xw@mail.gmail.com>	<5423F900.9040606@solute.de>
 <CACTnz+HWGDeGFuOfQ7m1iB7B+S4JUuh0N0c4yFzsUmmTn5Qdgw@mail.gmail.com>
Message-ID: <54240427.4060009@solute.de>

Okay, writing the example I found out what the actual problem is:


In the minimal example the fixture *is* executed, before any test but 
*after* my test classes setup_method.


I though expect that a session fixture is executed also before a classes 
setup_method (use case: fixture sets up DB, setup_method sets up some 
tables);


Am I wrong?


Jens


On 09/25/2014 01:18 PM, Anatoly Bubenkov wrote:
> please upload fully reproducable small example somewhere
> or, ideally, create a test and have a PR with it
>
> On 25 September 2014 13:14, Jens Hoffmann <jh at solute.de 
> <mailto:jh at solute.de>> wrote:
>
>     Yes, the directories test and test/module all contain a
>     __init__.py; sorry, that I didnt mention this important info.
>
>     So from your question I guess that you expect py.test to find and
>     execute conftest.py in all the cases shown?
>
>
>     Jens
>
>
>
>     On 09/25/2014 01:09 PM, Anatoly Bubenkov wrote:
>>     did you add __init__.py in all folders?
>>
>>     On 25 September 2014 12:35, Jens Hoffmann <jh at solute.de
>>     <mailto:jh at solute.de>> wrote:
>>
>>         Hi,
>>
>>
>>         we are working with pytest 2.6.2 and I run into a problem
>>         with my conftest session fixture setup.
>>
>>         My project structure looks something like this:
>>
>>         .
>>         ??? project
>>         ? ??? module
>>         ? ??? foo.py
>>         ??? test
>>         ??? conftest.py
>>         ??? module
>>         ??? test_foo.py
>>
>>
>>         conftest.py contains a single fixture with scope="session"
>>         and autouse=True, setting up some database that is needed for
>>         every single unittest. So also test_foo.py depends on that
>>         database setup.
>>
>>         Now some py.test runs:
>>
>>         $ py.test
>>         => conftest.py called, database setup properly, tests pass
>>
>>         $ py.test test/module
>>         => tests fail, fixture in conftest.py not executed
>>
>>         $ py.test test/module/test_foo.py
>>         => tests fail, fixture in conftest.py not executed
>>
>>         $ py.test -k MyTestClassContainedInTestFooDotPy
>>         => tests fail, fixture in conftest.py not executed
>>
>>
>>         Now my question/problem: Are all these outcoms expected
>>         behaviour? I hoped that all the runs would pass, that is
>>         execute my session fixture so that I wont need to always run
>>         my whole test suite.
>>
>>
>>         Thank you for your answer,
>>         Jens
>>
>>         _______________________________________________
>>         Pytest-dev mailing list
>>         Pytest-dev at python.org <mailto:Pytest-dev at python.org>
>>         https://mail.python.org/mailman/listinfo/pytest-dev
>>
>>
>>
>>
>>     -- 
>>     Anatoly Bubenkov
>
>     -- 
>     Jens Hoffmann Softwareentwickler Datamanagement billiger.de
>     <http://billiger.de> solute gmbh Zeppelinstra?e 15 D-76185
>     Karlsruhe Tel: +49 (0)721 - 86956-24
>     <tel:%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 - 86956-66
>     <tel:%2B49%20%280%29721%20-%2086956-66> E-Mail: rsc at solute.de
>     <mailto:rsc at solute.de> Web: http://www.billiger.de
>     Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe Registergericht:
>     Amtsgericht Mannheim Registernummer: HRB 110579
>     Umsatzsteueridentifikationsnummer: DE234663798
>     http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>
>
>
>
> -- 
> Anatoly Bubenkov

-- 
Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute gmbh 
Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24 Fax: +49 
(0)721 - 86956-66 E-Mail: rsc at solute.de Web: http://www.billiger.de 
Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe Registergericht: 
Amtsgericht Mannheim Registernummer: HRB 110579 
Umsatzsteueridentifikationsnummer: DE234663798 
http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140925/d039c032/attachment.html>

From bubenkoff at gmail.com  Thu Sep 25 14:03:37 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Thu, 25 Sep 2014 14:03:37 +0200
Subject: [pytest-dev] top-level conftest.py not recognized when running
 tests in sub-directories
In-Reply-To: <54240427.4060009@solute.de>
References: <5423EFED.30208@solute.de>
 <CACTnz+HZP4Tox0kJz1DKNt3G+SsoZ2vfkGzu452C9jxnRAP9Xw@mail.gmail.com>
 <5423F900.9040606@solute.de>
 <CACTnz+HWGDeGFuOfQ7m1iB7B+S4JUuh0N0c4yFzsUmmTn5Qdgw@mail.gmail.com>
 <54240427.4060009@solute.de>
Message-ID: <CACTnz+FFACo7a+uKH6YkQ6EVHzWRjiHR8ZHt08JkgQ9fi4Vp4g@mail.gmail.com>

setup_ methods should just die :)
use fixtures everywhere instead

On 25 September 2014 14:01, Jens Hoffmann <jh at solute.de> wrote:

>  Okay, writing the example I found out what the actual problem is:
>
>
> In the minimal example the fixture *is* executed, before any test but
> *after* my test classes setup_method.
>
>
> I though expect that a session fixture is executed also before a classes
> setup_method (use case: fixture sets up DB, setup_method sets up some
> tables);
>
>
> Am I wrong?
>
>
> Jens
>
>
>
> On 09/25/2014 01:18 PM, Anatoly Bubenkov wrote:
>
> please upload fully reproducable small example somewhere
> or, ideally, create a test and have a PR with it
>
> On 25 September 2014 13:14, Jens Hoffmann <jh at solute.de> wrote:
>
>>  Yes, the directories test and test/module all contain a __init__.py;
>> sorry, that I didnt mention this important info.
>>
>> So from your question I guess that you expect py.test to find and execute
>> conftest.py in all the cases shown?
>>
>>
>> Jens
>>
>>
>>
>> On 09/25/2014 01:09 PM, Anatoly Bubenkov wrote:
>>
>> did you add __init__.py in all folders?
>>
>> On 25 September 2014 12:35, Jens Hoffmann <jh at solute.de> wrote:
>>
>>> Hi,
>>>
>>>
>>> we are working with pytest 2.6.2 and I run into a problem with my
>>> conftest session fixture setup.
>>>
>>> My project structure looks something like this:
>>>
>>> .
>>> ??? project
>>> ? ??? module
>>> ? ??? foo.py
>>> ??? test
>>> ??? conftest.py
>>> ??? module
>>> ??? test_foo.py
>>>
>>>
>>> conftest.py contains a single fixture with scope="session" and
>>> autouse=True, setting up some database that is needed for every single
>>> unittest. So also test_foo.py depends on that database setup.
>>>
>>> Now some py.test runs:
>>>
>>> $ py.test
>>> => conftest.py called, database setup properly, tests pass
>>>
>>> $ py.test test/module
>>> => tests fail, fixture in conftest.py not executed
>>>
>>> $ py.test test/module/test_foo.py
>>> => tests fail, fixture in conftest.py not executed
>>>
>>> $ py.test -k MyTestClassContainedInTestFooDotPy
>>> => tests fail, fixture in conftest.py not executed
>>>
>>>
>>> Now my question/problem: Are all these outcoms expected behaviour? I
>>> hoped that all the runs would pass, that is execute my session fixture so
>>> that I wont need to always run my whole test suite.
>>>
>>>
>>> Thank you for your answer,
>>> Jens
>>>
>>> _______________________________________________
>>> Pytest-dev mailing list
>>> Pytest-dev at python.org
>>> https://mail.python.org/mailman/listinfo/pytest-dev
>>>
>>
>>
>>
>>  --
>> Anatoly Bubenkov
>>
>>
>>   --
>> Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute gmbh
>> Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24
>> <%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 - 86956-66
>> <%2B49%20%280%29721%20-%2086956-66> E-Mail: rsc at solute.de Web:
>> http://www.billiger.de Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe
>> Registergericht: Amtsgericht Mannheim Registernummer: HRB 110579
>> Umsatzsteueridentifikationsnummer: DE234663798
>> http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>>
>
>
>
>  --
> Anatoly Bubenkov
>
>
> --
> Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute gmbh
> Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24 Fax: +49
> (0)721 - 86956-66 E-Mail: rsc at solute.de Web: http://www.billiger.de
> Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe Registergericht:
> Amtsgericht Mannheim Registernummer: HRB 110579
> Umsatzsteueridentifikationsnummer: DE234663798
> http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>



-- 
Anatoly Bubenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140925/f99e6093/attachment-0001.html>

From jh at solute.de  Thu Sep 25 14:06:11 2014
From: jh at solute.de (Jens Hoffmann)
Date: Thu, 25 Sep 2014 14:06:11 +0200
Subject: [pytest-dev] top-level conftest.py not recognized when running
 tests in sub-directories
In-Reply-To: <CACTnz+FFACo7a+uKH6YkQ6EVHzWRjiHR8ZHt08JkgQ9fi4Vp4g@mail.gmail.com>
References: <5423EFED.30208@solute.de>	<CACTnz+HZP4Tox0kJz1DKNt3G+SsoZ2vfkGzu452C9jxnRAP9Xw@mail.gmail.com>	<5423F900.9040606@solute.de>	<CACTnz+HWGDeGFuOfQ7m1iB7B+S4JUuh0N0c4yFzsUmmTn5Qdgw@mail.gmail.com>	<54240427.4060009@solute.de>
 <CACTnz+FFACo7a+uKH6YkQ6EVHzWRjiHR8ZHt08JkgQ9fi4Vp4g@mail.gmail.com>
Message-ID: <54240533.7080408@solute.de>

okay, I'll kill them... thank you for your quick responses


On 09/25/2014 02:03 PM, Anatoly Bubenkov wrote:
> setup_ methods should just die :)
> use fixtures everywhere instead
>
> On 25 September 2014 14:01, Jens Hoffmann <jh at solute.de 
> <mailto:jh at solute.de>> wrote:
>
>     Okay, writing the example I found out what the actual problem is:
>
>
>     In the minimal example the fixture *is* executed, before any test
>     but *after* my test classes setup_method.
>
>
>     I though expect that a session fixture is executed also before a
>     classes setup_method (use case: fixture sets up DB, setup_method
>     sets up some tables);
>
>
>     Am I wrong?
>
>
>     Jens
>
>
>
>     On 09/25/2014 01:18 PM, Anatoly Bubenkov wrote:
>>     please upload fully reproducable small example somewhere
>>     or, ideally, create a test and have a PR with it
>>
>>     On 25 September 2014 13:14, Jens Hoffmann <jh at solute.de
>>     <mailto:jh at solute.de>> wrote:
>>
>>         Yes, the directories test and test/module all contain a
>>         __init__.py; sorry, that I didnt mention this important info.
>>
>>         So from your question I guess that you expect py.test to find
>>         and execute conftest.py in all the cases shown?
>>
>>
>>         Jens
>>
>>
>>
>>         On 09/25/2014 01:09 PM, Anatoly Bubenkov wrote:
>>>         did you add __init__.py in all folders?
>>>
>>>         On 25 September 2014 12:35, Jens Hoffmann <jh at solute.de
>>>         <mailto:jh at solute.de>> wrote:
>>>
>>>             Hi,
>>>
>>>
>>>             we are working with pytest 2.6.2 and I run into a
>>>             problem with my conftest session fixture setup.
>>>
>>>             My project structure looks something like this:
>>>
>>>             .
>>>             ??? project
>>>             ? ??? module
>>>             ? ??? foo.py
>>>             ??? test
>>>             ??? conftest.py
>>>             ??? module
>>>             ??? test_foo.py
>>>
>>>
>>>             conftest.py contains a single fixture with
>>>             scope="session" and autouse=True, setting up some
>>>             database that is needed for every single unittest. So
>>>             also test_foo.py depends on that database setup.
>>>
>>>             Now some py.test runs:
>>>
>>>             $ py.test
>>>             => conftest.py called, database setup properly, tests pass
>>>
>>>             $ py.test test/module
>>>             => tests fail, fixture in conftest.py not executed
>>>
>>>             $ py.test test/module/test_foo.py
>>>             => tests fail, fixture in conftest.py not executed
>>>
>>>             $ py.test -k MyTestClassContainedInTestFooDotPy
>>>             => tests fail, fixture in conftest.py not executed
>>>
>>>
>>>             Now my question/problem: Are all these outcoms expected
>>>             behaviour? I hoped that all the runs would pass, that is
>>>             execute my session fixture so that I wont need to always
>>>             run my whole test suite.
>>>
>>>
>>>             Thank you for your answer,
>>>             Jens
>>>
>>>             _______________________________________________
>>>             Pytest-dev mailing list
>>>             Pytest-dev at python.org <mailto:Pytest-dev at python.org>
>>>             https://mail.python.org/mailman/listinfo/pytest-dev
>>>
>>>
>>>
>>>
>>>         -- 
>>>         Anatoly Bubenkov
>>
>>         -- 
>>         Jens Hoffmann Softwareentwickler Datamanagement billiger.de
>>         <http://billiger.de> solute gmbh Zeppelinstra?e 15 D-76185
>>         Karlsruhe Tel: +49 (0)721 - 86956-24
>>         <tel:%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 -
>>         86956-66 <tel:%2B49%20%280%29721%20-%2086956-66> E-Mail:
>>         rsc at solute.de <mailto:rsc at solute.de> Web:
>>         http://www.billiger.de Gesch?ftsf?hrer: Lorenz Petersen Sitz:
>>         Karlsruhe Registergericht: Amtsgericht Mannheim
>>         Registernummer: HRB 110579 Umsatzsteueridentifikationsnummer:
>>         DE234663798
>>         http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>>
>>
>>
>>
>>     -- 
>>     Anatoly Bubenkov
>
>     -- 
>     Jens Hoffmann Softwareentwickler Datamanagement billiger.de
>     <http://billiger.de> solute gmbh Zeppelinstra?e 15 D-76185
>     Karlsruhe Tel: +49 (0)721 - 86956-24
>     <tel:%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 - 86956-66
>     <tel:%2B49%20%280%29721%20-%2086956-66> E-Mail: rsc at solute.de
>     <mailto:rsc at solute.de> Web: http://www.billiger.de
>     Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe Registergericht:
>     Amtsgericht Mannheim Registernummer: HRB 110579
>     Umsatzsteueridentifikationsnummer: DE234663798
>     http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>
>
>
>
> -- 
> Anatoly Bubenkov

-- 
Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute gmbh 
Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24 Fax: +49 
(0)721 - 86956-66 E-Mail: rsc at solute.de Web: http://www.billiger.de 
Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe Registergericht: 
Amtsgericht Mannheim Registernummer: HRB 110579 
Umsatzsteueridentifikationsnummer: DE234663798 
http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140925/94bfd424/attachment.html>

From bubenkoff at gmail.com  Thu Sep 25 14:09:13 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Thu, 25 Sep 2014 14:09:13 +0200
Subject: [pytest-dev] top-level conftest.py not recognized when running
 tests in sub-directories
In-Reply-To: <54240533.7080408@solute.de>
References: <5423EFED.30208@solute.de>
 <CACTnz+HZP4Tox0kJz1DKNt3G+SsoZ2vfkGzu452C9jxnRAP9Xw@mail.gmail.com>
 <5423F900.9040606@solute.de>
 <CACTnz+HWGDeGFuOfQ7m1iB7B+S4JUuh0N0c4yFzsUmmTn5Qdgw@mail.gmail.com>
 <54240427.4060009@solute.de>
 <CACTnz+FFACo7a+uKH6YkQ6EVHzWRjiHR8ZHt08JkgQ9fi4Vp4g@mail.gmail.com>
 <54240533.7080408@solute.de>
Message-ID: <CACTnz+E-jpBJkg=HDioegN+Opc0g-K2-n5uhdpD3s3+_VF3Xtw@mail.gmail.com>

the thing is, fixtures have proper dependency injection working
but combing them with oldish setup_ methods doesn't always work properly
out of the box - just because it's impossible to determine the 'right'
order, because there's no 'right' order, it's all up to you to determine
the dependency tree

On 25 September 2014 14:06, Jens Hoffmann <jh at solute.de> wrote:

>  okay, I'll kill them... thank you for your quick responses
>
>
>
> On 09/25/2014 02:03 PM, Anatoly Bubenkov wrote:
>
> setup_ methods should just die :)
> use fixtures everywhere instead
>
> On 25 September 2014 14:01, Jens Hoffmann <jh at solute.de> wrote:
>
>>  Okay, writing the example I found out what the actual problem is:
>>
>>
>> In the minimal example the fixture *is* executed, before any test but
>> *after* my test classes setup_method.
>>
>>
>> I though expect that a session fixture is executed also before a classes
>> setup_method (use case: fixture sets up DB, setup_method sets up some
>> tables);
>>
>>
>> Am I wrong?
>>
>>
>> Jens
>>
>>
>>
>> On 09/25/2014 01:18 PM, Anatoly Bubenkov wrote:
>>
>> please upload fully reproducable small example somewhere
>> or, ideally, create a test and have a PR with it
>>
>> On 25 September 2014 13:14, Jens Hoffmann <jh at solute.de> wrote:
>>
>>>  Yes, the directories test and test/module all contain a __init__.py;
>>> sorry, that I didnt mention this important info.
>>>
>>> So from your question I guess that you expect py.test to find and
>>> execute conftest.py in all the cases shown?
>>>
>>>
>>> Jens
>>>
>>>
>>>
>>> On 09/25/2014 01:09 PM, Anatoly Bubenkov wrote:
>>>
>>> did you add __init__.py in all folders?
>>>
>>> On 25 September 2014 12:35, Jens Hoffmann <jh at solute.de> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>> we are working with pytest 2.6.2 and I run into a problem with my
>>>> conftest session fixture setup.
>>>>
>>>> My project structure looks something like this:
>>>>
>>>> .
>>>> ??? project
>>>> ? ??? module
>>>> ? ??? foo.py
>>>> ??? test
>>>> ??? conftest.py
>>>> ??? module
>>>> ??? test_foo.py
>>>>
>>>>
>>>> conftest.py contains a single fixture with scope="session" and
>>>> autouse=True, setting up some database that is needed for every single
>>>> unittest. So also test_foo.py depends on that database setup.
>>>>
>>>> Now some py.test runs:
>>>>
>>>> $ py.test
>>>> => conftest.py called, database setup properly, tests pass
>>>>
>>>> $ py.test test/module
>>>> => tests fail, fixture in conftest.py not executed
>>>>
>>>> $ py.test test/module/test_foo.py
>>>> => tests fail, fixture in conftest.py not executed
>>>>
>>>> $ py.test -k MyTestClassContainedInTestFooDotPy
>>>> => tests fail, fixture in conftest.py not executed
>>>>
>>>>
>>>> Now my question/problem: Are all these outcoms expected behaviour? I
>>>> hoped that all the runs would pass, that is execute my session fixture so
>>>> that I wont need to always run my whole test suite.
>>>>
>>>>
>>>> Thank you for your answer,
>>>> Jens
>>>>
>>>> _______________________________________________
>>>> Pytest-dev mailing list
>>>> Pytest-dev at python.org
>>>> https://mail.python.org/mailman/listinfo/pytest-dev
>>>>
>>>
>>>
>>>
>>>  --
>>> Anatoly Bubenkov
>>>
>>>
>>>   --
>>> Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute gmbh
>>> Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24
>>> <%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 - 86956-66
>>> <%2B49%20%280%29721%20-%2086956-66> E-Mail: rsc at solute.de Web:
>>> http://www.billiger.de Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe
>>> Registergericht: Amtsgericht Mannheim Registernummer: HRB 110579
>>> Umsatzsteueridentifikationsnummer: DE234663798
>>> http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>>>
>>
>>
>>
>>  --
>> Anatoly Bubenkov
>>
>>
>> --
>> Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute gmbh
>> Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24
>> <%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 - 86956-66
>> <%2B49%20%280%29721%20-%2086956-66> E-Mail: rsc at solute.de Web:
>> http://www.billiger.de Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe
>> Registergericht: Amtsgericht Mannheim Registernummer: HRB 110579
>> Umsatzsteueridentifikationsnummer: DE234663798
>> http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>>
>
>
>
>  --
> Anatoly Bubenkov
>
>
> --
> Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute gmbh
> Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24 Fax: +49
> (0)721 - 86956-66 E-Mail: rsc at solute.de Web: http://www.billiger.de
> Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe Registergericht:
> Amtsgericht Mannheim Registernummer: HRB 110579
> Umsatzsteueridentifikationsnummer: DE234663798
> http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>



-- 
Anatoly Bubenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140925/8ef4f4c3/attachment-0001.html>

From jh at solute.de  Thu Sep 25 14:20:13 2014
From: jh at solute.de (Jens Hoffmann)
Date: Thu, 25 Sep 2014 14:20:13 +0200
Subject: [pytest-dev] top-level conftest.py not recognized when running
 tests in sub-directories
In-Reply-To: <CACTnz+E-jpBJkg=HDioegN+Opc0g-K2-n5uhdpD3s3+_VF3Xtw@mail.gmail.com>
References: <5423EFED.30208@solute.de>	<CACTnz+HZP4Tox0kJz1DKNt3G+SsoZ2vfkGzu452C9jxnRAP9Xw@mail.gmail.com>	<5423F900.9040606@solute.de>	<CACTnz+HWGDeGFuOfQ7m1iB7B+S4JUuh0N0c4yFzsUmmTn5Qdgw@mail.gmail.com>	<54240427.4060009@solute.de>	<CACTnz+FFACo7a+uKH6YkQ6EVHzWRjiHR8ZHt08JkgQ9fi4Vp4g@mail.gmail.com>	<54240533.7080408@solute.de>
 <CACTnz+E-jpBJkg=HDioegN+Opc0g-K2-n5uhdpD3s3+_VF3Xtw@mail.gmail.com>
Message-ID: <5424087D.8050202@solute.de>

This gives me a little pain, since I always liked to organize my tests 
OO-like, with classes etc; the docs call pytest fixtures: explicit, 
modular, scalable; but for me "decorating classes and methods" is a tiny 
bit of magic that forces me to leave the pure OO way and to think a 
little more functional;


Jens


On 09/25/2014 02:09 PM, Anatoly Bubenkov wrote:
> the thing is, fixtures have proper dependency injection working
> but combing them with oldish setup_ methods doesn't always work 
> properly out of the box - just because it's impossible to determine 
> the 'right' order, because there's no 'right' order, it's all up to 
> you to determine the dependency tree
>
> On 25 September 2014 14:06, Jens Hoffmann <jh at solute.de 
> <mailto:jh at solute.de>> wrote:
>
>     okay, I'll kill them... thank you for your quick responses
>
>
>
>     On 09/25/2014 02:03 PM, Anatoly Bubenkov wrote:
>>     setup_ methods should just die :)
>>     use fixtures everywhere instead
>>
>>     On 25 September 2014 14:01, Jens Hoffmann <jh at solute.de
>>     <mailto:jh at solute.de>> wrote:
>>
>>         Okay, writing the example I found out what the actual problem is:
>>
>>
>>         In the minimal example the fixture *is* executed, before any
>>         test but *after* my test classes setup_method.
>>
>>
>>         I though expect that a session fixture is executed also
>>         before a classes setup_method (use case: fixture sets up DB,
>>         setup_method sets up some tables);
>>
>>
>>         Am I wrong?
>>
>>
>>         Jens
>>
>>
>>
>>         On 09/25/2014 01:18 PM, Anatoly Bubenkov wrote:
>>>         please upload fully reproducable small example somewhere
>>>         or, ideally, create a test and have a PR with it
>>>
>>>         On 25 September 2014 13:14, Jens Hoffmann <jh at solute.de
>>>         <mailto:jh at solute.de>> wrote:
>>>
>>>             Yes, the directories test and test/module all contain a
>>>             __init__.py; sorry, that I didnt mention this important
>>>             info.
>>>
>>>             So from your question I guess that you expect py.test to
>>>             find and execute conftest.py in all the cases shown?
>>>
>>>
>>>             Jens
>>>
>>>
>>>
>>>             On 09/25/2014 01:09 PM, Anatoly Bubenkov wrote:
>>>>             did you add __init__.py in all folders?
>>>>
>>>>             On 25 September 2014 12:35, Jens Hoffmann <jh at solute.de
>>>>             <mailto:jh at solute.de>> wrote:
>>>>
>>>>                 Hi,
>>>>
>>>>
>>>>                 we are working with pytest 2.6.2 and I run into a
>>>>                 problem with my conftest session fixture setup.
>>>>
>>>>                 My project structure looks something like this:
>>>>
>>>>                 .
>>>>                 ??? project
>>>>                 ? ??? module
>>>>                 ? ??? foo.py
>>>>                 ??? test
>>>>                 ??? conftest.py
>>>>                 ??? module
>>>>                 ??? test_foo.py
>>>>
>>>>
>>>>                 conftest.py contains a single fixture with
>>>>                 scope="session" and autouse=True, setting up some
>>>>                 database that is needed for every single unittest.
>>>>                 So also test_foo.py depends on that database setup.
>>>>
>>>>                 Now some py.test runs:
>>>>
>>>>                 $ py.test
>>>>                 => conftest.py called, database setup properly,
>>>>                 tests pass
>>>>
>>>>                 $ py.test test/module
>>>>                 => tests fail, fixture in conftest.py not executed
>>>>
>>>>                 $ py.test test/module/test_foo.py
>>>>                 => tests fail, fixture in conftest.py not executed
>>>>
>>>>                 $ py.test -k MyTestClassContainedInTestFooDotPy
>>>>                 => tests fail, fixture in conftest.py not executed
>>>>
>>>>
>>>>                 Now my question/problem: Are all these outcoms
>>>>                 expected behaviour? I hoped that all the runs would
>>>>                 pass, that is execute my session fixture so that I
>>>>                 wont need to always run my whole test suite.
>>>>
>>>>
>>>>                 Thank you for your answer,
>>>>                 Jens
>>>>
>>>>                 _______________________________________________
>>>>                 Pytest-dev mailing list
>>>>                 Pytest-dev at python.org <mailto:Pytest-dev at python.org>
>>>>                 https://mail.python.org/mailman/listinfo/pytest-dev
>>>>
>>>>
>>>>
>>>>
>>>>             -- 
>>>>             Anatoly Bubenkov
>>>
>>>             -- 
>>>             Jens Hoffmann Softwareentwickler Datamanagement
>>>             billiger.de <http://billiger.de> solute gmbh
>>>             Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 -
>>>             86956-24 <tel:%2B49%20%280%29721%20-%2086956-24> Fax:
>>>             +49 (0)721 - 86956-66
>>>             <tel:%2B49%20%280%29721%20-%2086956-66> E-Mail:
>>>             rsc at solute.de <mailto:rsc at solute.de> Web:
>>>             http://www.billiger.de Gesch?ftsf?hrer: Lorenz Petersen
>>>             Sitz: Karlsruhe Registergericht: Amtsgericht Mannheim
>>>             Registernummer: HRB 110579
>>>             Umsatzsteueridentifikationsnummer: DE234663798
>>>             http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>>>
>>>
>>>
>>>
>>>         -- 
>>>         Anatoly Bubenkov
>>
>>         -- 
>>         Jens Hoffmann Softwareentwickler Datamanagement billiger.de
>>         <http://billiger.de> solute gmbh Zeppelinstra?e 15 D-76185
>>         Karlsruhe Tel: +49 (0)721 - 86956-24
>>         <tel:%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 -
>>         86956-66 <tel:%2B49%20%280%29721%20-%2086956-66> E-Mail:
>>         rsc at solute.de <mailto:rsc at solute.de> Web:
>>         http://www.billiger.de Gesch?ftsf?hrer: Lorenz Petersen Sitz:
>>         Karlsruhe Registergericht: Amtsgericht Mannheim
>>         Registernummer: HRB 110579 Umsatzsteueridentifikationsnummer:
>>         DE234663798
>>         http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>>
>>
>>
>>
>>     -- 
>>     Anatoly Bubenkov
>
>     -- 
>     Jens Hoffmann Softwareentwickler Datamanagement billiger.de
>     <http://billiger.de> solute gmbh Zeppelinstra?e 15 D-76185
>     Karlsruhe Tel: +49 (0)721 - 86956-24
>     <tel:%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 - 86956-66
>     <tel:%2B49%20%280%29721%20-%2086956-66> E-Mail: rsc at solute.de
>     <mailto:rsc at solute.de> Web: http://www.billiger.de
>     Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe Registergericht:
>     Amtsgericht Mannheim Registernummer: HRB 110579
>     Umsatzsteueridentifikationsnummer: DE234663798
>     http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>
>
>
>
> -- 
> Anatoly Bubenkov

-- 
Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute gmbh 
Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24 Fax: +49 
(0)721 - 86956-66 E-Mail: rsc at solute.de Web: http://www.billiger.de 
Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe Registergericht: 
Amtsgericht Mannheim Registernummer: HRB 110579 
Umsatzsteueridentifikationsnummer: DE234663798 
http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140925/d693f888/attachment-0001.html>

From bubenkoff at gmail.com  Thu Sep 25 14:23:07 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Thu, 25 Sep 2014 14:23:07 +0200
Subject: [pytest-dev] top-level conftest.py not recognized when running
 tests in sub-directories
In-Reply-To: <5424087D.8050202@solute.de>
References: <5423EFED.30208@solute.de>
 <CACTnz+HZP4Tox0kJz1DKNt3G+SsoZ2vfkGzu452C9jxnRAP9Xw@mail.gmail.com>
 <5423F900.9040606@solute.de>
 <CACTnz+HWGDeGFuOfQ7m1iB7B+S4JUuh0N0c4yFzsUmmTn5Qdgw@mail.gmail.com>
 <54240427.4060009@solute.de>
 <CACTnz+FFACo7a+uKH6YkQ6EVHzWRjiHR8ZHt08JkgQ9fi4Vp4g@mail.gmail.com>
 <54240533.7080408@solute.de>
 <CACTnz+E-jpBJkg=HDioegN+Opc0g-K2-n5uhdpD3s3+_VF3Xtw@mail.gmail.com>
 <5424087D.8050202@solute.de>
Message-ID: <CACTnz+GqYcyeQUj4KKCR+6EVhd_RbcvtPM9edSgtAdNwehMo6w@mail.gmail.com>

exactly, just throw away all those classes - Guido said, classes are NOT
namespaces
you might only need classes for the polymorphism, but it's no-use in the
tests

On 25 September 2014 14:20, Jens Hoffmann <jh at solute.de> wrote:

>  This gives me a little pain, since I always liked to organize my tests
> OO-like, with classes etc; the docs call pytest fixtures: explicit,
> modular, scalable; but for me "decorating classes and methods" is a tiny
> bit of magic that forces me to leave the pure OO way and to think a little
> more functional;
>
>
> Jens
>
>
>
> On 09/25/2014 02:09 PM, Anatoly Bubenkov wrote:
>
> the thing is, fixtures have proper dependency injection working
> but combing them with oldish setup_ methods doesn't always work properly
> out of the box - just because it's impossible to determine the 'right'
> order, because there's no 'right' order, it's all up to you to determine
> the dependency tree
>
> On 25 September 2014 14:06, Jens Hoffmann <jh at solute.de> wrote:
>
>>  okay, I'll kill them... thank you for your quick responses
>>
>>
>>
>> On 09/25/2014 02:03 PM, Anatoly Bubenkov wrote:
>>
>> setup_ methods should just die :)
>> use fixtures everywhere instead
>>
>> On 25 September 2014 14:01, Jens Hoffmann <jh at solute.de> wrote:
>>
>>>  Okay, writing the example I found out what the actual problem is:
>>>
>>>
>>> In the minimal example the fixture *is* executed, before any test but
>>> *after* my test classes setup_method.
>>>
>>>
>>> I though expect that a session fixture is executed also before a classes
>>> setup_method (use case: fixture sets up DB, setup_method sets up some
>>> tables);
>>>
>>>
>>> Am I wrong?
>>>
>>>
>>> Jens
>>>
>>>
>>>
>>> On 09/25/2014 01:18 PM, Anatoly Bubenkov wrote:
>>>
>>> please upload fully reproducable small example somewhere
>>> or, ideally, create a test and have a PR with it
>>>
>>> On 25 September 2014 13:14, Jens Hoffmann <jh at solute.de> wrote:
>>>
>>>>  Yes, the directories test and test/module all contain a __init__.py;
>>>> sorry, that I didnt mention this important info.
>>>>
>>>> So from your question I guess that you expect py.test to find and
>>>> execute conftest.py in all the cases shown?
>>>>
>>>>
>>>> Jens
>>>>
>>>>
>>>>
>>>> On 09/25/2014 01:09 PM, Anatoly Bubenkov wrote:
>>>>
>>>> did you add __init__.py in all folders?
>>>>
>>>> On 25 September 2014 12:35, Jens Hoffmann <jh at solute.de> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>> we are working with pytest 2.6.2 and I run into a problem with my
>>>>> conftest session fixture setup.
>>>>>
>>>>> My project structure looks something like this:
>>>>>
>>>>> .
>>>>> ??? project
>>>>> ? ??? module
>>>>> ? ??? foo.py
>>>>> ??? test
>>>>> ??? conftest.py
>>>>> ??? module
>>>>> ??? test_foo.py
>>>>>
>>>>>
>>>>> conftest.py contains a single fixture with scope="session" and
>>>>> autouse=True, setting up some database that is needed for every single
>>>>> unittest. So also test_foo.py depends on that database setup.
>>>>>
>>>>> Now some py.test runs:
>>>>>
>>>>> $ py.test
>>>>> => conftest.py called, database setup properly, tests pass
>>>>>
>>>>> $ py.test test/module
>>>>> => tests fail, fixture in conftest.py not executed
>>>>>
>>>>> $ py.test test/module/test_foo.py
>>>>> => tests fail, fixture in conftest.py not executed
>>>>>
>>>>> $ py.test -k MyTestClassContainedInTestFooDotPy
>>>>> => tests fail, fixture in conftest.py not executed
>>>>>
>>>>>
>>>>> Now my question/problem: Are all these outcoms expected behaviour? I
>>>>> hoped that all the runs would pass, that is execute my session fixture so
>>>>> that I wont need to always run my whole test suite.
>>>>>
>>>>>
>>>>> Thank you for your answer,
>>>>> Jens
>>>>>
>>>>> _______________________________________________
>>>>> Pytest-dev mailing list
>>>>> Pytest-dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/pytest-dev
>>>>>
>>>>
>>>>
>>>>
>>>>  --
>>>> Anatoly Bubenkov
>>>>
>>>>
>>>>   --
>>>> Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute
>>>> gmbh Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24
>>>> <%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 - 86956-66
>>>> <%2B49%20%280%29721%20-%2086956-66> E-Mail: rsc at solute.de Web:
>>>> http://www.billiger.de Gesch?ftsf?hrer: Lorenz Petersen Sitz:
>>>> Karlsruhe Registergericht: Amtsgericht Mannheim Registernummer: HRB 110579
>>>> Umsatzsteueridentifikationsnummer: DE234663798
>>>> http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>>>>
>>>
>>>
>>>
>>>  --
>>> Anatoly Bubenkov
>>>
>>>
>>> --
>>> Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute gmbh
>>> Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24
>>> <%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 - 86956-66
>>> <%2B49%20%280%29721%20-%2086956-66> E-Mail: rsc at solute.de Web:
>>> http://www.billiger.de Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe
>>> Registergericht: Amtsgericht Mannheim Registernummer: HRB 110579
>>> Umsatzsteueridentifikationsnummer: DE234663798
>>> http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>>>
>>
>>
>>
>>  --
>> Anatoly Bubenkov
>>
>>
>> --
>> Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute gmbh
>> Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24
>> <%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 - 86956-66
>> <%2B49%20%280%29721%20-%2086956-66> E-Mail: rsc at solute.de Web:
>> http://www.billiger.de Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe
>> Registergericht: Amtsgericht Mannheim Registernummer: HRB 110579
>> Umsatzsteueridentifikationsnummer: DE234663798
>> http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>>
>
>
>
>  --
> Anatoly Bubenkov
>
>
> --
> Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute gmbh
> Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24 Fax: +49
> (0)721 - 86956-66 E-Mail: rsc at solute.de Web: http://www.billiger.de
> Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe Registergericht:
> Amtsgericht Mannheim Registernummer: HRB 110579
> Umsatzsteueridentifikationsnummer: DE234663798
> http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>



-- 
Anatoly Bubenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140925/118b94d4/attachment-0001.html>

From bubenkoff at gmail.com  Thu Sep 25 14:35:40 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Thu, 25 Sep 2014 14:35:40 +0200
Subject: [pytest-dev] top-level conftest.py not recognized when running
 tests in sub-directories
In-Reply-To: <54240B18.4050509@solute.de>
References: <5423EFED.30208@solute.de>
 <CACTnz+HZP4Tox0kJz1DKNt3G+SsoZ2vfkGzu452C9jxnRAP9Xw@mail.gmail.com>
 <5423F900.9040606@solute.de>
 <CACTnz+HWGDeGFuOfQ7m1iB7B+S4JUuh0N0c4yFzsUmmTn5Qdgw@mail.gmail.com>
 <54240427.4060009@solute.de>
 <CACTnz+FFACo7a+uKH6YkQ6EVHzWRjiHR8ZHt08JkgQ9fi4Vp4g@mail.gmail.com>
 <54240533.7080408@solute.de>
 <CACTnz+E-jpBJkg=HDioegN+Opc0g-K2-n5uhdpD3s3+_VF3Xtw@mail.gmail.com>
 <5424087D.8050202@solute.de>
 <CACTnz+GqYcyeQUj4KKCR+6EVhd_RbcvtPM9edSgtAdNwehMo6w@mail.gmail.com>
 <54240B18.4050509@solute.de>
Message-ID: <CACTnz+GE0DDASzW_23F+vNu-Ck-+NrSk4M8-ut=3KXDxhQdVqA@mail.gmail.com>

pytest is a test framework, right?
and framework is a set of rules to enforce, otherwise, what is it?
all IMHO of course, please don't take it too serious, it's mostly my
experience with fixtures in pytest: if something is not a fixture, then
you'll have a problem at some point

On 25 September 2014 14:31, Jens Hoffmann <jh at solute.de> wrote:

>  Okay, I clearly get what Guido said, but I say: let the folks do what
> they want to! pytest now kind of forces me to think like Guido;
>
>
> Jens
>
>
>
>
> On 09/25/2014 02:23 PM, Anatoly Bubenkov wrote:
>
> exactly, just throw away all those classes - Guido said, classes are NOT
> namespaces
> you might only need classes for the polymorphism, but it's no-use in the
> tests
>
> On 25 September 2014 14:20, Jens Hoffmann <jh at solute.de> wrote:
>
>>  This gives me a little pain, since I always liked to organize my tests
>> OO-like, with classes etc; the docs call pytest fixtures: explicit,
>> modular, scalable; but for me "decorating classes and methods" is a tiny
>> bit of magic that forces me to leave the pure OO way and to think a little
>> more functional;
>>
>>
>> Jens
>>
>>
>>
>> On 09/25/2014 02:09 PM, Anatoly Bubenkov wrote:
>>
>> the thing is, fixtures have proper dependency injection working
>> but combing them with oldish setup_ methods doesn't always work properly
>> out of the box - just because it's impossible to determine the 'right'
>> order, because there's no 'right' order, it's all up to you to determine
>> the dependency tree
>>
>> On 25 September 2014 14:06, Jens Hoffmann <jh at solute.de> wrote:
>>
>>>  okay, I'll kill them... thank you for your quick responses
>>>
>>>
>>>
>>> On 09/25/2014 02:03 PM, Anatoly Bubenkov wrote:
>>>
>>> setup_ methods should just die :)
>>> use fixtures everywhere instead
>>>
>>> On 25 September 2014 14:01, Jens Hoffmann <jh at solute.de> wrote:
>>>
>>>>  Okay, writing the example I found out what the actual problem is:
>>>>
>>>>
>>>> In the minimal example the fixture *is* executed, before any test but
>>>> *after* my test classes setup_method.
>>>>
>>>>
>>>> I though expect that a session fixture is executed also before a
>>>> classes setup_method (use case: fixture sets up DB, setup_method sets up
>>>> some tables);
>>>>
>>>>
>>>> Am I wrong?
>>>>
>>>>
>>>> Jens
>>>>
>>>>
>>>>
>>>> On 09/25/2014 01:18 PM, Anatoly Bubenkov wrote:
>>>>
>>>> please upload fully reproducable small example somewhere
>>>> or, ideally, create a test and have a PR with it
>>>>
>>>> On 25 September 2014 13:14, Jens Hoffmann <jh at solute.de> wrote:
>>>>
>>>>>  Yes, the directories test and test/module all contain a __init__.py;
>>>>> sorry, that I didnt mention this important info.
>>>>>
>>>>> So from your question I guess that you expect py.test to find and
>>>>> execute conftest.py in all the cases shown?
>>>>>
>>>>>
>>>>> Jens
>>>>>
>>>>>
>>>>>
>>>>> On 09/25/2014 01:09 PM, Anatoly Bubenkov wrote:
>>>>>
>>>>> did you add __init__.py in all folders?
>>>>>
>>>>> On 25 September 2014 12:35, Jens Hoffmann <jh at solute.de> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>> we are working with pytest 2.6.2 and I run into a problem with my
>>>>>> conftest session fixture setup.
>>>>>>
>>>>>> My project structure looks something like this:
>>>>>>
>>>>>> .
>>>>>> ??? project
>>>>>> ? ??? module
>>>>>> ? ??? foo.py
>>>>>> ??? test
>>>>>> ??? conftest.py
>>>>>> ??? module
>>>>>> ??? test_foo.py
>>>>>>
>>>>>>
>>>>>> conftest.py contains a single fixture with scope="session" and
>>>>>> autouse=True, setting up some database that is needed for every single
>>>>>> unittest. So also test_foo.py depends on that database setup.
>>>>>>
>>>>>> Now some py.test runs:
>>>>>>
>>>>>> $ py.test
>>>>>> => conftest.py called, database setup properly, tests pass
>>>>>>
>>>>>> $ py.test test/module
>>>>>> => tests fail, fixture in conftest.py not executed
>>>>>>
>>>>>> $ py.test test/module/test_foo.py
>>>>>> => tests fail, fixture in conftest.py not executed
>>>>>>
>>>>>> $ py.test -k MyTestClassContainedInTestFooDotPy
>>>>>> => tests fail, fixture in conftest.py not executed
>>>>>>
>>>>>>
>>>>>> Now my question/problem: Are all these outcoms expected behaviour? I
>>>>>> hoped that all the runs would pass, that is execute my session fixture so
>>>>>> that I wont need to always run my whole test suite.
>>>>>>
>>>>>>
>>>>>> Thank you for your answer,
>>>>>> Jens
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pytest-dev mailing list
>>>>>> Pytest-dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/pytest-dev
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  --
>>>>> Anatoly Bubenkov
>>>>>
>>>>>
>>>>>   --
>>>>> Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute
>>>>> gmbh Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24
>>>>> <%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 - 86956-66
>>>>> <%2B49%20%280%29721%20-%2086956-66> E-Mail: rsc at solute.de Web:
>>>>> http://www.billiger.de Gesch?ftsf?hrer: Lorenz Petersen Sitz:
>>>>> Karlsruhe Registergericht: Amtsgericht Mannheim Registernummer: HRB 110579
>>>>> Umsatzsteueridentifikationsnummer: DE234663798
>>>>> http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>>>>>
>>>>
>>>>
>>>>
>>>>  --
>>>> Anatoly Bubenkov
>>>>
>>>>
>>>> --
>>>> Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute
>>>> gmbh Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24
>>>> <%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 - 86956-66
>>>> <%2B49%20%280%29721%20-%2086956-66> E-Mail: rsc at solute.de Web:
>>>> http://www.billiger.de Gesch?ftsf?hrer: Lorenz Petersen Sitz:
>>>> Karlsruhe Registergericht: Amtsgericht Mannheim Registernummer: HRB 110579
>>>> Umsatzsteueridentifikationsnummer: DE234663798
>>>> http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>>>>
>>>
>>>
>>>
>>>  --
>>> Anatoly Bubenkov
>>>
>>>
>>> --
>>> Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute gmbh
>>> Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24
>>> <%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 - 86956-66
>>> <%2B49%20%280%29721%20-%2086956-66> E-Mail: rsc at solute.de Web:
>>> http://www.billiger.de Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe
>>> Registergericht: Amtsgericht Mannheim Registernummer: HRB 110579
>>> Umsatzsteueridentifikationsnummer: DE234663798
>>> http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>>>
>>
>>
>>
>>  --
>> Anatoly Bubenkov
>>
>>
>> --
>> Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute gmbh
>> Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24
>> <%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 - 86956-66
>> <%2B49%20%280%29721%20-%2086956-66> E-Mail: rsc at solute.de Web:
>> http://www.billiger.de Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe
>> Registergericht: Amtsgericht Mannheim Registernummer: HRB 110579
>> Umsatzsteueridentifikationsnummer: DE234663798
>> http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>>
>
>
>
>  --
> Anatoly Bubenkov
>
>
> --
> Jens Hoffmann Softwareentwickler billiger.de solute gmbh
> _______________________________________________________________
> jh at solute.de http://www.billiger.de http://www.solute.de
> _______________________________________________________________ Office
> Karlsruhe Zeppelinstra?e 15 D-76185 Karlsruhe Tel: ... Fax: ...
> _______________________________________________________________
> Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe Registergericht:
> Amtsgericht Mannheim Registernummer: HRB 110579
> Umsatzsteueridentifikationsnummer: DE234663798
>



-- 
Anatoly Bubenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140925/19f90702/attachment-0001.html>

From jh at solute.de  Thu Sep 25 14:31:20 2014
From: jh at solute.de (Jens Hoffmann)
Date: Thu, 25 Sep 2014 14:31:20 +0200
Subject: [pytest-dev] top-level conftest.py not recognized when running
 tests in sub-directories
In-Reply-To: <CACTnz+GqYcyeQUj4KKCR+6EVhd_RbcvtPM9edSgtAdNwehMo6w@mail.gmail.com>
References: <5423EFED.30208@solute.de>	<CACTnz+HZP4Tox0kJz1DKNt3G+SsoZ2vfkGzu452C9jxnRAP9Xw@mail.gmail.com>	<5423F900.9040606@solute.de>	<CACTnz+HWGDeGFuOfQ7m1iB7B+S4JUuh0N0c4yFzsUmmTn5Qdgw@mail.gmail.com>	<54240427.4060009@solute.de>	<CACTnz+FFACo7a+uKH6YkQ6EVHzWRjiHR8ZHt08JkgQ9fi4Vp4g@mail.gmail.com>	<54240533.7080408@solute.de>	<CACTnz+E-jpBJkg=HDioegN+Opc0g-K2-n5uhdpD3s3+_VF3Xtw@mail.gmail.com>	<5424087D.8050202@solute.de>
 <CACTnz+GqYcyeQUj4KKCR+6EVhd_RbcvtPM9edSgtAdNwehMo6w@mail.gmail.com>
Message-ID: <54240B18.4050509@solute.de>

Okay, I clearly get what Guido said, but I say: let the folks do what 
they want to! pytest now kind of forces me to think like Guido;


Jens



On 09/25/2014 02:23 PM, Anatoly Bubenkov wrote:
> exactly, just throw away all those classes - Guido said, classes are 
> NOT namespaces
> you might only need classes for the polymorphism, but it's no-use in 
> the tests
>
> On 25 September 2014 14:20, Jens Hoffmann <jh at solute.de 
> <mailto:jh at solute.de>> wrote:
>
>     This gives me a little pain, since I always liked to organize my
>     tests OO-like, with classes etc; the docs call pytest fixtures:
>     explicit, modular, scalable; but for me "decorating classes and
>     methods" is a tiny bit of magic that forces me to leave the pure
>     OO way and to think a little more functional;
>
>
>     Jens
>
>
>
>     On 09/25/2014 02:09 PM, Anatoly Bubenkov wrote:
>>     the thing is, fixtures have proper dependency injection working
>>     but combing them with oldish setup_ methods doesn't always work
>>     properly out of the box - just because it's impossible to
>>     determine the 'right' order, because there's no 'right' order,
>>     it's all up to you to determine the dependency tree
>>
>>     On 25 September 2014 14:06, Jens Hoffmann <jh at solute.de
>>     <mailto:jh at solute.de>> wrote:
>>
>>         okay, I'll kill them... thank you for your quick responses
>>
>>
>>
>>         On 09/25/2014 02:03 PM, Anatoly Bubenkov wrote:
>>>         setup_ methods should just die :)
>>>         use fixtures everywhere instead
>>>
>>>         On 25 September 2014 14:01, Jens Hoffmann <jh at solute.de
>>>         <mailto:jh at solute.de>> wrote:
>>>
>>>             Okay, writing the example I found out what the actual
>>>             problem is:
>>>
>>>
>>>             In the minimal example the fixture *is* executed, before
>>>             any test but *after* my test classes setup_method.
>>>
>>>
>>>             I though expect that a session fixture is executed also
>>>             before a classes setup_method (use case: fixture sets up
>>>             DB, setup_method sets up some tables);
>>>
>>>
>>>             Am I wrong?
>>>
>>>
>>>             Jens
>>>
>>>
>>>
>>>             On 09/25/2014 01:18 PM, Anatoly Bubenkov wrote:
>>>>             please upload fully reproducable small example somewhere
>>>>             or, ideally, create a test and have a PR with it
>>>>
>>>>             On 25 September 2014 13:14, Jens Hoffmann <jh at solute.de
>>>>             <mailto:jh at solute.de>> wrote:
>>>>
>>>>                 Yes, the directories test and test/module all
>>>>                 contain a __init__.py; sorry, that I didnt mention
>>>>                 this important info.
>>>>
>>>>                 So from your question I guess that you expect
>>>>                 py.test to find and execute conftest.py in all the
>>>>                 cases shown?
>>>>
>>>>
>>>>                 Jens
>>>>
>>>>
>>>>
>>>>                 On 09/25/2014 01:09 PM, Anatoly Bubenkov wrote:
>>>>>                 did you add __init__.py in all folders?
>>>>>
>>>>>                 On 25 September 2014 12:35, Jens Hoffmann
>>>>>                 <jh at solute.de <mailto:jh at solute.de>> wrote:
>>>>>
>>>>>                     Hi,
>>>>>
>>>>>
>>>>>                     we are working with pytest 2.6.2 and I run
>>>>>                     into a problem with my conftest session
>>>>>                     fixture setup.
>>>>>
>>>>>                     My project structure looks something like this:
>>>>>
>>>>>                     .
>>>>>                     ??? project
>>>>>                     ? ??? module
>>>>>                     ? ??? foo.py
>>>>>                     ??? test
>>>>>                     ??? conftest.py
>>>>>                     ??? module
>>>>>                     ??? test_foo.py
>>>>>
>>>>>
>>>>>                     conftest.py contains a single fixture with
>>>>>                     scope="session" and autouse=True, setting up
>>>>>                     some database that is needed for every single
>>>>>                     unittest. So also test_foo.py depends on that
>>>>>                     database setup.
>>>>>
>>>>>                     Now some py.test runs:
>>>>>
>>>>>                     $ py.test
>>>>>                     => conftest.py called, database setup
>>>>>                     properly, tests pass
>>>>>
>>>>>                     $ py.test test/module
>>>>>                     => tests fail, fixture in conftest.py not executed
>>>>>
>>>>>                     $ py.test test/module/test_foo.py
>>>>>                     => tests fail, fixture in conftest.py not executed
>>>>>
>>>>>                     $ py.test -k MyTestClassContainedInTestFooDotPy
>>>>>                     => tests fail, fixture in conftest.py not executed
>>>>>
>>>>>
>>>>>                     Now my question/problem: Are all these outcoms
>>>>>                     expected behaviour? I hoped that all the runs
>>>>>                     would pass, that is execute my session fixture
>>>>>                     so that I wont need to always run my whole
>>>>>                     test suite.
>>>>>
>>>>>
>>>>>                     Thank you for your answer,
>>>>>                     Jens
>>>>>
>>>>>                     _______________________________________________
>>>>>                     Pytest-dev mailing list
>>>>>                     Pytest-dev at python.org
>>>>>                     <mailto:Pytest-dev at python.org>
>>>>>                     https://mail.python.org/mailman/listinfo/pytest-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                 -- 
>>>>>                 Anatoly Bubenkov
>>>>
>>>>                 -- 
>>>>                 Jens Hoffmann Softwareentwickler Datamanagement
>>>>                 billiger.de <http://billiger.de> solute gmbh
>>>>                 Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721
>>>>                 - 86956-24 <tel:%2B49%20%280%29721%20-%2086956-24>
>>>>                 Fax: +49 (0)721 - 86956-66
>>>>                 <tel:%2B49%20%280%29721%20-%2086956-66> E-Mail:
>>>>                 rsc at solute.de <mailto:rsc at solute.de> Web:
>>>>                 http://www.billiger.de Gesch?ftsf?hrer: Lorenz
>>>>                 Petersen Sitz: Karlsruhe Registergericht:
>>>>                 Amtsgericht Mannheim Registernummer: HRB 110579
>>>>                 Umsatzsteueridentifikationsnummer: DE234663798
>>>>                 http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>>>>
>>>>
>>>>
>>>>
>>>>             -- 
>>>>             Anatoly Bubenkov
>>>
>>>             -- 
>>>             Jens Hoffmann Softwareentwickler Datamanagement
>>>             billiger.de <http://billiger.de> solute gmbh
>>>             Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 -
>>>             86956-24 <tel:%2B49%20%280%29721%20-%2086956-24> Fax:
>>>             +49 (0)721 - 86956-66
>>>             <tel:%2B49%20%280%29721%20-%2086956-66> E-Mail:
>>>             rsc at solute.de <mailto:rsc at solute.de> Web:
>>>             http://www.billiger.de Gesch?ftsf?hrer: Lorenz Petersen
>>>             Sitz: Karlsruhe Registergericht: Amtsgericht Mannheim
>>>             Registernummer: HRB 110579
>>>             Umsatzsteueridentifikationsnummer: DE234663798
>>>             http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>>>
>>>
>>>
>>>
>>>         -- 
>>>         Anatoly Bubenkov
>>
>>         -- 
>>         Jens Hoffmann Softwareentwickler Datamanagement billiger.de
>>         <http://billiger.de> solute gmbh Zeppelinstra?e 15 D-76185
>>         Karlsruhe Tel: +49 (0)721 - 86956-24
>>         <tel:%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 -
>>         86956-66 <tel:%2B49%20%280%29721%20-%2086956-66> E-Mail:
>>         rsc at solute.de <mailto:rsc at solute.de> Web:
>>         http://www.billiger.de Gesch?ftsf?hrer: Lorenz Petersen Sitz:
>>         Karlsruhe Registergericht: Amtsgericht Mannheim
>>         Registernummer: HRB 110579 Umsatzsteueridentifikationsnummer:
>>         DE234663798
>>         http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>>
>>
>>
>>
>>     -- 
>>     Anatoly Bubenkov
>
>     -- 
>     Jens Hoffmann Softwareentwickler Datamanagement billiger.de
>     <http://billiger.de> solute gmbh Zeppelinstra?e 15 D-76185
>     Karlsruhe Tel: +49 (0)721 - 86956-24
>     <tel:%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 - 86956-66
>     <tel:%2B49%20%280%29721%20-%2086956-66> E-Mail: rsc at solute.de
>     <mailto:rsc at solute.de> Web: http://www.billiger.de
>     Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe Registergericht:
>     Amtsgericht Mannheim Registernummer: HRB 110579
>     Umsatzsteueridentifikationsnummer: DE234663798
>     http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>
>
>
>
> -- 
> Anatoly Bubenkov

-- 
Jens Hoffmann Softwareentwickler billiger.de solute gmbh 
_______________________________________________________________ 
jh at solute.de http://www.billiger.de http://www.solute.de 
_______________________________________________________________ Office 
Karlsruhe Zeppelinstra?e 15 D-76185 Karlsruhe Tel: ... Fax: ... 
_______________________________________________________________ 
Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe Registergericht: 
Amtsgericht Mannheim Registernummer: HRB 110579 
Umsatzsteueridentifikationsnummer: DE234663798
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140925/7e904f27/attachment-0001.html>

From holger at merlinux.eu  Thu Sep 25 14:59:37 2014
From: holger at merlinux.eu (holger krekel)
Date: Thu, 25 Sep 2014 12:59:37 +0000
Subject: [pytest-dev] Is it valid to use --boxed with --capture=no?
In-Reply-To: <1411641595.1010982.171604221.64B3B114@webmail.messagingengine.com>
References: <1411632415.975429.171562001.3CDC66F9@webmail.messagingengine.com>
 <20140925091916.GW7954@merlinux.eu>
 <1411641595.1010982.171604221.64B3B114@webmail.messagingengine.com>
Message-ID: <20140925125937.GX7954@merlinux.eu>

Hi David,

On Thu, Sep 25, 2014 at 11:39 +0100, David R?thlisberger wrote:
> Hi Holger, thanks for your quick response.
> 
> > > Is it valid to use --boxed with --capture=no? It fails with
> > > UnicodeEncodeError. More details at
> > > https://bitbucket.org/hpk42/pytest/issue/573
> >
> > In any case, could you please update the issue using the latest 
> > pytest-2.6.3 and pytest-xdist-1.11?
> 
> Done. The issue remains the same.
>
> > Do you need to timestamp the captured output as one big thing or per line?
> 
> I add a timestamp to each line, similar to the "ts" utility from
> moreutils[1] but in-process in python.
> 
> I do this by "dup2"ing stdout & stderr to a a named pipe. There's a
> thread reading from the pipe, timestamping each line and writing it to
> a logfile.
> 
> [1] http://manpages.ubuntu.com/manpages/trusty/man1/ts.1.html
> 
> 
> > Could you give a somewhat real-life example of what you would like to
> > customize in a pytest run?
> 
> This may be more detail than you care about, but here goes:
> 
> Stb-tester tests set-top boxes by capturing video from the set-top box
> (using video-capture hardware) and sending infrared signals to the
> set-top box (using a usb infrared emitter). The user's tests are written
> in python.
> 
> With pytest I have a function-scope fixture that passes in an object
> that the user's test can use to access the video-processing and
> infrared-control functions.
> 
> For each test run I also make a video recording of the set-top box's
> output. The timestamps in the log allow the user to correlate the logs
> to particular points in the video.
> 
> The user can also capture other logs during a test run (for example logs
> from processes running on the set-top box itself) so the timestamps are
> also necessary to correlate these logs with stb-tester's logs of what
> the test script is doing.
> 
> I'd like to be able to capture (and timestamp) any stdout & stderr
> output written by the user's script. If this turns out to be too hard I
> could provide the user's script a function like "stb_tester.log(...)"
> which does the timestamping and writes to a file, but that would be an
> incompatible break for my users -- their scripts currently use "print"
> for logging, and unless they change their scripts that logging would be
> lost when they upgrade stb-tester to the new version that uses pytest.

Thanks for the good explanation.  If designed anew i'd indeed suggest
to use a "log" fixture like this:

    def test_some_video(log):
        log("hello")

If it's really "print" that is used and shall be used in the future, you
might also overwrite sys.stdout with an object that does the
timestamping.  Capturing at file descriptor level is only neccessary
if you have C code writing to FD1 or start subprocesses which write out.

> I need to use "--boxed" to run each test in a different process, because
> very occasionally I get segfaults from the video-capture and
> image-processing libraries that I use, and I don't want that to bring
> down the rest of the tests.

With pytest-xdist-1.11 you can also run things with "py.test -n1" now which is
faster and will restart a crashed process if neccessary.  I expect "--boxed"
to be removed if "py.test -n1" proves to be a sufficient.

best,
holger

From holger at merlinux.eu  Thu Sep 25 15:17:01 2014
From: holger at merlinux.eu (holger krekel)
Date: Thu, 25 Sep 2014 13:17:01 +0000
Subject: [pytest-dev] top-level conftest.py not recognized when running
 tests in sub-directories
In-Reply-To: <54240427.4060009@solute.de>
References: <5423EFED.30208@solute.de>
 <CACTnz+HZP4Tox0kJz1DKNt3G+SsoZ2vfkGzu452C9jxnRAP9Xw@mail.gmail.com>
 <5423F900.9040606@solute.de>
 <CACTnz+HWGDeGFuOfQ7m1iB7B+S4JUuh0N0c4yFzsUmmTn5Qdgw@mail.gmail.com>
 <54240427.4060009@solute.de>
Message-ID: <20140925131701.GZ7954@merlinux.eu>

On Thu, Sep 25, 2014 at 14:01 +0200, Jens Hoffmann wrote:
> Okay, writing the example I found out what the actual problem is:
> 
> 
> In the minimal example the fixture *is* executed, before any test
> but *after* my test classes setup_method.
> 
> I though expect that a session fixture is executed also before a
> classes setup_method (use case: fixture sets up DB, setup_method
> sets up some tables);
> 
> 
> Am I wrong?

Your expectation is reasonable.  There also is 
https://bitbucket.org/hpk42/pytest/issue/517/setup_-executed-before-all-fixtures

I think the best way to fix it is to re-implement how xUnit setup
methods are called.  Currently pytest has special code that detects
and calls them independently of its own more general fixture system.

There is one straightforward solution to re-implement setup* functions
in terms of autouse fixtures.  Via "request.function", "request.cls", 
"request.module" you have access to the objects that have 
setup_module|class|method or setUp{Class}/setUpModule/...  methods
and can call the methods, register finalizers as neccessary.

The less straightforward but more efficient solution is to parse
setup* functions at the same time when we parse the "@pytest.fixture"
functions and add them as fixtures.  If no setup* functions are found
anywhere, there would be no overhead.  The previous solution add a
constant overhead as xUnit-fixtures would be checked for at each 
function function.

best,
holger



> 
> Jens
> 
> 
> On 09/25/2and 014 01:18 PM, Anatoly Bubenkov wrote:
> >please upload fully reproducable small example somewhere
> >or, ideally, create a test and have a PR with it
> >
> >On 25 September 2014 13:14, Jens Hoffmann <jh at solute.de
> ><mailto:jh at solute.de>> wrote:
> >
> >    Yes, the directories test and test/module all contain a
> >    __init__.py; sorry, that I didnt mention this important info.
> >
> >    So from your question I guess that you expect py.test to find and
> >    execute conftest.py in all the cases shown?
> >
> >
> >    Jens
> >
> >
> >
> >    On 09/25/2014 01:09 PM, Anatoly Bubenkov wrote:
> >>    did you add __init__.py in all folders?
> >>
> >>    On 25 September 2014 12:35, Jens Hoffmann <jh at solute.de
> >>    <mailto:jh at solute.de>> wrote:
> >>
> >>        Hi,
> >>
> >>
> >>        we are working with pytest 2.6.2 and I run into a problem
> >>        with my conftest session fixture setup.
> >>
> >>        My project structure looks something like this:
> >>
> >>        .
> >>        ??? project
> >>        ? ??? module
> >>        ? ??? foo.py
> >>        ??? test
> >>        ??? conftest.py
> >>        ??? module
> >>        ??? test_foo.py
> >>
> >>
> >>        conftest.py contains a single fixture with scope="session"
> >>        and autouse=True, setting up some database that is needed for
> >>        every single unittest. So also test_foo.py depends on that
> >>        database setup.
> >>
> >>        Now some py.test runs:
> >>
> >>        $ py.test
> >>        => conftest.py called, database setup properly, tests pass
> >>
> >>        $ py.test test/module
> >>        => tests fail, fixture in conftest.py not executed
> >>
> >>        $ py.test test/module/test_foo.py
> >>        => tests fail, fixture in conftest.py not executed
> >>
> >>        $ py.test -k MyTestClassContainedInTestFooDotPy
> >>        => tests fail, fixture in conftest.py not executed
> >>
> >>
> >>        Now my question/problem: Are all these outcoms expected
> >>        behaviour? I hoped that all the runs would pass, that is
> >>        execute my session fixture so that I wont need to always run
> >>        my whole test suite.
> >>
> >>
> >>        Thank you for your answer,
> >>        Jens
> >>
> >>        _______________________________________________
> >>        Pytest-dev mailing list
> >>        Pytest-dev at python.org <mailto:Pytest-dev at python.org>
> >>        https://mail.python.org/mailman/listinfo/pytest-dev
> >>
> >>
> >>
> >>
> >>    --     Anatoly Bubenkov
> >
> >    --     Jens Hoffmann Softwareentwickler Datamanagement
> >billiger.de
> >    <http://billiger.de> solute gmbh Zeppelinstra?e 15 D-76185
> >    Karlsruhe Tel: +49 (0)721 - 86956-24
> >    <tel:%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 - 86956-66
> >    <tel:%2B49%20%280%29721%20-%2086956-66> E-Mail: rsc at solute.de
> >    <mailto:rsc at solute.de> Web: http://www.billiger.de
> >    Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe Registergericht:
> >    Amtsgericht Mannheim Registernummer: HRB 110579
> >    Umsatzsteueridentifikationsnummer: DE234663798
> >    http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
> >
> >
> >
> >
> >-- 
> >Anatoly Bubenkov
> 
> -- 
> Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute
> gmbh Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24
> Fax: +49 (0)721 - 86956-66 E-Mail: rsc at solute.de Web:
> http://www.billiger.de Gesch?ftsf?hrer: Lorenz Petersen Sitz:
> Karlsruhe Registergericht: Amtsgericht Mannheim Registernummer: HRB
> 110579 Umsatzsteueridentifikationsnummer: DE234663798 http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png

> _______________________________________________
> Pytest-dev mailing list
> Pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev


From flub at devork.be  Fri Sep 26 23:15:51 2014
From: flub at devork.be (Floris Bruynooghe)
Date: Fri, 26 Sep 2014 22:15:51 +0100
Subject: [pytest-dev] top-level conftest.py not recognized when running
 tests in sub-directories
In-Reply-To: <5424087D.8050202@solute.de>
References: <5423EFED.30208@solute.de>
 <CACTnz+HZP4Tox0kJz1DKNt3G+SsoZ2vfkGzu452C9jxnRAP9Xw@mail.gmail.com>
 <5423F900.9040606@solute.de>
 <CACTnz+HWGDeGFuOfQ7m1iB7B+S4JUuh0N0c4yFzsUmmTn5Qdgw@mail.gmail.com>
 <54240427.4060009@solute.de>
 <CACTnz+FFACo7a+uKH6YkQ6EVHzWRjiHR8ZHt08JkgQ9fi4Vp4g@mail.gmail.com>
 <54240533.7080408@solute.de>
 <CACTnz+E-jpBJkg=HDioegN+Opc0g-K2-n5uhdpD3s3+_VF3Xtw@mail.gmail.com>
 <5424087D.8050202@solute.de>
Message-ID: <CAAWk_Dy3exPsONAZ1MffxbKegKLPHmmk+DNyYfA8p_ZARdD_GQ@mail.gmail.com>

So I'll give an alternative opinion and say that I don't mind using classes
as namespaces for py.test. The simple migration path away from
.setup_method() is to create an autouse fixture in the class instead.
On 25 Sep 2014 13:21, "Jens Hoffmann" <jh at solute.de> wrote:

>  This gives me a little pain, since I always liked to organize my tests
> OO-like, with classes etc; the docs call pytest fixtures: explicit,
> modular, scalable; but for me "decorating classes and methods" is a tiny
> bit of magic that forces me to leave the pure OO way and to think a little
> more functional;
>
>
> Jens
>
>
> On 09/25/2014 02:09 PM, Anatoly Bubenkov wrote:
>
> the thing is, fixtures have proper dependency injection working
> but combing them with oldish setup_ methods doesn't always work properly
> out of the box - just because it's impossible to determine the 'right'
> order, because there's no 'right' order, it's all up to you to determine
> the dependency tree
>
> On 25 September 2014 14:06, Jens Hoffmann <jh at solute.de> wrote:
>
>>  okay, I'll kill them... thank you for your quick responses
>>
>>
>>
>> On 09/25/2014 02:03 PM, Anatoly Bubenkov wrote:
>>
>> setup_ methods should just die :)
>> use fixtures everywhere instead
>>
>> On 25 September 2014 14:01, Jens Hoffmann <jh at solute.de> wrote:
>>
>>>  Okay, writing the example I found out what the actual problem is:
>>>
>>>
>>> In the minimal example the fixture *is* executed, before any test but
>>> *after* my test classes setup_method.
>>>
>>>
>>> I though expect that a session fixture is executed also before a classes
>>> setup_method (use case: fixture sets up DB, setup_method sets up some
>>> tables);
>>>
>>>
>>> Am I wrong?
>>>
>>>
>>> Jens
>>>
>>>
>>>
>>> On 09/25/2014 01:18 PM, Anatoly Bubenkov wrote:
>>>
>>> please upload fully reproducable small example somewhere
>>> or, ideally, create a test and have a PR with it
>>>
>>> On 25 September 2014 13:14, Jens Hoffmann <jh at solute.de> wrote:
>>>
>>>>  Yes, the directories test and test/module all contain a __init__.py;
>>>> sorry, that I didnt mention this important info.
>>>>
>>>> So from your question I guess that you expect py.test to find and
>>>> execute conftest.py in all the cases shown?
>>>>
>>>>
>>>> Jens
>>>>
>>>>
>>>>
>>>> On 09/25/2014 01:09 PM, Anatoly Bubenkov wrote:
>>>>
>>>> did you add __init__.py in all folders?
>>>>
>>>> On 25 September 2014 12:35, Jens Hoffmann <jh at solute.de> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>> we are working with pytest 2.6.2 and I run into a problem with my
>>>>> conftest session fixture setup.
>>>>>
>>>>> My project structure looks something like this:
>>>>>
>>>>> .
>>>>> ??? project
>>>>> ? ??? module
>>>>> ? ??? foo.py
>>>>> ??? test
>>>>> ??? conftest.py
>>>>> ??? module
>>>>> ??? test_foo.py
>>>>>
>>>>>
>>>>> conftest.py contains a single fixture with scope="session" and
>>>>> autouse=True, setting up some database that is needed for every single
>>>>> unittest. So also test_foo.py depends on that database setup.
>>>>>
>>>>> Now some py.test runs:
>>>>>
>>>>> $ py.test
>>>>> => conftest.py called, database setup properly, tests pass
>>>>>
>>>>> $ py.test test/module
>>>>> => tests fail, fixture in conftest.py not executed
>>>>>
>>>>> $ py.test test/module/test_foo.py
>>>>> => tests fail, fixture in conftest.py not executed
>>>>>
>>>>> $ py.test -k MyTestClassContainedInTestFooDotPy
>>>>> => tests fail, fixture in conftest.py not executed
>>>>>
>>>>>
>>>>> Now my question/problem: Are all these outcoms expected behaviour? I
>>>>> hoped that all the runs would pass, that is execute my session fixture so
>>>>> that I wont need to always run my whole test suite.
>>>>>
>>>>>
>>>>> Thank you for your answer,
>>>>> Jens
>>>>>
>>>>> _______________________________________________
>>>>> Pytest-dev mailing list
>>>>> Pytest-dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/pytest-dev
>>>>>
>>>>
>>>>
>>>>
>>>>  --
>>>> Anatoly Bubenkov
>>>>
>>>>
>>>>   --
>>>> Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute
>>>> gmbh Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24
>>>> <%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 - 86956-66
>>>> <%2B49%20%280%29721%20-%2086956-66> E-Mail: rsc at solute.de Web:
>>>> http://www.billiger.de Gesch?ftsf?hrer: Lorenz Petersen Sitz:
>>>> Karlsruhe Registergericht: Amtsgericht Mannheim Registernummer: HRB 110579
>>>> Umsatzsteueridentifikationsnummer: DE234663798
>>>> http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>>>>
>>>
>>>
>>>
>>>  --
>>> Anatoly Bubenkov
>>>
>>>
>>> --
>>> Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute gmbh
>>> Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24
>>> <%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 - 86956-66
>>> <%2B49%20%280%29721%20-%2086956-66> E-Mail: rsc at solute.de Web:
>>> http://www.billiger.de Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe
>>> Registergericht: Amtsgericht Mannheim Registernummer: HRB 110579
>>> Umsatzsteueridentifikationsnummer: DE234663798
>>> http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>>>
>>
>>
>>
>>  --
>> Anatoly Bubenkov
>>
>>
>> --
>> Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute gmbh
>> Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24
>> <%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 - 86956-66
>> <%2B49%20%280%29721%20-%2086956-66> E-Mail: rsc at solute.de Web:
>> http://www.billiger.de Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe
>> Registergericht: Amtsgericht Mannheim Registernummer: HRB 110579
>> Umsatzsteueridentifikationsnummer: DE234663798
>> http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>>
>
>
>
>  --
> Anatoly Bubenkov
>
>
> --
> Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute gmbh
> Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24 Fax: +49
> (0)721 - 86956-66 E-Mail: rsc at solute.de Web: http://www.billiger.de
> Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe Registergericht:
> Amtsgericht Mannheim Registernummer: HRB 110579
> Umsatzsteueridentifikationsnummer: DE234663798
> http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>
> _______________________________________________
> Pytest-dev mailing list
> Pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140926/4634db15/attachment-0001.html>

From bubenkoff at gmail.com  Fri Sep 26 23:17:07 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Fri, 26 Sep 2014 23:17:07 +0200
Subject: [pytest-dev] top-level conftest.py not recognized when running
 tests in sub-directories
In-Reply-To: <CAAWk_Dy3exPsONAZ1MffxbKegKLPHmmk+DNyYfA8p_ZARdD_GQ@mail.gmail.com>
References: <5423EFED.30208@solute.de>
 <CACTnz+HZP4Tox0kJz1DKNt3G+SsoZ2vfkGzu452C9jxnRAP9Xw@mail.gmail.com>
 <5423F900.9040606@solute.de>
 <CACTnz+HWGDeGFuOfQ7m1iB7B+S4JUuh0N0c4yFzsUmmTn5Qdgw@mail.gmail.com>
 <54240427.4060009@solute.de>
 <CACTnz+FFACo7a+uKH6YkQ6EVHzWRjiHR8ZHt08JkgQ9fi4Vp4g@mail.gmail.com>
 <54240533.7080408@solute.de>
 <CACTnz+E-jpBJkg=HDioegN+Opc0g-K2-n5uhdpD3s3+_VF3Xtw@mail.gmail.com>
 <5424087D.8050202@solute.de>
 <CAAWk_Dy3exPsONAZ1MffxbKegKLPHmmk+DNyYfA8p_ZARdD_GQ@mail.gmail.com>
Message-ID: <CACTnz+Fn43qRiwF+kTLKm+zuAcquwj79rALfz6_LzHwVyYFEtw@mail.gmail.com>

+1 probably the simplest in this case

On 26 September 2014 23:15, Floris Bruynooghe <flub at devork.be> wrote:

> So I'll give an alternative opinion and say that I don't mind using
> classes as namespaces for py.test. The simple migration path away from
> .setup_method() is to create an autouse fixture in the class instead.
> On 25 Sep 2014 13:21, "Jens Hoffmann" <jh at solute.de> wrote:
>
>>  This gives me a little pain, since I always liked to organize my tests
>> OO-like, with classes etc; the docs call pytest fixtures: explicit,
>> modular, scalable; but for me "decorating classes and methods" is a tiny
>> bit of magic that forces me to leave the pure OO way and to think a little
>> more functional;
>>
>>
>> Jens
>>
>>
>> On 09/25/2014 02:09 PM, Anatoly Bubenkov wrote:
>>
>> the thing is, fixtures have proper dependency injection working
>> but combing them with oldish setup_ methods doesn't always work properly
>> out of the box - just because it's impossible to determine the 'right'
>> order, because there's no 'right' order, it's all up to you to determine
>> the dependency tree
>>
>> On 25 September 2014 14:06, Jens Hoffmann <jh at solute.de> wrote:
>>
>>>  okay, I'll kill them... thank you for your quick responses
>>>
>>>
>>>
>>> On 09/25/2014 02:03 PM, Anatoly Bubenkov wrote:
>>>
>>> setup_ methods should just die :)
>>> use fixtures everywhere instead
>>>
>>> On 25 September 2014 14:01, Jens Hoffmann <jh at solute.de> wrote:
>>>
>>>>  Okay, writing the example I found out what the actual problem is:
>>>>
>>>>
>>>> In the minimal example the fixture *is* executed, before any test but
>>>> *after* my test classes setup_method.
>>>>
>>>>
>>>> I though expect that a session fixture is executed also before a
>>>> classes setup_method (use case: fixture sets up DB, setup_method sets up
>>>> some tables);
>>>>
>>>>
>>>> Am I wrong?
>>>>
>>>>
>>>> Jens
>>>>
>>>>
>>>>
>>>> On 09/25/2014 01:18 PM, Anatoly Bubenkov wrote:
>>>>
>>>> please upload fully reproducable small example somewhere
>>>> or, ideally, create a test and have a PR with it
>>>>
>>>> On 25 September 2014 13:14, Jens Hoffmann <jh at solute.de> wrote:
>>>>
>>>>>  Yes, the directories test and test/module all contain a __init__.py;
>>>>> sorry, that I didnt mention this important info.
>>>>>
>>>>> So from your question I guess that you expect py.test to find and
>>>>> execute conftest.py in all the cases shown?
>>>>>
>>>>>
>>>>> Jens
>>>>>
>>>>>
>>>>>
>>>>> On 09/25/2014 01:09 PM, Anatoly Bubenkov wrote:
>>>>>
>>>>> did you add __init__.py in all folders?
>>>>>
>>>>> On 25 September 2014 12:35, Jens Hoffmann <jh at solute.de> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>> we are working with pytest 2.6.2 and I run into a problem with my
>>>>>> conftest session fixture setup.
>>>>>>
>>>>>> My project structure looks something like this:
>>>>>>
>>>>>> .
>>>>>> ??? project
>>>>>> ? ??? module
>>>>>> ? ??? foo.py
>>>>>> ??? test
>>>>>> ??? conftest.py
>>>>>> ??? module
>>>>>> ??? test_foo.py
>>>>>>
>>>>>>
>>>>>> conftest.py contains a single fixture with scope="session" and
>>>>>> autouse=True, setting up some database that is needed for every single
>>>>>> unittest. So also test_foo.py depends on that database setup.
>>>>>>
>>>>>> Now some py.test runs:
>>>>>>
>>>>>> $ py.test
>>>>>> => conftest.py called, database setup properly, tests pass
>>>>>>
>>>>>> $ py.test test/module
>>>>>> => tests fail, fixture in conftest.py not executed
>>>>>>
>>>>>> $ py.test test/module/test_foo.py
>>>>>> => tests fail, fixture in conftest.py not executed
>>>>>>
>>>>>> $ py.test -k MyTestClassContainedInTestFooDotPy
>>>>>> => tests fail, fixture in conftest.py not executed
>>>>>>
>>>>>>
>>>>>> Now my question/problem: Are all these outcoms expected behaviour? I
>>>>>> hoped that all the runs would pass, that is execute my session fixture so
>>>>>> that I wont need to always run my whole test suite.
>>>>>>
>>>>>>
>>>>>> Thank you for your answer,
>>>>>> Jens
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pytest-dev mailing list
>>>>>> Pytest-dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/pytest-dev
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  --
>>>>> Anatoly Bubenkov
>>>>>
>>>>>
>>>>>   --
>>>>> Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute
>>>>> gmbh Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24
>>>>> <%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 - 86956-66
>>>>> <%2B49%20%280%29721%20-%2086956-66> E-Mail: rsc at solute.de Web:
>>>>> http://www.billiger.de Gesch?ftsf?hrer: Lorenz Petersen Sitz:
>>>>> Karlsruhe Registergericht: Amtsgericht Mannheim Registernummer: HRB 110579
>>>>> Umsatzsteueridentifikationsnummer: DE234663798
>>>>> http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>>>>>
>>>>
>>>>
>>>>
>>>>  --
>>>> Anatoly Bubenkov
>>>>
>>>>
>>>> --
>>>> Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute
>>>> gmbh Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24
>>>> <%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 - 86956-66
>>>> <%2B49%20%280%29721%20-%2086956-66> E-Mail: rsc at solute.de Web:
>>>> http://www.billiger.de Gesch?ftsf?hrer: Lorenz Petersen Sitz:
>>>> Karlsruhe Registergericht: Amtsgericht Mannheim Registernummer: HRB 110579
>>>> Umsatzsteueridentifikationsnummer: DE234663798
>>>> http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>>>>
>>>
>>>
>>>
>>>  --
>>> Anatoly Bubenkov
>>>
>>>
>>> --
>>> Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute gmbh
>>> Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24
>>> <%2B49%20%280%29721%20-%2086956-24> Fax: +49 (0)721 - 86956-66
>>> <%2B49%20%280%29721%20-%2086956-66> E-Mail: rsc at solute.de Web:
>>> http://www.billiger.de Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe
>>> Registergericht: Amtsgericht Mannheim Registernummer: HRB 110579
>>> Umsatzsteueridentifikationsnummer: DE234663798
>>> http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>>>
>>
>>
>>
>>  --
>> Anatoly Bubenkov
>>
>>
>> --
>> Jens Hoffmann Softwareentwickler Datamanagement billiger.de solute gmbh
>> Zeppelinstra?e 15 D-76185 Karlsruhe Tel: +49 (0)721 - 86956-24 Fax: +49
>> (0)721 - 86956-66 E-Mail: rsc at solute.de Web: http://www.billiger.de
>> Gesch?ftsf?hrer: Lorenz Petersen Sitz: Karlsruhe Registergericht:
>> Amtsgericht Mannheim Registernummer: HRB 110579
>> Umsatzsteueridentifikationsnummer: DE234663798
>> http://cdn.billiger.com/static/mail/billiger_today_logo_dunkel_20140911.png
>>
>> _______________________________________________
>> Pytest-dev mailing list
>> Pytest-dev at python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>
>>


-- 
Anatoly Bubenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140926/95627142/attachment-0001.html>

From nicoddemus at gmail.com  Sun Sep 28 22:46:00 2014
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Sun, 28 Sep 2014 17:46:00 -0300
Subject: [pytest-dev] Hook validation difference between conftest files and
	plugins
Message-ID: <CA+RQFfcUiMw2cB2tW2wPMXhHuzR58oeh_6hnsFCBsb5bKFihZw@mail.gmail.com>

Hi everyone,

I'm having some trouble when trying to use some of xdist-defined hooks in a
plugin, but I believe this problem is not related to xdist specifically.

If I redefine a few of `xdist`'s hook functions inside a conftest file, it
works fine. Once I move them to an external plugin however, I start getting
"found unknown hook" errors.

Here is an example:

    # contents of conftest.py
    def pytest_configure_node(node):
        assert 0, 'configure_node called'

    # contents of test_foo.py
    def test_foo(): pass

In a fresh virtual environment with `pytest-xdist` installed:


    $ py.test -n2
    <snip traceback>
    INTERNALERROR> AssertionError: configure_node called

OK, that's what I expected.

On the other hand, renaming `conftest.py` to `myplugin.py`:

    $ py.test -n2 -p myplugin
        raise PluginValidationError("%s:\n%s" % (name, stringio.getvalue()))
    _pytest.helpconfig.PluginValidationError: myplugin:
    found unknown hook: pytest_configure_node

(You might have to configure your $PYTHONPATH to the working directory)

The same happens if I make a plugin using setup.py/setuptools.

Am I missing something, or is this a bug?

Digging at the source a bit I found that plugin registration and hook
validation happen one right after the other, which might be a problem
because a plugin might depend on hooks that will be registered by other
plugins later.

Cheers,
Bruno.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140928/348d2120/attachment.html>

From bubenkoff at gmail.com  Sun Sep 28 23:38:47 2014
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Sun, 28 Sep 2014 23:38:47 +0200
Subject: [pytest-dev] Hook validation difference between conftest files
 and plugins
In-Reply-To: <CA+RQFfcUiMw2cB2tW2wPMXhHuzR58oeh_6hnsFCBsb5bKFihZw@mail.gmail.com>
References: <CA+RQFfcUiMw2cB2tW2wPMXhHuzR58oeh_6hnsFCBsb5bKFihZw@mail.gmail.com>
Message-ID: <CACTnz+E4NCBiv2AJnGT1u=OgHWp-g_9QzEzYUNuMKzMP0eMyqg@mail.gmail.com>

I had the same problem
solved it by 'deferring' a plugin hook a bit:

https://github.com/pytest-dev/pytest-splinter/blob/master/pytest_splinter/plugin.py#L333

On 28 September 2014 22:46, Bruno Oliveira <nicoddemus at gmail.com> wrote:

> Hi everyone,
>
> I'm having some trouble when trying to use some of xdist-defined hooks in
> a plugin, but I believe this problem is not related to xdist specifically.
>
> If I redefine a few of `xdist`'s hook functions inside a conftest file, it
> works fine. Once I move them to an external plugin however, I start getting
> "found unknown hook" errors.
>
> Here is an example:
>
>     # contents of conftest.py
>     def pytest_configure_node(node):
>         assert 0, 'configure_node called'
>
>     # contents of test_foo.py
>     def test_foo(): pass
>
> In a fresh virtual environment with `pytest-xdist` installed:
>
>
>     $ py.test -n2
>     <snip traceback>
>     INTERNALERROR> AssertionError: configure_node called
>
> OK, that's what I expected.
>
> On the other hand, renaming `conftest.py` to `myplugin.py`:
>
>     $ py.test -n2 -p myplugin
>         raise PluginValidationError("%s:\n%s" % (name,
> stringio.getvalue()))
>     _pytest.helpconfig.PluginValidationError: myplugin:
>     found unknown hook: pytest_configure_node
>
> (You might have to configure your $PYTHONPATH to the working directory)
>
> The same happens if I make a plugin using setup.py/setuptools.
>
> Am I missing something, or is this a bug?
>
> Digging at the source a bit I found that plugin registration and hook
> validation happen one right after the other, which might be a problem
> because a plugin might depend on hooks that will be registered by other
> plugins later.
>
> Cheers,
> Bruno.
>
> _______________________________________________
> Pytest-dev mailing list
> Pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>


-- 
Anatoly Bubenkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140928/32dc4333/attachment.html>

From holger at merlinux.eu  Mon Sep 29 08:47:29 2014
From: holger at merlinux.eu (holger krekel)
Date: Mon, 29 Sep 2014 06:47:29 +0000
Subject: [pytest-dev] Hook validation difference between conftest files
 and plugins
In-Reply-To: <CA+RQFfcUiMw2cB2tW2wPMXhHuzR58oeh_6hnsFCBsb5bKFihZw@mail.gmail.com>
References: <CA+RQFfcUiMw2cB2tW2wPMXhHuzR58oeh_6hnsFCBsb5bKFihZw@mail.gmail.com>
Message-ID: <20140929064729.GJ7954@merlinux.eu>

Hi Bruno, Anatoly,

On Sun, Sep 28, 2014 at 17:46 -0300, Bruno Oliveira wrote:
> Hi everyone,
> 
> I'm having some trouble when trying to use some of xdist-defined hooks in a
> plugin, but I believe this problem is not related to xdist specifically.
> 
> If I redefine a few of `xdist`'s hook functions inside a conftest file, it
> works fine. Once I move them to an external plugin however, I start getting
> "found unknown hook" errors.
> 
> Here is an example:
> 
>     # contents of conftest.py
>     def pytest_configure_node(node):
>         assert 0, 'configure_node called'
> 
>     # contents of test_foo.py
>     def test_foo(): pass
> 
> In a fresh virtual environment with `pytest-xdist` installed:
> 
> 
>     $ py.test -n2
>     <snip traceback>
>     INTERNALERROR> AssertionError: configure_node called
> 
> OK, that's what I expected.
> 
> On the other hand, renaming `conftest.py` to `myplugin.py`:
> 
>     $ py.test -n2 -p myplugin
>         raise PluginValidationError("%s:\n%s" % (name, stringio.getvalue()))
>     _pytest.helpconfig.PluginValidationError: myplugin:
>     found unknown hook: pytest_configure_node
> 
> (You might have to configure your $PYTHONPATH to the working directory)
> 
> The same happens if I make a plugin using setup.py/setuptools.
> 
> Am I missing something, or is this a bug?
> 
> Digging at the source a bit I found that plugin registration and hook
> validation happen one right after the other, which might be a problem
> because a plugin might depend on hooks that will be registered by other
> plugins later.

You are right.  We could do it differently by first calling pytest_addhooks
on all plugins before calling the pytest_registered hook.  But Anatoly's
solution (deferring registration to pytest_configure) has the additional
advantage that you can conditionally register plugins.  You might register
differently (or not at all) if there is no xdist installed, for example.
So currently i think it's best to just add an example to the docs.

best,
holge



> Cheers,
> Bruno.

> _______________________________________________
> Pytest-dev mailing list
> Pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev


From david at stb-tester.com  Mon Sep 29 10:25:56 2014
From: david at stb-tester.com (=?ISO-8859-1?Q?David=20R=F6thlisberger?=)
Date: Mon, 29 Sep 2014 09:25:56 +0100
Subject: [pytest-dev] Is it valid to use --boxed with --capture=no?
In-Reply-To: <20140925125937.GX7954@merlinux.eu>
References: <1411632415.975429.171562001.3CDC66F9@webmail.messagingengine.com>
 <20140925091916.GW7954@merlinux.eu>
 <1411641595.1010982.171604221.64B3B114@webmail.messagingengine.com>
 <20140925125937.GX7954@merlinux.eu>
Message-ID: <1411979156.2650037.172845269.19467A39@webmail.messagingengine.com>

On Thu, Sep 25, 2014, at 01:59 PM, holger krekel wrote:
> > I need to use "--boxed" to run each test in a different process, because
> > very occasionally I get segfaults from the video-capture and
> > image-processing libraries that I use, and I don't want that to bring
> > down the rest of the tests.
> 
> With pytest-xdist-1.11 you can also run things with "py.test -n1" now which is
> faster and will restart a crashed process if neccessary.  I expect "--boxed"
> to be removed if "py.test -n1" proves to be a sufficient.

"-n1" doesn't suffer from the same UnicodeEncodeError that "--boxed"
suffers from, but it doesn't run each test in a separate process (and it
turns out that I need each test run in a different process for other
reasons related to the way I capture video from the system under test).
So for now I'll switch to using a separate function for logging, instead
of capturing std{out,err}.

Thanks,
Dave.

From holger at merlinux.eu  Mon Sep 29 10:30:04 2014
From: holger at merlinux.eu (holger krekel)
Date: Mon, 29 Sep 2014 08:30:04 +0000
Subject: [pytest-dev] Is it valid to use --boxed with --capture=no?
In-Reply-To: <1411979156.2650037.172845269.19467A39@webmail.messagingengine.com>
References: <1411632415.975429.171562001.3CDC66F9@webmail.messagingengine.com>
 <20140925091916.GW7954@merlinux.eu>
 <1411641595.1010982.171604221.64B3B114@webmail.messagingengine.com>
 <20140925125937.GX7954@merlinux.eu>
 <1411979156.2650037.172845269.19467A39@webmail.messagingengine.com>
Message-ID: <20140929083004.GO7954@merlinux.eu>

On Mon, Sep 29, 2014 at 09:25 +0100, David R?thlisberger wrote:
> On Thu, Sep 25, 2014, at 01:59 PM, holger krekel wrote:
> > > I need to use "--boxed" to run each test in a different process, because
> > > very occasionally I get segfaults from the video-capture and
> > > image-processing libraries that I use, and I don't want that to bring
> > > down the rest of the tests.
> > 
> > With pytest-xdist-1.11 you can also run things with "py.test -n1" now which is
> > faster and will restart a crashed process if neccessary.  I expect "--boxed"
> > to be removed if "py.test -n1" proves to be a sufficient.
> 
> "-n1" doesn't suffer from the same UnicodeEncodeError that "--boxed"
> suffers from, but it doesn't run each test in a separate process (and it
> turns out that I need each test run in a different process for other
> reasons related to the way I capture video from the system under test).
> So for now I'll switch to using a separate function for logging, instead
> of capturing std{out,err}.

I see.  The output capturing with pytest is not very configurable and
there are no particular hooks related to it.  If it's clear what would
be needed it could be implemented without much effort i guess.
Then again, running with "-s" and implementing your own capturing
fixtures (possibly with autouse=True) would also work.

best,
holger

From holger at merlinux.eu  Mon Sep 29 12:29:42 2014
From: holger at merlinux.eu (holger krekel)
Date: Mon, 29 Sep 2014 10:29:42 +0000
Subject: [pytest-dev] removed outdated japanese docs
Message-ID: <20140929102942.GR7954@merlinux.eu>

Hi all,

i just removed the japanese documentation because it's just a
translation of the english docs a the time of the pytest-2.2 release.
So it's more misleading now than helpful.  Also i am not convinced a
test tool used by software developers should care much for non-english TBH.
If you disagree and/or would like to maintain the japanese docs, please tell! 

There still remain available at http://pytest.org/latest-ja for the time
being.

best,
holger


From nicoddemus at gmail.com  Mon Sep 29 12:56:01 2014
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Mon, 29 Sep 2014 07:56:01 -0300
Subject: [pytest-dev] Hook validation difference between conftest files
 and plugins
In-Reply-To: <20140929064729.GJ7954@merlinux.eu>
References: <CA+RQFfcUiMw2cB2tW2wPMXhHuzR58oeh_6hnsFCBsb5bKFihZw@mail.gmail.com>
 <20140929064729.GJ7954@merlinux.eu>
Message-ID: <CA+RQFferkfGLjyuOy5uRLf5VZQxWY3JaqXhnoDjOuZK-ocrRqw@mail.gmail.com>

Hi Anatoly, Holger,

On Sun, Sep 28, 2014 at 6:38 PM, Anatoly Bubenkov <bubenkoff at gmail.com>
 wrote:
> I had the same problem solved it by 'deferring' a plugin hook a bit:

Thanks! I will use this approach.


On Mon, Sep 29, 2014 at 3:47 AM, holger krekel <holger at merlinux.eu> wrote:
> So currently i think it's best to just add an example to the docs.

OK, I will open a PR with an example targeted to plugin developers.

Thanks for the help!

Cheers,


On Mon, Sep 29, 2014 at 3:47 AM, holger krekel <holger at merlinux.eu> wrote:

> Hi Bruno, Anatoly,
>
> On Sun, Sep 28, 2014 at 17:46 -0300, Bruno Oliveira wrote:
> > Hi everyone,
> >
> > I'm having some trouble when trying to use some of xdist-defined hooks
> in a
> > plugin, but I believe this problem is not related to xdist specifically.
> >
> > If I redefine a few of `xdist`'s hook functions inside a conftest file,
> it
> > works fine. Once I move them to an external plugin however, I start
> getting
> > "found unknown hook" errors.
> >
> > Here is an example:
> >
> >     # contents of conftest.py
> >     def pytest_configure_node(node):
> >         assert 0, 'configure_node called'
> >
> >     # contents of test_foo.py
> >     def test_foo(): pass
> >
> > In a fresh virtual environment with `pytest-xdist` installed:
> >
> >
> >     $ py.test -n2
> >     <snip traceback>
> >     INTERNALERROR> AssertionError: configure_node called
> >
> > OK, that's what I expected.
> >
> > On the other hand, renaming `conftest.py` to `myplugin.py`:
> >
> >     $ py.test -n2 -p myplugin
> >         raise PluginValidationError("%s:\n%s" % (name,
> stringio.getvalue()))
> >     _pytest.helpconfig.PluginValidationError: myplugin:
> >     found unknown hook: pytest_configure_node
> >
> > (You might have to configure your $PYTHONPATH to the working directory)
> >
> > The same happens if I make a plugin using setup.py/setuptools.
> >
> > Am I missing something, or is this a bug?
> >
> > Digging at the source a bit I found that plugin registration and hook
> > validation happen one right after the other, which might be a problem
> > because a plugin might depend on hooks that will be registered by other
> > plugins later.
>
> You are right.  We could do it differently by first calling pytest_addhooks
> on all plugins before calling the pytest_registered hook.  But Anatoly's
> solution (deferring registration to pytest_configure) has the additional
> advantage that you can conditionally register plugins.  You might register
> differently (or not at all) if there is no xdist installed, for example.
> So currently i think it's best to just add an example to the docs.
>
> best,
> holge
>
>
>
> > Cheers,
> > Bruno.
>
> > _______________________________________________
> > Pytest-dev mailing list
> > Pytest-dev at python.org
> > https://mail.python.org/mailman/listinfo/pytest-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140929/10336d8b/attachment.html>

From david at stb-tester.com  Mon Sep 29 13:16:24 2014
From: david at stb-tester.com (=?ISO-8859-1?Q?David=20R=F6thlisberger?=)
Date: Mon, 29 Sep 2014 12:16:24 +0100
Subject: [pytest-dev] Is it valid to use --boxed with --capture=no?
In-Reply-To: <20140929083004.GO7954@merlinux.eu>
References: <1411632415.975429.171562001.3CDC66F9@webmail.messagingengine.com>
 <20140925091916.GW7954@merlinux.eu>
 <1411641595.1010982.171604221.64B3B114@webmail.messagingengine.com>
 <20140925125937.GX7954@merlinux.eu>
 <1411979156.2650037.172845269.19467A39@webmail.messagingengine.com>
 <20140929083004.GO7954@merlinux.eu>
Message-ID: <1411989384.2689684.172904249.01356B45@webmail.messagingengine.com>



On Mon, Sep 29, 2014, at 09:30 AM, holger krekel wrote:
> On Mon, Sep 29, 2014 at 09:25 +0100, David R?thlisberger wrote:
> > On Thu, Sep 25, 2014, at 01:59 PM, holger krekel wrote:
> > > > I need to use "--boxed" to run each test in a different process, because
> > > > very occasionally I get segfaults from the video-capture and
> > > > image-processing libraries that I use, and I don't want that to bring
> > > > down the rest of the tests.
> > > 
> > > With pytest-xdist-1.11 you can also run things with "py.test -n1" now which is
> > > faster and will restart a crashed process if neccessary.  I expect "--boxed"
> > > to be removed if "py.test -n1" proves to be a sufficient.
> > 
> > "-n1" doesn't suffer from the same UnicodeEncodeError that "--boxed"
> > suffers from, but it doesn't run each test in a separate process (and it
> > turns out that I need each test run in a different process for other
> > reasons related to the way I capture video from the system under test).
> > So for now I'll switch to using a separate function for logging, instead
> > of capturing std{out,err}.
> 
> I see.  The output capturing with pytest is not very configurable and
> there are no particular hooks related to it.  If it's clear what would
> be needed it could be implemented without much effort i guess.
> Then again, running with "-s" and implementing your own capturing
> fixtures (possibly with autouse=True) would also work.

My *actual* issue (and I realise now that I never actually mentioned
this in the thread) was that I had implemented my own capturing fixtures
but *even with my own fixtures* and "-s" (aka "--capture=no"), I was
getting UnicodeEncodeError from py/_process/forkedfunc.py.

However I can no longer reproduce this after upgrading from pytest 2.?.?
and xdist 1.? on Mac OS X, to pytest 2.6.3 and xdist 1.11 on Linux
(Ubuntu 14.04).

To be clear, I was not asking for any additional configurability to be
added to pytest; and my use case is now working as I want it to. I'll
leave it to your discretion whether Issue #573 is worth keeping open for
the case of "-s" without custom capturing fixtures.

Thanks again,
Dave.

From ayelet at fabrixsystems.com  Mon Sep 29 15:09:11 2014
From: ayelet at fabrixsystems.com (Ayelet Regev)
Date: Mon, 29 Sep 2014 16:09:11 +0300
Subject: [pytest-dev] running py-test setup without actual running the tests
 and their tear down
Message-ID: <542959F7.3070803@fabrixsystems.com>

Hi,

I wish to allow --validate_only option to my py.test plugin.
i want the ability to run many checks without actually running the 
pytest_runtest_call and pytest_runtest_teardown.
What is the best approach?

-- 
Best Regards,

Ayelet Regev Dabah
Email: ayelet at fabrixsystems.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20140929/537d5302/attachment.html>