From holger at merlinux.eu  Sat Nov  2 07:39:22 2013
From: holger at merlinux.eu (holger krekel)
Date: Sat, 2 Nov 2013 06:39:22 +0000
Subject: [pytest-dev] next pytest bug day (doodle)
Message-ID: <20131102063922.GX3973@merlinux.eu>

Hi all,

here is a doodle for arranging for the next pytest bug day.  Please
list yourself on the days you could at least partially participate:

    http://doodle.com/dz4nk5q4arib8y97

I am going to pick and announce the final day with the most participants.

best,
holger

From nicoddemus at gmail.com  Wed Nov  6 20:22:41 2013
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Wed, 6 Nov 2013 17:22:41 -0200
Subject: [pytest-dev] plugin status page
In-Reply-To: <20131030104213.GR3973@merlinux.eu>
References: <20131014203230.GX14010@merlinux.eu>
 <CA+RQFffNquqMpo-eNapVi2e+NCirUHj8UVa8dmQ4kYrcFAgBcw@mail.gmail.com>
 <20131020055219.GB19953@merlinux.eu>
 <CA+RQFffbcOVn=inAr43CXqnAge36_pvGLvTZfFqwVH9VRz1ZXg@mail.gmail.com>
 <CA+RQFfdDbVsyRUadv9bpa5Li7ET5THozxCwnc1eHWFp02jjhyg@mail.gmail.com>
 <20131024065255.GU3973@merlinux.eu>
 <CA+RQFfeJs96zOPw_=xLaWgCkxkaukJHNUOV44zkT=S4a9kMdxA@mail.gmail.com>
 <20131024135827.GW3973@merlinux.eu>
 <CA+RQFfei38wtpzd_Y2_xOdeg_i31mp1t=bhnnnOzxFiEGwiEAQ@mail.gmail.com>
 <20131024203935.GY3973@merlinux.eu> <20131030104213.GR3973@merlinux.eu>
Message-ID: <CA+RQFfeeUdA9shWCOD5eg2yV3KrYVMazmHvjGONpxM+GS6dy-g@mail.gmail.com>

Hi Holger, all,

Back from vacation, so I'm back to this. :)

On Wed, Oct 30, 2013 at 8:42 AM, holger krekel <holger at merlinux.eu> wrote:
>
> I just did devpi-*-1.2 releases.  If you install devpi-client>=1.2
> you get "devpi test --fallback-ini someini".  Hope it helps.
>

Works great, thanks. I'm keeping a branch "devpi" on pytest-plugs for this.
You can see one of the build results here:

https://travis-ci.org/nicoddemus/pytest-plugs/builds/13596968

It basically installs a devpi server using "quickstart" and issues a series
of "devpi test" commands. Neat.

One question:

1) Is there any way to overwrite the pytest version to use for running
"devpi test"? This is required if we want to test against different pytest
versions.

Cheers,
Bruno.


> best,
> holger
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20131106/47b6ac04/attachment.html>

From holger at merlinux.eu  Fri Nov  8 07:04:16 2013
From: holger at merlinux.eu (holger krekel)
Date: Fri, 8 Nov 2013 06:04:16 +0000
Subject: [pytest-dev] plugin status page
In-Reply-To: <CA+RQFfeeUdA9shWCOD5eg2yV3KrYVMazmHvjGONpxM+GS6dy-g@mail.gmail.com>
References: <20131020055219.GB19953@merlinux.eu>
 <CA+RQFffbcOVn=inAr43CXqnAge36_pvGLvTZfFqwVH9VRz1ZXg@mail.gmail.com>
 <CA+RQFfdDbVsyRUadv9bpa5Li7ET5THozxCwnc1eHWFp02jjhyg@mail.gmail.com>
 <20131024065255.GU3973@merlinux.eu>
 <CA+RQFfeJs96zOPw_=xLaWgCkxkaukJHNUOV44zkT=S4a9kMdxA@mail.gmail.com>
 <20131024135827.GW3973@merlinux.eu>
 <CA+RQFfei38wtpzd_Y2_xOdeg_i31mp1t=bhnnnOzxFiEGwiEAQ@mail.gmail.com>
 <20131024203935.GY3973@merlinux.eu>
 <20131030104213.GR3973@merlinux.eu>
 <CA+RQFfeeUdA9shWCOD5eg2yV3KrYVMazmHvjGONpxM+GS6dy-g@mail.gmail.com>
Message-ID: <20131108060416.GI3973@merlinux.eu>

Hi Bruno,

On Wed, Nov 06, 2013 at 17:22 -0200, Bruno Oliveira wrote:
> Hi Holger, all,
> 
> Back from vacation, so I'm back to this. :)
> 
> On Wed, Oct 30, 2013 at 8:42 AM, holger krekel <holger at merlinux.eu> wrote:
> >
> > I just did devpi-*-1.2 releases.  If you install devpi-client>=1.2
> > you get "devpi test --fallback-ini someini".  Hope it helps.
> >
> 
> Works great, thanks. I'm keeping a branch "devpi" on pytest-plugs for this.
> You can see one of the build results here:
> 
> https://travis-ci.org/nicoddemus/pytest-plugs/builds/13596968
> 
> It basically installs a devpi server using "quickstart" and issues a series
> of "devpi test" commands. Neat.
> 
> One question:
> 
> 1) Is there any way to overwrite the pytest version to use for running
> "devpi test"? This is required if we want to test against different pytest
> versions.

From "devpi test" there is no way currently other than passing in a
custom tox.ini.  We could think about adding an option to tox but it is
not clear how that would look like.  Maybe we could assume that
the tox.ini that is being used has certain environments that would
pin a pytest version.  It is then a matter of reading out the
"toxresults" that are posted to devpi after the tests have run.  
(you also see the result of reading that out from "devpi list X".
There is no API documentation how to read it out but the code
doing it is contained in devpi_client/list_remove.py (it's basically
performing some http json requests).
Our own "--fallback-ini" could of course pin pytest versions as well.

best,
holger

> Cheers,
> Bruno.
> 
> 
> > best,
> > holger
> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20131108/c1da441c/attachment.sig>

From nicoddemus at gmail.com  Fri Nov  8 13:58:19 2013
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Fri, 8 Nov 2013 10:58:19 -0200
Subject: [pytest-dev] plugin status page
In-Reply-To: <20131108060416.GI3973@merlinux.eu>
References: <20131020055219.GB19953@merlinux.eu>
 <CA+RQFffbcOVn=inAr43CXqnAge36_pvGLvTZfFqwVH9VRz1ZXg@mail.gmail.com>
 <CA+RQFfdDbVsyRUadv9bpa5Li7ET5THozxCwnc1eHWFp02jjhyg@mail.gmail.com>
 <20131024065255.GU3973@merlinux.eu>
 <CA+RQFfeJs96zOPw_=xLaWgCkxkaukJHNUOV44zkT=S4a9kMdxA@mail.gmail.com>
 <20131024135827.GW3973@merlinux.eu>
 <CA+RQFfei38wtpzd_Y2_xOdeg_i31mp1t=bhnnnOzxFiEGwiEAQ@mail.gmail.com>
 <20131024203935.GY3973@merlinux.eu> <20131030104213.GR3973@merlinux.eu>
 <CA+RQFfeeUdA9shWCOD5eg2yV3KrYVMazmHvjGONpxM+GS6dy-g@mail.gmail.com>
 <20131108060416.GI3973@merlinux.eu>
Message-ID: <CA+RQFfd8y85LM4nxrX8b239xNwjaynUy20=Q_3kg58DXPDLjiQ@mail.gmail.com>

Hi Holger,

On Fri, Nov 8, 2013 at 4:04 AM, holger krekel <holger at merlinux.eu> wrote:

> From "devpi test" there is no way currently other than passing in a
> custom tox.ini.  We could think about adding an option to tox but it is
> not clear how that would look like.  Maybe we could assume that
> the tox.ini that is being used has certain environments that would
> pin a pytest version.  It is then a matter of reading out the
> "toxresults" that are posted to devpi after the tests have run.
> (you also see the result of reading that out from "devpi list X".
> There is no API documentation how to read it out but the code
> doing it is contained in devpi_client/list_remove.py (it's basically
> performing some http json requests).
> Our own "--fallback-ini" could of course pin pytest versions as well.


Hmm, I just realized that tox uses the latest pytest version, not the one I
have installed in the environment it is running (which makes sense). This
means that the travis jobs for pytest 2.3.5 are actually running the tests
using 2.4.2. :)

To solve this, I guess the simplest approach would be to read the tox.ini
file and replace occurrences of plain "pytest" to "pytest==<version>" to
enforce tox to use the version we want. Don't know how/if that would play
out nicely with devpi, seems very specific for the purpose we are trying to
accomplish.

I'm finishing the page where the results are posted, at the very least we
will have a compatibility matrix of plugins against python versions and the
latest pytest version. Once I finish this (probably today) I will let you
know so you can take a look.

Best Regards,
Bruno.


>
> > Cheers,
> > Bruno.
> >
> >
> > > best,
> > > holger
> > >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEcBAEBAgAGBQJSfH7gAAoJEI47A6J5t3LWypAH+wU9c8FtDhrZqZQ+cZ33dgvD
> meYzYwKPsuZ8Xe/OGRPteroD/PugdYy1ewPg3C7VPLdKHMsL1FLR89D4rY3yqjX0
> CVS7f9O1mQaauQ83bB0F/YwMajZgcahoUyIZn5q5GSdTr+DWHqUhvIyJtJ4ykysK
> 5MvaVBkSEj8Bx1ZGdOQtWSRo0CdURceQ8yV3jm9z24L8VlEOpAr3tCvkOhNyOcZN
> aj71mZ34hvXFjLFhRgGj3pYbU7BHumtWYPGcyCnxh2/anpX9azU3tMin1IU4Sn8L
> EH5Vorcx4bg80tDu9gOLQHcO1mro1MKPqeinoITDG4nJLndi9SM9GaZSq2+jilE=
> =GXi4
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20131108/2d79c5a7/attachment.html>

From nicoddemus at gmail.com  Fri Nov  8 22:28:38 2013
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Fri, 8 Nov 2013 19:28:38 -0200
Subject: [pytest-dev] plugin status page
In-Reply-To: <CA+RQFfd8y85LM4nxrX8b239xNwjaynUy20=Q_3kg58DXPDLjiQ@mail.gmail.com>
References: <20131020055219.GB19953@merlinux.eu>
 <CA+RQFffbcOVn=inAr43CXqnAge36_pvGLvTZfFqwVH9VRz1ZXg@mail.gmail.com>
 <CA+RQFfdDbVsyRUadv9bpa5Li7ET5THozxCwnc1eHWFp02jjhyg@mail.gmail.com>
 <20131024065255.GU3973@merlinux.eu>
 <CA+RQFfeJs96zOPw_=xLaWgCkxkaukJHNUOV44zkT=S4a9kMdxA@mail.gmail.com>
 <20131024135827.GW3973@merlinux.eu>
 <CA+RQFfei38wtpzd_Y2_xOdeg_i31mp1t=bhnnnOzxFiEGwiEAQ@mail.gmail.com>
 <20131024203935.GY3973@merlinux.eu> <20131030104213.GR3973@merlinux.eu>
 <CA+RQFfeeUdA9shWCOD5eg2yV3KrYVMazmHvjGONpxM+GS6dy-g@mail.gmail.com>
 <20131108060416.GI3973@merlinux.eu>
 <CA+RQFfd8y85LM4nxrX8b239xNwjaynUy20=Q_3kg58DXPDLjiQ@mail.gmail.com>
Message-ID: <CA+RQFfcU-QbK+yxN6=6nfOJp4W4KcSH7h1Y5wV49Av1h6jh3dg@mail.gmail.com>

On Fri, Nov 8, 2013 at 10:58 AM, Bruno Oliveira <nicoddemus at gmail.com>wrote:

> I'm finishing the page where the results are posted, at the very least we
> will have a compatibility matrix of plugins against python versions and the
> latest pytest version. Once I finish this (probably today) I will let you
> know so you can take a look.
>

I just finished a first version, please take a look:

http://pytest-plugs.herokuapp.com/

Also, an endpoint "/status/<plugin>" is available to query status images
(for an example, please see
http://pytest-plugs.herokuapp.com/status/pytest-blockage-0.1?py=py27&pytest=2.4.2).
I'm thinking we can use those URLs to embed status images for the latest
pytest version into the plugin index page, similar to the summary table at
the start of the pytest-plugs heroku app.

As I noted earlier, the tests reported for pytest-2.3.5 are actually for
2.4.2 since I didn't overwrite the environment in the tox.ini files. I will
try the approach of replacing the "pytest" dependency manually, unless you
have another suggestion.

This is the very first version, so comments are very welcome.

Cheers,


>
> Best Regards,
> Bruno.
>
>
>>
>> > Cheers,
>> > Bruno.
>> >
>> >
>> > > best,
>> > > holger
>> > >
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (GNU/Linux)
>>
>> iQEcBAEBAgAGBQJSfH7gAAoJEI47A6J5t3LWypAH+wU9c8FtDhrZqZQ+cZ33dgvD
>> meYzYwKPsuZ8Xe/OGRPteroD/PugdYy1ewPg3C7VPLdKHMsL1FLR89D4rY3yqjX0
>> CVS7f9O1mQaauQ83bB0F/YwMajZgcahoUyIZn5q5GSdTr+DWHqUhvIyJtJ4ykysK
>> 5MvaVBkSEj8Bx1ZGdOQtWSRo0CdURceQ8yV3jm9z24L8VlEOpAr3tCvkOhNyOcZN
>> aj71mZ34hvXFjLFhRgGj3pYbU7BHumtWYPGcyCnxh2/anpX9azU3tMin1IU4Sn8L
>> EH5Vorcx4bg80tDu9gOLQHcO1mro1MKPqeinoITDG4nJLndi9SM9GaZSq2+jilE=
>> =GXi4
>> -----END PGP SIGNATURE-----
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20131108/89386f91/attachment.html>

From slip76 at gmail.com  Mon Nov 11 18:56:25 2013
From: slip76 at gmail.com (Andrii Smirnov)
Date: Mon, 11 Nov 2013 19:56:25 +0200
Subject: [pytest-dev] Running finalizer in case test setup has failed
Message-ID: <CAHDVPJVixmjcCEdp2haubu7o03e2Bnkc18r_oX_jwyunYXyYWw@mail.gmail.com>

Hello All,

We have complex enough (several stages of putting the test environment into
some condition) code which should be executed in all cases regardless of
test setup result (fixture setup).

Since finalizer for fixture will not be called in case its (fixture) setup
failed we've put some calls to pytest_sessionfinish as a temporary
workaround but we need to find a way how to call finalizer code explicitly.

Could you please suggest how to achieve that?

Thank you in advance!

-Andrii
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20131111/fd4889b6/attachment.html>

From holger at merlinux.eu  Tue Nov 12 10:16:12 2013
From: holger at merlinux.eu (holger krekel)
Date: Tue, 12 Nov 2013 09:16:12 +0000
Subject: [pytest-dev] Running finalizer in case test setup has failed
In-Reply-To: <CAHDVPJVixmjcCEdp2haubu7o03e2Bnkc18r_oX_jwyunYXyYWw@mail.gmail.com>
References: <CAHDVPJVixmjcCEdp2haubu7o03e2Bnkc18r_oX_jwyunYXyYWw@mail.gmail.com>
Message-ID: <20131112091612.GA20094@merlinux.eu>

Hi Andrii,

On Mon, Nov 11, 2013 at 19:56 +0200, Andrii Smirnov wrote:
> Hello All,
> 
> We have complex enough (several stages of putting the test environment into
> some condition) code which should be executed in all cases regardless of
> test setup result (fixture setup).
> 
> Since finalizer for fixture will not be called in case its (fixture) setup
> failed we've put some calls to pytest_sessionfinish as a temporary
> workaround but we need to find a way how to call finalizer code explicitly.

Calling fixture finalizers from such a hook is hard if even possible.

But i don't understand yet why your finalizers are not run.  Take
this example::

    import pytest

    @pytest.fixture
    def fix(request):
        def fin():
            print "finalizing!"
        
        request.addfinalizer(fin)
        0/0

    def test_hello(fix):
        pass

If you run this with ``py.test -s`` you will see the ``finalizing!``
message although the fixture function fails.

If you are running xUnit-style ``setup*`` functions then indeed,
pytest is compatible to the way unittest or nose do xUnit setup:
teardownX functions are not run if a setupX function fails.
However, you can transform any such setup function into
a pytest style one by puttig a fixture-autouse decorator in front::

    @pytest.fixture(autouse=True)
    def setup_function(request):
        # as above you can register finalizers etc.

If you use the decorator you can also use other pytest fixtures
such as ``tmpdir`` or ``monkeypatch`` or your own fixtures, of course.

If both examples don't answer your question, please try to give a
code example on how things fail for you.

cheers,
holger

From holger at merlinux.eu  Tue Nov 12 10:25:33 2013
From: holger at merlinux.eu (holger krekel)
Date: Tue, 12 Nov 2013 09:25:33 +0000
Subject: [pytest-dev] plugin status page
In-Reply-To: <CA+RQFfcU-QbK+yxN6=6nfOJp4W4KcSH7h1Y5wV49Av1h6jh3dg@mail.gmail.com>
References: <20131024065255.GU3973@merlinux.eu>
 <CA+RQFfeJs96zOPw_=xLaWgCkxkaukJHNUOV44zkT=S4a9kMdxA@mail.gmail.com>
 <20131024135827.GW3973@merlinux.eu>
 <CA+RQFfei38wtpzd_Y2_xOdeg_i31mp1t=bhnnnOzxFiEGwiEAQ@mail.gmail.com>
 <20131024203935.GY3973@merlinux.eu>
 <20131030104213.GR3973@merlinux.eu>
 <CA+RQFfeeUdA9shWCOD5eg2yV3KrYVMazmHvjGONpxM+GS6dy-g@mail.gmail.com>
 <20131108060416.GI3973@merlinux.eu>
 <CA+RQFfd8y85LM4nxrX8b239xNwjaynUy20=Q_3kg58DXPDLjiQ@mail.gmail.com>
 <CA+RQFfcU-QbK+yxN6=6nfOJp4W4KcSH7h1Y5wV49Av1h6jh3dg@mail.gmail.com>
Message-ID: <20131112092533.GB20094@merlinux.eu>

Hi Bruno,

On Fri, Nov 08, 2013 at 19:28 -0200, Bruno Oliveira wrote:
> On Fri, Nov 8, 2013 at 10:58 AM, Bruno Oliveira <nicoddemus at gmail.com>wrote:
> 
> > I'm finishing the page where the results are posted, at the very least we
> > will have a compatibility matrix of plugins against python versions and the
> > latest pytest version. Once I finish this (probably today) I will let you
> > know so you can take a look.
> >
> 
> I just finished a first version, please take a look:
> 
> http://pytest-plugs.herokuapp.com/

looks good on first sight!

> Also, an endpoint "/status/<plugin>" is available to query status images
> (for an example, please see
> http://pytest-plugs.herokuapp.com/status/pytest-blockage-0.1?py=py27&pytest=2.4.2).

Works.

> I'm thinking we can use those URLs to embed status images for the latest
> pytest version into the plugin index page, similar to the summary table at
> the start of the pytest-plugs heroku app.
> 
> As I noted earlier, the tests reported for pytest-2.3.5 are actually for
> 2.4.2 since I didn't overwrite the environment in the tox.ini files. I will
> try the approach of replacing the "pytest" dependency manually, unless you
> have another suggestion.

Are the tests run via creating a ``tox.ini`` yourself, overriding any
tox.ini that might be contained with the package?

In any case, it would be useful to everyone (plugin authors, users,
pytest core devs) to see what is actually breaking (or working), i.e. 
the actual test failure/success log.  Is that available somewhere already?

cheers,
holger

> This is the very first version, so comments are very welcome.


> Cheers,
> 
> 
> >
> > Best Regards,
> > Bruno.
> >
> >
> >>
> >> > Cheers,
> >> > Bruno.
> >> >
> >> >
> >> > > best,
> >> > > holger
> >> > >
> >>
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1.4.10 (GNU/Linux)
> >>
> >> iQEcBAEBAgAGBQJSfH7gAAoJEI47A6J5t3LWypAH+wU9c8FtDhrZqZQ+cZ33dgvD
> >> meYzYwKPsuZ8Xe/OGRPteroD/PugdYy1ewPg3C7VPLdKHMsL1FLR89D4rY3yqjX0
> >> CVS7f9O1mQaauQ83bB0F/YwMajZgcahoUyIZn5q5GSdTr+DWHqUhvIyJtJ4ykysK
> >> 5MvaVBkSEj8Bx1ZGdOQtWSRo0CdURceQ8yV3jm9z24L8VlEOpAr3tCvkOhNyOcZN
> >> aj71mZ34hvXFjLFhRgGj3pYbU7BHumtWYPGcyCnxh2/anpX9azU3tMin1IU4Sn8L
> >> EH5Vorcx4bg80tDu9gOLQHcO1mro1MKPqeinoITDG4nJLndi9SM9GaZSq2+jilE=
> >> =GXi4
> >> -----END PGP SIGNATURE-----
> >>
> >>
> >

From nicoddemus at gmail.com  Wed Nov 13 01:51:42 2013
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 12 Nov 2013 22:51:42 -0200
Subject: [pytest-dev] plugin status page
In-Reply-To: <20131112092533.GB20094@merlinux.eu>
References: <20131024065255.GU3973@merlinux.eu>
 <CA+RQFfeJs96zOPw_=xLaWgCkxkaukJHNUOV44zkT=S4a9kMdxA@mail.gmail.com>
 <20131024135827.GW3973@merlinux.eu>
 <CA+RQFfei38wtpzd_Y2_xOdeg_i31mp1t=bhnnnOzxFiEGwiEAQ@mail.gmail.com>
 <20131024203935.GY3973@merlinux.eu> <20131030104213.GR3973@merlinux.eu>
 <CA+RQFfeeUdA9shWCOD5eg2yV3KrYVMazmHvjGONpxM+GS6dy-g@mail.gmail.com>
 <20131108060416.GI3973@merlinux.eu>
 <CA+RQFfd8y85LM4nxrX8b239xNwjaynUy20=Q_3kg58DXPDLjiQ@mail.gmail.com>
 <CA+RQFfcU-QbK+yxN6=6nfOJp4W4KcSH7h1Y5wV49Av1h6jh3dg@mail.gmail.com>
 <20131112092533.GB20094@merlinux.eu>
Message-ID: <CA+RQFfckqk5piTG0j0-1YSqVJ0B+oQCW6C1v09uZa2DHaPKsZQ@mail.gmail.com>

Hi Holger, all,

On Tue, Nov 12, 2013 at 7:25 AM, holger krekel <holger at merlinux.eu> wrote:

> > I'm thinking we can use those URLs to embed status images for the latest
>  > pytest version into the plugin index page, similar to the summary table
> at
> > the start of the pytest-plugs heroku app.
> >
> > As I noted earlier, the tests reported for pytest-2.3.5 are actually for
> > 2.4.2 since I didn't overwrite the environment in the tox.ini files. I
> will
> > try the approach of replacing the "pytest" dependency manually, unless
> you
> > have another suggestion.
>
> Are the tests run via creating a ``tox.ini`` yourself, overriding any
> tox.ini that might be contained with the package?
>

I'm creating a tox.ini file if there is none, or if there is already a
tox.ini inplace I try to use a simple regex to replace "pytest" occurrences
to "pytest==$PYTEST_VERSION" in an attempt to enforce the pytest version
that should be used for running the tests. This has worked for most
plugins, but some of them setup the dependencies in a slightly different
manner than what my simple regex-replace trick could handle:

* Some packages declare a specific pytest a version as dependency, like
"pytest==2.4.0" or "pytest>=2.0".
* One of the packages installed the dependencies from a requirements file,
using "-r requirements-tests.txt" instead of listing the dependencies on
the tox.ini file itself.

I could of course make my regex more complex in an attempt to cover all the
cases, but I feel this would mean a lot of duplicated work that is already
done by tox itself. Any suggestions?

In any case, it would be useful to everyone (plugin authors, users,
> pytest core devs) to see what is actually breaking (or working), i.e.
> the actual test failure/success log.  Is that available somewhere already?
>

Hmm good point. It is available from the travis-ci output log, but that is
not very friendly. I will change the travis-ci jobs to also post the
results from "tox --result-json" which contains all the details from that
test session, and make that available from the webpage as well.

So I'm thinking this should be the next steps:

1. Update plugins index page to include the status images;
2. Post test results to the pytest-plugs page and make it available from
there;
3. Find a nice way to ensure we are running "tox" with the pytest version
we want;

About 3), I just had an idea... what if we install a devpi server that
would serve only the pytest version we want (say, 2.3.5) and force tox to
use that devpi server by using the "-i" option? Would that be possible?
("Shadowed Release Files" seems to be what would be required for this to
work).

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

From holger at merlinux.eu  Wed Nov 13 08:55:36 2013
From: holger at merlinux.eu (holger krekel)
Date: Wed, 13 Nov 2013 07:55:36 +0000
Subject: [pytest-dev] plugin status page
In-Reply-To: <CA+RQFfckqk5piTG0j0-1YSqVJ0B+oQCW6C1v09uZa2DHaPKsZQ@mail.gmail.com>
References: <20131024135827.GW3973@merlinux.eu>
 <CA+RQFfei38wtpzd_Y2_xOdeg_i31mp1t=bhnnnOzxFiEGwiEAQ@mail.gmail.com>
 <20131024203935.GY3973@merlinux.eu>
 <20131030104213.GR3973@merlinux.eu>
 <CA+RQFfeeUdA9shWCOD5eg2yV3KrYVMazmHvjGONpxM+GS6dy-g@mail.gmail.com>
 <20131108060416.GI3973@merlinux.eu>
 <CA+RQFfd8y85LM4nxrX8b239xNwjaynUy20=Q_3kg58DXPDLjiQ@mail.gmail.com>
 <CA+RQFfcU-QbK+yxN6=6nfOJp4W4KcSH7h1Y5wV49Av1h6jh3dg@mail.gmail.com>
 <20131112092533.GB20094@merlinux.eu>
 <CA+RQFfckqk5piTG0j0-1YSqVJ0B+oQCW6C1v09uZa2DHaPKsZQ@mail.gmail.com>
Message-ID: <20131113075536.GG20094@merlinux.eu>

Hi Bruno,

On Tue, Nov 12, 2013 at 22:51 -0200, Bruno Oliveira wrote:
> Hi Holger, all,
> 
> On Tue, Nov 12, 2013 at 7:25 AM, holger krekel <holger at merlinux.eu> wrote:
> 
> > > I'm thinking we can use those URLs to embed status images for the latest
> >  > pytest version into the plugin index page, similar to the summary table
> > at
> > > the start of the pytest-plugs heroku app.
> > >
> > > As I noted earlier, the tests reported for pytest-2.3.5 are actually for
> > > 2.4.2 since I didn't overwrite the environment in the tox.ini files. I
> > will
> > > try the approach of replacing the "pytest" dependency manually, unless
> > you
> > > have another suggestion.
> >
> > Are the tests run via creating a ``tox.ini`` yourself, overriding any
> > tox.ini that might be contained with the package?
> >
> 
> I'm creating a tox.ini file if there is none, or if there is already a
> tox.ini inplace I try to use a simple regex to replace "pytest" occurrences
> to "pytest==$PYTEST_VERSION" in an attempt to enforce the pytest version
> that should be used for running the tests. This has worked for most
> plugins, but some of them setup the dependencies in a slightly different
> manner than what my simple regex-replace trick could handle:
> 
> * Some packages declare a specific pytest a version as dependency, like
> "pytest==2.4.0" or "pytest>=2.0".
> * One of the packages installed the dependencies from a requirements file,
> using "-r requirements-tests.txt" instead of listing the dependencies on
> the tox.ini file itself.
> 
> I could of course make my regex more complex in an attempt to cover all the
> cases, but I feel this would mean a lot of duplicated work that is already
> done by tox itself. Any suggestions?

I think we should allow instructing tox to override 
a version for a dependency.  Something like 

    tox --force-dep-version=pytest==2.4.2

This would make tox replace any "pytest" dependency that is specified
with tox itself.  It would not work for implicit dependencies 
specified within a setup.py's install_requires setting.  I guess
we should extend the result-json format to include a list of all
packages and dependencies for each environment so that we can do
a double-check after tests were run.

> In any case, it would be useful to everyone (plugin authors, users,
> > pytest core devs) to see what is actually breaking (or working), i.e.
> > the actual test failure/success log.  Is that available somewhere already?
> >
> 
> Hmm good point. It is available from the travis-ci output log, but that is
> not very friendly. I will change the travis-ci jobs to also post the
> results from "tox --result-json" which contains all the details from that
> test session, and make that available from the webpage as well.
> 
> So I'm thinking this should be the next steps:
> 
> 1. Update plugins index page to include the status images;
> 2. Post test results to the pytest-plugs page and make it available from
> there;
> 3. Find a nice way to ensure we are running "tox" with the pytest version
> we want;

makes sense.

> About 3), I just had an idea... what if we install a devpi server that
> would serve only the pytest version we want (say, 2.3.5) and force tox to
> use that devpi server by using the "-i" option? Would that be possible?
> ("Shadowed Release Files" seems to be what would be required for this to
> work).

See my suggestion above.  I think it would be more effort to do it
indirectly via devpi-server here.

cheers,
holger

> Cheers,
> Bruno.

From nicoddemus at gmail.com  Wed Nov 13 15:30:47 2013
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Wed, 13 Nov 2013 12:30:47 -0200
Subject: [pytest-dev] plugin status page
In-Reply-To: <20131113075536.GG20094@merlinux.eu>
References: <20131024135827.GW3973@merlinux.eu>
 <CA+RQFfei38wtpzd_Y2_xOdeg_i31mp1t=bhnnnOzxFiEGwiEAQ@mail.gmail.com>
 <20131024203935.GY3973@merlinux.eu> <20131030104213.GR3973@merlinux.eu>
 <CA+RQFfeeUdA9shWCOD5eg2yV3KrYVMazmHvjGONpxM+GS6dy-g@mail.gmail.com>
 <20131108060416.GI3973@merlinux.eu>
 <CA+RQFfd8y85LM4nxrX8b239xNwjaynUy20=Q_3kg58DXPDLjiQ@mail.gmail.com>
 <CA+RQFfcU-QbK+yxN6=6nfOJp4W4KcSH7h1Y5wV49Av1h6jh3dg@mail.gmail.com>
 <20131112092533.GB20094@merlinux.eu>
 <CA+RQFfckqk5piTG0j0-1YSqVJ0B+oQCW6C1v09uZa2DHaPKsZQ@mail.gmail.com>
 <20131113075536.GG20094@merlinux.eu>
Message-ID: <CA+RQFfe6yNMseVXXRBwKiNSSnKYbyVC=DFPD_uo6Uw-Nuj2oUQ@mail.gmail.com>

Hi Holger,

I think we should allow instructing tox to override
> a version for a dependency.  Something like
>
>     tox --force-dep-version=pytest==2.4.2
>
> This would make tox replace any "pytest" dependency that is specified
> with tox itself.  It would not work for implicit dependencies
> specified within a setup.py's install_requires setting.  I guess
> we should extend the result-json format to include a list of all
> packages and dependencies for each environment so that we can do
> a double-check after tests were run.
>

I agree, that seems cleaner. I will take a look at tox in order to open a
PR for that.


> > In any case, it would be useful to everyone (plugin authors, users,
> > > pytest core devs) to see what is actually breaking (or working), i.e.
> > > the actual test failure/success log.  Is that available somewhere
> already?
> > >
> >
> > Hmm good point. It is available from the travis-ci output log, but that
> is
> > not very friendly. I will change the travis-ci jobs to also post the
> > results from "tox --result-json" which contains all the details from that
> > test session, and make that available from the webpage as well.
> >
> > So I'm thinking this should be the next steps:
> >
> > 1. Update plugins index page to include the status images;
> > 2. Post test results to the pytest-plugs page and make it available from
> > there;
> > 3. Find a nice way to ensure we are running "tox" with the pytest version
> > we want;
>
> makes sense.
>
> > About 3), I just had an idea... what if we install a devpi server that
> > would serve only the pytest version we want (say, 2.3.5) and force tox to
> > use that devpi server by using the "-i" option? Would that be possible?
> > ("Shadowed Release Files" seems to be what would be required for this to
> > work).
>
> See my suggestion above.  I think it would be more effort to do it
> indirectly via devpi-server here.
>

OK, let's see how that goes. :)

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

From holger at merlinux.eu  Thu Nov 14 06:15:58 2013
From: holger at merlinux.eu (holger krekel)
Date: Thu, 14 Nov 2013 05:15:58 +0000
Subject: [pytest-dev] plugin status page
In-Reply-To: <CA+RQFfe6yNMseVXXRBwKiNSSnKYbyVC=DFPD_uo6Uw-Nuj2oUQ@mail.gmail.com>
References: <20131024203935.GY3973@merlinux.eu>
 <20131030104213.GR3973@merlinux.eu>
 <CA+RQFfeeUdA9shWCOD5eg2yV3KrYVMazmHvjGONpxM+GS6dy-g@mail.gmail.com>
 <20131108060416.GI3973@merlinux.eu>
 <CA+RQFfd8y85LM4nxrX8b239xNwjaynUy20=Q_3kg58DXPDLjiQ@mail.gmail.com>
 <CA+RQFfcU-QbK+yxN6=6nfOJp4W4KcSH7h1Y5wV49Av1h6jh3dg@mail.gmail.com>
 <20131112092533.GB20094@merlinux.eu>
 <CA+RQFfckqk5piTG0j0-1YSqVJ0B+oQCW6C1v09uZa2DHaPKsZQ@mail.gmail.com>
 <20131113075536.GG20094@merlinux.eu>
 <CA+RQFfe6yNMseVXXRBwKiNSSnKYbyVC=DFPD_uo6Uw-Nuj2oUQ@mail.gmail.com>
Message-ID: <20131114051558.GN20094@merlinux.eu>

Hi Bruno,

On Wed, Nov 13, 2013 at 12:30 -0200, Bruno Oliveira wrote:
> Hi Holger,
> 
> I think we should allow instructing tox to override
> > a version for a dependency.  Something like
> >
> >     tox --force-dep-version=pytest==2.4.2
> >
> > This would make tox replace any "pytest" dependency that is specified
> > with tox itself.  It would not work for implicit dependencies
> > specified within a setup.py's install_requires setting.  I guess
> > we should extend the result-json format to include a list of all
> > packages and dependencies for each environment so that we can do
> > a double-check after tests were run.
> >
> 
> I agree, that seems cleaner. I will take a look at tox in order to open a
> PR for that.

great, thanks!  And let me know if you get stuck on that or need help.

cheers,
holger

> > > In any case, it would be useful to everyone (plugin authors, users,
> > > > pytest core devs) to see what is actually breaking (or working), i.e.
> > > > the actual test failure/success log.  Is that available somewhere
> > already?
> > > >
> > >
> > > Hmm good point. It is available from the travis-ci output log, but that
> > is
> > > not very friendly. I will change the travis-ci jobs to also post the
> > > results from "tox --result-json" which contains all the details from that
> > > test session, and make that available from the webpage as well.
> > >
> > > So I'm thinking this should be the next steps:
> > >
> > > 1. Update plugins index page to include the status images;
> > > 2. Post test results to the pytest-plugs page and make it available from
> > > there;
> > > 3. Find a nice way to ensure we are running "tox" with the pytest version
> > > we want;
> >
> > makes sense.
> >
> > > About 3), I just had an idea... what if we install a devpi server that
> > > would serve only the pytest version we want (say, 2.3.5) and force tox to
> > > use that devpi server by using the "-i" option? Would that be possible?
> > > ("Shadowed Release Files" seems to be what would be required for this to
> > > work).
> >
> > See my suggestion above.  I think it would be more effort to do it
> > indirectly via devpi-server here.
> >
> 
> OK, let's see how that goes. :)
> 
> Cheers,
> Bruno

From holger at merlinux.eu  Thu Nov 14 06:29:11 2013
From: holger at merlinux.eu (holger krekel)
Date: Thu, 14 Nov 2013 05:29:11 +0000
Subject: [pytest-dev] pytest bugday: TUESDAY, 19th november 2013
Message-ID: <20131114052911.GO20094@merlinux.eu>

Hi all,

pytest bug day is final:

    Tuesday, 19th November
    starting 9AM UTC+1 on #pylib freenode

Let's see to package a pytest-2.4.3 containing the work of the
bug/issue-fixing day later in that week.

cheers,
holger

From dhruvabhagi at gmail.com  Thu Nov 14 07:50:59 2013
From: dhruvabhagi at gmail.com (Dhruv Bhagi)
Date: Wed, 13 Nov 2013 22:50:59 -0800
Subject: [pytest-dev] Pytest (2.3.3) is not taking arguments on
	windows-Please help
Message-ID: <CAKkotnzBwhdnnWa42_2gowwk5LOw_exAafKnQao0r7SP6rKNjA@mail.gmail.com>

Hi,
I'm relatively new to using pytest on windows. I have bunch of test files
(like test1.py, test2.py, test3.py etc in a folder tests). The goal is to
run a particular individual test <say test1.py>by running the command
'pytest test1.py'. Instead, pytest is running all the tests in the 'tests'
folder <rather than running only test1.py>. pytest is not even any
arguments <like --version, --help etc.>. If i do 'pytest --version', it
still runs all the tests in the folder.

So the problem is, pytest not parsing/taking any arguments supplied to it.
This is happening only on windows (i'm using windows7, pytest 2.3.3).
Anyone seen this before? What could be possibly wrong? (Or) what part of
the pytest code should i look at to drill down to the problem? Please
advise.

I'm kinda blocked by this. I will be greatly thankful for your help.

Thanks in advance,

Dhruv
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20131113/7580bac6/attachment.html>

From holger at merlinux.eu  Fri Nov 15 09:43:35 2013
From: holger at merlinux.eu (holger krekel)
Date: Fri, 15 Nov 2013 08:43:35 +0000
Subject: [pytest-dev] Pytest (2.3.3) is not taking arguments on
 windows-Please help
In-Reply-To: <CAKkotnzBwhdnnWa42_2gowwk5LOw_exAafKnQao0r7SP6rKNjA@mail.gmail.com>
References: <CAKkotnzBwhdnnWa42_2gowwk5LOw_exAafKnQao0r7SP6rKNjA@mail.gmail.com>
Message-ID: <20131115084335.GS20094@merlinux.eu>

Hi Dhruv,

On Wed, Nov 13, 2013 at 22:50 -0800, Dhruv Bhagi wrote:
> Hi,
> I'm relatively new to using pytest on windows. I have bunch of test files
> (like test1.py, test2.py, test3.py etc in a folder tests). The goal is to
> run a particular individual test <say test1.py>by running the command
> 'pytest test1.py'. Instead, pytest is running all the tests in the 'tests'
> folder <rather than running only test1.py>. pytest is not even any
> arguments <like --version, --help etc.>. If i do 'pytest --version', it
> still runs all the tests in the folder.
> 
> So the problem is, pytest not parsing/taking any arguments supplied to it.
> This is happening only on windows (i'm using windows7, pytest 2.3.3).
> Anyone seen this before? What could be possibly wrong? (Or) what part of
> the pytest code should i look at to drill down to the problem? Please
> advise.
> 
> I'm kinda blocked by this. I will be greatly thankful for your help.


I suspect you are using the wrong tool.  The package "pytest" installs
the "py.test" tool (mind the dot).  There also is another tool "pytest"
which is installed under a different package name (something with "logilab"
i think).  The confusion is historic -- i guess pytest could at some point
move to just provide "pytest" and "py.test".

cheers,
holger

> Thanks in advance,
> 
> Dhruv

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


From dhruvabhagi at gmail.com  Fri Nov 15 09:49:44 2013
From: dhruvabhagi at gmail.com (Dhruv Bhagi)
Date: Fri, 15 Nov 2013 00:49:44 -0800
Subject: [pytest-dev] Pytest (2.3.3) is not taking arguments on
 windows-Please help
In-Reply-To: <20131115084335.GS20094@merlinux.eu>
References: <CAKkotnzBwhdnnWa42_2gowwk5LOw_exAafKnQao0r7SP6rKNjA@mail.gmail.com>
 <20131115084335.GS20094@merlinux.eu>
Message-ID: <CAKkotny_N4k8WUQvoZ9SjcTSeGtMMXv=kRdvWFRf0=vVDLZ9ig@mail.gmail.com>

Hey Holger,
Thank you so much for the reply. I fixed this issue. There were few plugins
missing in my pytest while setting the test env. I really appreciate you
for taking your time to respond.

Thanks,
Dhruv


On Fri, Nov 15, 2013 at 12:43 AM, holger krekel <holger at merlinux.eu> wrote:

> Hi Dhruv,
>
> On Wed, Nov 13, 2013 at 22:50 -0800, Dhruv Bhagi wrote:
> > Hi,
> > I'm relatively new to using pytest on windows. I have bunch of test files
> > (like test1.py, test2.py, test3.py etc in a folder tests). The goal is to
> > run a particular individual test <say test1.py>by running the command
> > 'pytest test1.py'. Instead, pytest is running all the tests in the
> 'tests'
> > folder <rather than running only test1.py>. pytest is not even any
> > arguments <like --version, --help etc.>. If i do 'pytest --version', it
> > still runs all the tests in the folder.
> >
> > So the problem is, pytest not parsing/taking any arguments supplied to
> it.
> > This is happening only on windows (i'm using windows7, pytest 2.3.3).
> > Anyone seen this before? What could be possibly wrong? (Or) what part of
> > the pytest code should i look at to drill down to the problem? Please
> > advise.
> >
> > I'm kinda blocked by this. I will be greatly thankful for your help.
>
>
> I suspect you are using the wrong tool.  The package "pytest" installs
> the "py.test" tool (mind the dot).  There also is another tool "pytest"
> which is installed under a different package name (something with "logilab"
> i think).  The confusion is historic -- i guess pytest could at some point
> move to just provide "pytest" and "py.test".
>
> cheers,
> holger
>
> > Thanks in advance,
> >
> > Dhruv
>
> > _______________________________________________
> > Pytest-dev mailing list
> > Pytest-dev at python.org
> > https://mail.python.org/mailman/listinfo/pytest-dev
>
>


-- 
with regards,
Dhruva Kumar Bhagi,
641 Old county road, # 203,
Belmont, CA
94002.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20131115/e8de1499/attachment.html>

From holger at merlinux.eu  Mon Nov 18 12:44:28 2013
From: holger at merlinux.eu (holger krekel)
Date: Mon, 18 Nov 2013 11:44:28 +0000
Subject: [pytest-dev] pytest bug day tomorrow / stackoverflow / bitbucket
Message-ID: <20131118114428.GC11363@merlinux.eu>

Hi all,

1. tomorrow is pytest bug day. I'll be online 9am CET on IRC #pylib
   and hope to be there for most of the day and some in the evening.
   We'll do a little etherpad and list issues and who works on what.

2. I'd be very happy if you subscribed to Stackoverflow's "pytest" tag
   as to receive notifications when people ask questions about pytest
   and for upvoting/commenting on questions and answers:
   http://stackoverflow.com/questions/tagged/py.test

3. Lastly, and this costs you only 30 seconds once, it would help me and 
   others if you upvoted this general bitbucket feature issue:
   https://bitbucket.org/site/master/issue/7949/
   It would mean maintainers can safe time by subscribing
   to all issues of a project wholesale, without having to explicitely
   do it for each issue.

cheers and thanks!
holger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20131118/5169f99f/attachment.sig>

From achartier at fastmail.fm  Tue Nov 19 03:13:19 2013
From: achartier at fastmail.fm (achartier at fastmail.fm)
Date: Mon, 18 Nov 2013 18:13:19 -0800
Subject: [pytest-dev] Calling pytest.main() does not pick up changes made to
	test script file
Message-ID: <1384827199.31498.49181137.6393E088@webmail.messagingengine.com>

Hello,

We are developing an in-house testing tool based on pytest and are
interested in calling pytest programmatically using pytest.main().
Unfortunately, using this approach, pytest does not "see" changes I make
to my pytest test script file between successive calls to pytest.main(). 

For example, I have a pytest test script called "testscript.py". This
test script file currently has one test called "test_1". If I call

pytest.main("testscript.py")

it correctly runs the one "test_1" test. If I now change the
testscript.py file to include, for instance, the definition of another
test (called "test_2") and run

pytest.main("testscript.py")

it does not see test_2 but only shows test_1. In order for pytest to see
test_2, I must shut down the Python terminal, open a new Python terminal
and then call pytest.main() again. This workflow is unfortunately not
acceptable for our use case.

Does pytest have some file caching mechanism that is causing this issue?
Is there a pytest configuration option I am missing that can fix this?
Am I doing anything wrong?

Any help in this regard is greatly appreciated.

Thank you,

Alfonso


From anton7811 at gmail.com  Wed Nov 20 17:26:16 2013
From: anton7811 at gmail.com (Anton P)
Date: Wed, 20 Nov 2013 18:26:16 +0200
Subject: [pytest-dev] Running finalizer in case test setup has failed
In-Reply-To: <20131112091612.GA20094@merlinux.eu>
References: <CAHDVPJVixmjcCEdp2haubu7o03e2Bnkc18r_oX_jwyunYXyYWw@mail.gmail.com>
 <20131112091612.GA20094@merlinux.eu>
Message-ID: <CALL=tm0fJOEk7aDM3bchct=X9Wr_SfeN=LBP3Kke6RAj5-4u7w@mail.gmail.com>

Also as I found that addfinalizer is more robust approach in comparison
with yield_fixture.
If we get an exception before yield statement anything after it won't be
executed:

import pytest

@pytest.yield_fixture
def yfix(request):
    def fin():
        print "finalizing!"
    0/0
    yield
    fin()

def test_hello(yfix):
    pass



$ py.test -s test_finalizing.py
============================ test session starts
============================
platform linux2 -- Python 2.7.3 -- pytest-2.4.2
plugins: cov
collected 1 items

test_finalizing.py E

================================== ERRORS
===================================
_______________________ ERROR at setup of test_hello
________________________

request = <FixtureRequest for <Function 'test_hello'>>

    @pytest.yield_fixture
    def yfix(request):
        def fin():
            print "finalizing!"
>       0/0
E       ZeroDivisionError: integer division or modulo by zero

test_finalizing.py:15: ZeroDivisionError
========================== 1 error in 0.01 seconds
==========================

Best regards,
Anton


On Tue, Nov 12, 2013 at 11:16 AM, holger krekel <holger at merlinux.eu> wrote:

> Hi Andrii,
>
> On Mon, Nov 11, 2013 at 19:56 +0200, Andrii Smirnov wrote:
> > Hello All,
> >
> > We have complex enough (several stages of putting the test environment
> into
> > some condition) code which should be executed in all cases regardless of
> > test setup result (fixture setup).
> >
> > Since finalizer for fixture will not be called in case its (fixture)
> setup
> > failed we've put some calls to pytest_sessionfinish as a temporary
> > workaround but we need to find a way how to call finalizer code
> explicitly.
>
> Calling fixture finalizers from such a hook is hard if even possible.
>
> But i don't understand yet why your finalizers are not run.  Take
> this example::
>
>     import pytest
>
>     @pytest.fixture
>     def fix(request):
>         def fin():
>             print "finalizing!"
>
>         request.addfinalizer(fin)
>         0/0
>
>     def test_hello(fix):
>         pass
>
> If you run this with ``py.test -s`` you will see the ``finalizing!``
> message although the fixture function fails.
>
> If you are running xUnit-style ``setup*`` functions then indeed,
> pytest is compatible to the way unittest or nose do xUnit setup:
> teardownX functions are not run if a setupX function fails.
> However, you can transform any such setup function into
> a pytest style one by puttig a fixture-autouse decorator in front::
>
>     @pytest.fixture(autouse=True)
>     def setup_function(request):
>         # as above you can register finalizers etc.
>
> If you use the decorator you can also use other pytest fixtures
> such as ``tmpdir`` or ``monkeypatch`` or your own fixtures, of course.
>
> If both examples don't answer your question, please try to give a
> code example on how things fail for you.
>
> cheers,
> holger
> _______________________________________________
> 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/20131120/165659d5/attachment.html>

From holger at merlinux.eu  Wed Nov 20 17:49:51 2013
From: holger at merlinux.eu (holger krekel)
Date: Wed, 20 Nov 2013 16:49:51 +0000
Subject: [pytest-dev] Running finalizer in case test setup has failed
In-Reply-To: <CALL=tm0fJOEk7aDM3bchct=X9Wr_SfeN=LBP3Kke6RAj5-4u7w@mail.gmail.com>
References: <CAHDVPJVixmjcCEdp2haubu7o03e2Bnkc18r_oX_jwyunYXyYWw@mail.gmail.com>
 <20131112091612.GA20094@merlinux.eu>
 <CALL=tm0fJOEk7aDM3bchct=X9Wr_SfeN=LBP3Kke6RAj5-4u7w@mail.gmail.com>
Message-ID: <20131120164951.GS11363@merlinux.eu>

On Wed, Nov 20, 2013 at 18:26 +0200, Anton P wrote:
> Also as I found that addfinalizer is more robust approach in comparison
> with yield_fixture.
> If we get an exception before yield statement anything after it won't be
> executed:
> 
> import pytest
> 
> @pytest.yield_fixture
> def yfix(request):
>     def fin():
>         print "finalizing!"
>     0/0
>     yield
>     fin()
> 
> def test_hello(yfix):
>     pass

Sure, your example should better read:

 @pytest.yield_fixture
 def yfix(request):
     0/0
     yield
     print "finalizing!"

and then it's clear that the print statement is not executed.
This is strictly equivalent to:

 @pytest.fixture
 def yfix(request):
     0 / 0
     def fin():
        print "finalizing!"
     request.addfinalizer(fin)
     return None

It really only makes a difference if you want to
have multiple calls to request.addfinalizer() and do computations
that can raise in between.

best,
holger

> 
> def test_hello(yfix):
>     pass

> 
> 
> $ py.test -s test_finalizing.py
> ============================ test session starts
> ============================
> platform linux2 -- Python 2.7.3 -- pytest-2.4.2
> plugins: cov
> collected 1 items
> 
> test_finalizing.py E
> 
> ================================== ERRORS
> ===================================
> _______________________ ERROR at setup of test_hello
> ________________________
> 
> request = <FixtureRequest for <Function 'test_hello'>>
> 
>     @pytest.yield_fixture
>     def yfix(request):
>         def fin():
>             print "finalizing!"
> >       0/0
> E       ZeroDivisionError: integer division or modulo by zero
> 
> test_finalizing.py:15: ZeroDivisionError
> ========================== 1 error in 0.01 seconds
> ==========================
> 
> Best regards,
> Anton
> 
> 
> On Tue, Nov 12, 2013 at 11:16 AM, holger krekel <holger at merlinux.eu> wrote:
> 
> > Hi Andrii,
> >
> > On Mon, Nov 11, 2013 at 19:56 +0200, Andrii Smirnov wrote:
> > > Hello All,
> > >
> > > We have complex enough (several stages of putting the test environment
> > into
> > > some condition) code which should be executed in all cases regardless of
> > > test setup result (fixture setup).
> > >
> > > Since finalizer for fixture will not be called in case its (fixture)
> > setup
> > > failed we've put some calls to pytest_sessionfinish as a temporary
> > > workaround but we need to find a way how to call finalizer code
> > explicitly.
> >
> > Calling fixture finalizers from such a hook is hard if even possible.
> >
> > But i don't understand yet why your finalizers are not run.  Take
> > this example::
> >
> >     import pytest
> >
> >     @pytest.fixture
> >     def fix(request):
> >         def fin():
> >             print "finalizing!"
> >
> >         request.addfinalizer(fin)
> >         0/0
> >
> >     def test_hello(fix):
> >         pass
> >
> > If you run this with ``py.test -s`` you will see the ``finalizing!``
> > message although the fixture function fails.
> >
> > If you are running xUnit-style ``setup*`` functions then indeed,
> > pytest is compatible to the way unittest or nose do xUnit setup:
> > teardownX functions are not run if a setupX function fails.
> > However, you can transform any such setup function into
> > a pytest style one by puttig a fixture-autouse decorator in front::
> >
> >     @pytest.fixture(autouse=True)
> >     def setup_function(request):
> >         # as above you can register finalizers etc.
> >
> > If you use the decorator you can also use other pytest fixtures
> > such as ``tmpdir`` or ``monkeypatch`` or your own fixtures, of course.
> >
> > If both examples don't answer your question, please try to give a
> > code example on how things fail for you.
> >
> > cheers,
> > holger
> > _______________________________________________
> > Pytest-dev mailing list
> > Pytest-dev at python.org
> > https://mail.python.org/mailman/listinfo/pytest-dev
> >

From lskuff at cloudera.com  Thu Nov 21 16:38:51 2013
From: lskuff at cloudera.com (Lenni Kuff)
Date: Thu, 21 Nov 2013 07:38:51 -0800
Subject: [pytest-dev] Question about silencing pytest xdist plugin reporting
Message-ID: <CAGQc2gEtRzc0vCLU2B_TwE1KRqSFhD5YBg9aW5Mjvj0LkQiujg@mail.gmail.com>

Hi,
I am experimenting with using Pytest + Xdist and I was wondering if it is
possible to completely/mostly silence the xdist logging? When running many
tests in parallel there can be a lots of spew like:

gw0 C / gw1 I / gw2 I / gw3 I / gw4 I / gw5 I / gw6 I / gw7 I / gw8 I / gw9
I / gw10 I / gw11 I / gw12 I / gw13 gw0 C / gw1 C ...

I have been able to reduce the output a bit by adding the following into by
conftest.py file, but can't figure out how to completely silence the output:

def pytest_xdist_setupnodes(config, specs):
  config.option.verbose = 0

Any help would be appreciated.

Thanks,
Lenni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20131121/28d5fe4d/attachment.html>

From holger at merlinux.eu  Sat Nov 23 20:16:34 2013
From: holger at merlinux.eu (holger krekel)
Date: Sat, 23 Nov 2013 19:16:34 +0000
Subject: [pytest-dev] Question about silencing pytest xdist plugin
 reporting
In-Reply-To: <CAGQc2gEtRzc0vCLU2B_TwE1KRqSFhD5YBg9aW5Mjvj0LkQiujg@mail.gmail.com>
References: <CAGQc2gEtRzc0vCLU2B_TwE1KRqSFhD5YBg9aW5Mjvj0LkQiujg@mail.gmail.com>
Message-ID: <20131123191634.GH11363@merlinux.eu>

Hi Lenni,

On Thu, Nov 21, 2013 at 07:38 -0800, Lenni Kuff wrote:
> Hi,
> I am experimenting with using Pytest + Xdist and I was wondering if it is
> possible to completely/mostly silence the xdist logging? When running many
> tests in parallel there can be a lots of spew like:
> 
> gw0 C / gw1 I / gw2 I / gw3 I / gw4 I / gw5 I / gw6 I / gw7 I / gw8 I / gw9
> I / gw10 I / gw11 I / gw12 I / gw13 gw0 C / gw1 C ...
> 
> I have been able to reduce the output a bit by adding the following into by
> conftest.py file, but can't figure out how to completely silence the output:
> 
> def pytest_xdist_setupnodes(config, specs):
>   config.option.verbose = 0
> 
> Any help would be appreciated.

the pytest-xdist plugin could probably act on "config.option.verbosity"
which is a number that increases with "-v" and decreases with "-q".
Maybe consider a pull request as i don't think you can easily tweak
things through hooks or config options without changing some code.

best,
holger

> Thanks,
> Lenni

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


From brianna.laugher at gmail.com  Tue Nov 26 04:45:39 2013
From: brianna.laugher at gmail.com (Brianna Laugher)
Date: Tue, 26 Nov 2013 14:45:39 +1100
Subject: [pytest-dev] fixtures and pylint W0621
Message-ID: <CAPjwCjsoM+88wnRexud7RzmWfJvJEf_Tbi4EJW-wu1-yuqv+bQ@mail.gmail.com>

Hi,

Defining a fixture in the same file as a test that uses it triggers a
pylint complaint:

"W0621:*Redefining name %r from outer scope (line %s)* Used when a
variable?s name hide a name defined in the outer scope."

If the fixture was in conftest.py it would be fine. But it is nice to have
fixtures in the same file if they are only used there. Does everybody just
disable this message? I find it useful in general, I would prefer not to
disable it completely.

thanks
Brianna

-- 
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20131126/5cb15c52/attachment.html>

From holger at merlinux.eu  Tue Nov 26 08:58:40 2013
From: holger at merlinux.eu (holger krekel)
Date: Tue, 26 Nov 2013 07:58:40 +0000
Subject: [pytest-dev] fixtures and pylint W0621
In-Reply-To: <CAPjwCjsoM+88wnRexud7RzmWfJvJEf_Tbi4EJW-wu1-yuqv+bQ@mail.gmail.com>
References: <CAPjwCjsoM+88wnRexud7RzmWfJvJEf_Tbi4EJW-wu1-yuqv+bQ@mail.gmail.com>
Message-ID: <20131126075840.GJ11363@merlinux.eu>

Hi Brianna,

On Tue, Nov 26, 2013 at 14:45 +1100, Brianna Laugher wrote:
> Hi,
> 
> Defining a fixture in the same file as a test that uses it triggers a
> pylint complaint:
> 
> "W0621:*Redefining name %r from outer scope (line %s)* Used when a
> variable?s name hide a name defined in the outer scope."
> 
> If the fixture was in conftest.py it would be fine. But it is nice to have
> fixtures in the same file if they are only used there. Does everybody just
> disable this message? I find it useful in general, I would prefer not to
> disable it completely.

I use flakes and pep8 (pytest-flakes and pytest-pep8) and don't get this
error.  What you can immediately do but which is not pretty is to use
the old naming scheme together with a decorator:

    import pytest

    @pytest.fixture
    def pytest_funcarg__somefixture(...):
        ...

This should avoid the pylint warning.

Alternatively, putting the fixture on a class-level might
avoid the problem:

    class TestClass:
        @pytest.fixture
        def fix(self):
            ....

        def test_fix(self, fix):
            ...

but i haven't tried if pylint likes that.

best,
holger