From opensource at ronnypfannschmidt.de  Sun Dec  6 14:28:11 2015
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Sun, 6 Dec 2015 20:28:11 +0100
Subject: [pytest-dev] pytest 2.8.4 was released :)
Message-ID: <56648C4B.1000808@ronnypfannschmidt.de>

pytest-2.8.4
============

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 supposed to be drop-in compatible to 2.8.2.

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 to this release, among them:

  Bruno Oliveira
  Florian Bruhin
  Jeff Widman
  Mehdy Khoshnoody
  Nicholas Chammas
  Ronny Pfannschmidt
  Tim Chan


Happy testing,
The py.test Development Team


2.8.4 (compared to 2.8.3)
-----------------------------

- fix #1190: ``deprecated_call()`` now works when the deprecated
  function has been already called by another test in the same
  module. Thanks Mikhail Chernykh for the report and Bruno Oliveira for the
  PR.

- fix #1198: ``--pastebin`` option now works on Python 3. Thanks
  Mehdy Khoshnoody for the PR.

- fix #1219: ``--pastebin`` now works correctly when captured output
contains
  non-ascii characters. Thanks Bruno Oliveira for the PR.

- fix #1204: another error when collecting with a nasty __getattr__().
  Thanks Florian Bruhin for the PR.

- fix the summary printed when no tests did run.
  Thanks Florian Bruhin for the PR.

- a number of documentation modernizations wrt good practices.
  Thanks Bruno Oliveira for the PR.


From opensource at ronnypfannschmidt.de  Mon Dec  7 14:42:34 2015
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Mon, 7 Dec 2015 20:42:34 +0100
Subject: [pytest-dev] [proposal] creation of a pytest-dev meta organisation
 on github
Message-ID: <5665E12A.5020100@ronnypfannschmidt.de>

Hi everyone,

given that pytest-dev is slowly growing, i'm feeling it is necessary to
have a transparent management channel to see
and communicate the details that span more than one project, and their
management

that includes infrastructure, addition of projects, handling maintainer
management as well as simpy stuff like the planned/ongoing github
migration of further projects.

an example of such a management channel that i liked was the meta-flask
organisation that the pocoo team created around flask.

for further effects it might make sense to think about something that
works for tox/devpi/execnet as well

-- Ronny

From opensource at ronnypfannschmidt.de  Mon Dec  7 16:12:23 2015
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Mon, 7 Dec 2015 22:12:23 +0100
Subject: [pytest-dev] Doodle for a potential hangout call
Message-ID: <5665F637.5040801@ronnypfannschmidt.de>

Hi Everyone,

if possible i'd like to get a larger part of the pytest team into a
hangout and
concisely talk about a few topics around:

* backward compat
* pytest 3.0 and some feature ideas to be fleshed out specifically after
the call
* xdist
* the kinda stagnated move of many more repos to github

so i made a doodle

http://doodle.com/poll/ez2898mrigfwe278

the time is in central europe and chosen to be late to ease getting
bruno on board

-- Ronny



From flub at devork.be  Mon Dec  7 17:13:19 2015
From: flub at devork.be (Floris Bruynooghe)
Date: Mon, 7 Dec 2015 22:13:19 +0000
Subject: [pytest-dev] [proposal] creation of a pytest-dev meta
 organisation on github
In-Reply-To: <5665E12A.5020100@ronnypfannschmidt.de>
References: <5665E12A.5020100@ronnypfannschmidt.de>
Message-ID: <CAAWk_Dw99R1rgk=y8rzAhBee1c2JZWkEiD=XgGbj10ub18SPqw@mail.gmail.com>

Hi all

On 7 December 2015 at 19:42, Ronny Pfannschmidt
<opensource at ronnypfannschmidt.de> wrote:
> Hi everyone,
>
> given that pytest-dev is slowly growing, i'm feeling it is necessary to
> have a transparent management channel to see
> and communicate the details that span more than one project, and their
> management
>
> that includes infrastructure, addition of projects, handling maintainer
> management as well as simpy stuff like the planned/ongoing github
> migration of further projects.
>
> an example of such a management channel that i liked was the meta-flask
> organisation that the pocoo team created around flask.

For those wondering, the description of this is at
https://github.com/pocoo/metaflask

While what is described at metaflask sounds rather heavy and like it
would easily be out of date I do thing it could be beneficial to spell
out how pytest-dev repos operate, when you can "hijack" it from a
maintainer and how you get commit access.  This last one is probably
the most important one, it's more inclusive to spell out clear rules
on how to get commit access then on just leaving it "when the other
core devs think appropriate".  And giving people commit access is
empowering them to contribute more.

Personally I think this could easily be a page on pytest.org though.
In fact I just searched pytest.org for "pytest-dev" and was surprised
not to get any results.

Regards,
Floris

From holger at merlinux.eu  Fri Dec 11 09:29:35 2015
From: holger at merlinux.eu (holger krekel)
Date: Fri, 11 Dec 2015 14:29:35 +0000
Subject: [pytest-dev] thanking for PRs?
Message-ID: <20151211142935.GD18067@merlinux.eu>


I was wondering about the practise to have PR authors add themselves
to AUTHORS and CHANGELOG.  The latter particularly is a bit odd, i.e.
to thank yourself for submitting a PR.  What do you all think about
having the merger do this last bit (changelog entry)?  AUTHORS
can also be usually obtained from the history so that contributors
can concentrate on tests, code and possibly docs.

my 2c,
holger

From me at the-compiler.org  Fri Dec 11 09:47:42 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Fri, 11 Dec 2015 15:47:42 +0100
Subject: [pytest-dev] thanking for PRs?
In-Reply-To: <20151211142935.GD18067@merlinux.eu>
References: <20151211142935.GD18067@merlinux.eu>
Message-ID: <20151211144742.GJ13519@tonks>

* holger krekel <holger at merlinux.eu> [2015-12-11 14:29:35 +0000]:
> I was wondering about the practise to have PR authors add themselves
> to AUTHORS and CHANGELOG.  The latter particularly is a bit odd, i.e.
> to thank yourself for submitting a PR.

I agree - I've even been asked on Twitter before from some pytest user
about this.

> What do you all think about having the merger do this last bit
> (changelog entry)?  AUTHORS can also be usually obtained from the
> history so that contributors can concentrate on tests, code and
> possibly docs.

I have a more radical view: Do we really want "thanks" in the
changelog at all? IMHO they're just unnecessary noise. We already
express our gratitude as a PR comment and we give credit by listing
people in AUTHORS, so I'd rather not have this in the changelog as
well.

The job of it, after all, is for someone to view *what changed*. If I
want to know *who* changed something, I can easily look it up.

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20151211/f181ce6f/attachment.sig>

From nicoddemus at gmail.com  Fri Dec 11 09:48:45 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Fri, 11 Dec 2015 14:48:45 +0000
Subject: [pytest-dev] thanking for PRs?
In-Reply-To: <20151211142935.GD18067@merlinux.eu>
References: <20151211142935.GD18067@merlinux.eu>
Message-ID: <CA+RQFfc50z0pDBgctP+ZAHp6OP8J5mqN0eerKXMqtxoQKLha6Q@mail.gmail.com>

On Fri, Dec 11, 2015 at 12:30 PM holger krekel <holger at merlinux.eu> wrote:

>
> I was wondering about the practise to have PR authors add themselves
> to AUTHORS and CHANGELOG.  The latter particularly is a bit odd, i.e.
> to thank yourself for submitting a PR.  What do you all think about
> having the merger do this last bit (changelog entry)?  AUTHORS
> can also be usually obtained from the history so that contributors
> can concentrate on tests, code and possibly docs.
>

Often when I merge a PR I do so using GitHub's web interface because I'm
not at my workstation so I don't have the code checked out, but it is easy
enough to also use GitHub's web interface to edit and commit the CHANGELOG
file directly to master after the merge, so I'm not against changing the
policy regarding the CHANGELOG.

About AUTHORS, if we are changing things, IMHO we can delete that file and
add a link to the README pointing to
https://github.com/pytest-dev/pytest/graphs/contributors or
https://github.com/pytest-dev/pytest/network/members.

Cheers,
Bruno.



>
> my 2c,
> 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/20151211/725ef155/attachment.html>

From holger at merlinux.eu  Fri Dec 11 10:14:59 2015
From: holger at merlinux.eu (holger krekel)
Date: Fri, 11 Dec 2015 15:14:59 +0000
Subject: [pytest-dev] thanking for PRs?
In-Reply-To: <CA+RQFfc50z0pDBgctP+ZAHp6OP8J5mqN0eerKXMqtxoQKLha6Q@mail.gmail.com>
References: <20151211142935.GD18067@merlinux.eu>
 <CA+RQFfc50z0pDBgctP+ZAHp6OP8J5mqN0eerKXMqtxoQKLha6Q@mail.gmail.com>
Message-ID: <20151211151459.GV23581@merlinux.eu>

On Fri, Dec 11, 2015 at 14:48 +0000, Bruno Oliveira wrote:
> On Fri, Dec 11, 2015 at 12:30 PM holger krekel <holger at merlinux.eu> wrote:
> 
> >
> > I was wondering about the practise to have PR authors add themselves
> > to AUTHORS and CHANGELOG.  The latter particularly is a bit odd, i.e.
> > to thank yourself for submitting a PR.  What do you all think about
> > having the merger do this last bit (changelog entry)?  AUTHORS
> > can also be usually obtained from the history so that contributors
> > can concentrate on tests, code and possibly docs.
> >
> 
> Often when I merge a PR I do so using GitHub's web interface because I'm
> not at my workstation so I don't have the code checked out, but it is easy
> enough to also use GitHub's web interface to edit and commit the CHANGELOG
> file directly to master after the merge, so I'm not against changing the
> policy regarding the CHANGELOG.
> 
> About AUTHORS, if we are changing things, IMHO we can delete that file and
> add a link to the README pointing to
> https://github.com/pytest-dev/pytest/graphs/contributors or
> https://github.com/pytest-dev/pytest/network/members.

I think the source distro should directly contain the list of authors.
But we can also add links to the github from the web page.

As to Florian's view of not thanking: it feels different for
some authors to be mentioned by name when a release announce
is sent around or in the changelog.  Also i think it's interesting
to know who changed something.  Doing blame/annotate is a different
thing for different purposes IMO.

best,
holger


> Cheers,
> Bruno.
> 
> 
> 
> >
> > my 2c,
> > holger
> > _______________________________________________
> > pytest-dev mailing list
> > pytest-dev at python.org
> > https://mail.python.org/mailman/listinfo/pytest-dev
> >

-- 
about me:    http://holgerkrekel.net/about-me/
contracting: http://merlinux.eu

From nicoddemus at gmail.com  Fri Dec 11 20:05:04 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Sat, 12 Dec 2015 01:05:04 +0000
Subject: [pytest-dev] pytest 2.8.5 released
Message-ID: <CA+RQFff9QRpheL+Ks5kB93xVEeYpuJxuyRuDz9uRCJNk00C20w@mail.gmail.com>

Hey,

I'm happy to announce pytest 2.8.5 has been released.

This release is supposed to be drop-in compatible to 2.8.4

pytest is a mature Python testing tool with more than a 1100 tests
against itself, passing on many different interpreters and platforms.

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 to this release, among them:

  Alex Gaynor
  aselus-hub
  Bruno Oliveira
  Ronny Pfannschmidt

Happy testing,
The py.test Development Team


2.8.5 (compared to 2.8.4)
-------------------------

- fix #1243: fixed issue where class attributes injected during collection
could break pytest.
  PR by Alexei Kozlenok, thanks Ronny Pfannschmidt and Bruno Oliveira for
the review and help.

- fix #1074: precompute junitxml chunks instead of storing the whole tree
in objects
  Thanks Bruno Oliveira for the report and Ronny Pfannschmidt for the PR

- fix #1238: fix ``pytest.deprecated_call()`` receiving multiple arguments
  (Regression introduced in 2.8.4). Thanks Alex Gaynor for the report and
  Bruno Oliveira for the PR.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20151212/ac9613cc/attachment.html>

From opensource at ronnypfannschmidt.de  Sat Dec 12 10:31:35 2015
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Sat, 12 Dec 2015 16:31:35 +0100
Subject: [pytest-dev] Hangout Time Di 15.12.15 21:00
Message-ID: <566C3DD7.2060709@ronnypfannschmidt.de>

Hi everyone,

after Holger confirmed as maybe and Bruno confirmed the time in chat,
the Hangout will be Di 15.12.15 21:00

best regards,
Ronny

From florian.schulze at gmx.net  Sun Dec 13 02:32:33 2015
From: florian.schulze at gmx.net (Florian Schulze)
Date: Sun, 13 Dec 2015 08:32:33 +0100
Subject: [pytest-dev] thanking for PRs?
In-Reply-To: <20151211151459.GV23581@merlinux.eu>
References: <20151211142935.GD18067@merlinux.eu>
 <CA+RQFfc50z0pDBgctP+ZAHp6OP8J5mqN0eerKXMqtxoQKLha6Q@mail.gmail.com>
 <20151211151459.GV23581@merlinux.eu>
Message-ID: <48D40EBC-D8A4-4831-879C-B36F0E53168F@gmx.net>

I just list the usernames after the change and if the user contributed 
for the first time, the fullname as well. See this for example:
https://github.com/fschulze/mr.developer/blob/master/CHANGES.rst

Regards,
Florian Schulze


On 11 Dec 2015, at 16:14, holger krekel wrote:

> On Fri, Dec 11, 2015 at 14:48 +0000, Bruno Oliveira wrote:
>> On Fri, Dec 11, 2015 at 12:30 PM holger krekel <holger at merlinux.eu> 
>> wrote:
>>
>>>
>>> I was wondering about the practise to have PR authors add themselves
>>> to AUTHORS and CHANGELOG.  The latter particularly is a bit odd, 
>>> i.e.
>>> to thank yourself for submitting a PR.  What do you all think about
>>> having the merger do this last bit (changelog entry)?  AUTHORS
>>> can also be usually obtained from the history so that contributors
>>> can concentrate on tests, code and possibly docs.
>>>
>>
>> Often when I merge a PR I do so using GitHub's web interface because 
>> I'm
>> not at my workstation so I don't have the code checked out, but it is 
>> easy
>> enough to also use GitHub's web interface to edit and commit the 
>> CHANGELOG
>> file directly to master after the merge, so I'm not against changing 
>> the
>> policy regarding the CHANGELOG.
>>
>> About AUTHORS, if we are changing things, IMHO we can delete that 
>> file and
>> add a link to the README pointing to
>> https://github.com/pytest-dev/pytest/graphs/contributors or
>> https://github.com/pytest-dev/pytest/network/members.
>
> I think the source distro should directly contain the list of authors.
> But we can also add links to the github from the web page.
>
> As to Florian's view of not thanking: it feels different for
> some authors to be mentioned by name when a release announce
> is sent around or in the changelog.  Also i think it's interesting
> to know who changed something.  Doing blame/annotate is a different
> thing for different purposes IMO.
>
> best,
> holger
>
>
>> Cheers,
>> Bruno.
>>
>>
>>
>>>
>>> my 2c,
>>> holger
>>> _______________________________________________
>>> pytest-dev mailing list
>>> pytest-dev at python.org
>>> https://mail.python.org/mailman/listinfo/pytest-dev
>>>
>
> -- 
> about me:    http://holgerkrekel.net/about-me/
> contracting: http://merlinux.eu
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev

From contact at ionelmc.ro  Sun Dec 13 08:41:38 2015
From: contact at ionelmc.ro (=?UTF-8?Q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Sun, 13 Dec 2015 15:41:38 +0200
Subject: [pytest-dev] thanking for PRs?
In-Reply-To: <20151211142935.GD18067@merlinux.eu>
References: <20151211142935.GD18067@merlinux.eu>
Message-ID: <CANkHFr8NOxC1VDCia24fk4t79AwGfTAf9COC0Jwug-zOJ6UbwQ@mail.gmail.com>

Can we also change a bit the changelog to have actual links to issues/prs?
I often go through the changelog and what to see what the changes actually
were.


Thanks,
-- Ionel Cristian M?rie?, http://blog.ionelmc.ro

On Fri, Dec 11, 2015 at 4:29 PM, holger krekel <holger at merlinux.eu> wrote:

>
> I was wondering about the practise to have PR authors add themselves
> to AUTHORS and CHANGELOG.  The latter particularly is a bit odd, i.e.
> to thank yourself for submitting a PR.  What do you all think about
> having the merger do this last bit (changelog entry)?  AUTHORS
> can also be usually obtained from the history so that contributors
> can concentrate on tests, code and possibly docs.
>
> my 2c,
> 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/20151213/9e9743b9/attachment.html>

From alexn at final.co.il  Mon Dec 14 10:50:57 2015
From: alexn at final.co.il (Alex Netes)
Date: Mon, 14 Dec 2015 15:50:57 +0000
Subject: [pytest-dev] Parametrized scope question
Message-ID: <9DD36B231B342345A5CE849F546273BA7BC40FEF@mail-01>

Hello guys,

I'm new to Pytest and I encounter something I cannot explain.
I'm trying to give fixture fixt_func() a parameter fixt_prm and expect the fixture to be called only once as it defined with 'class' scope, but the fixture is called twice as it ignores the scope. What am I missing?


@pytest.fixture(scope='class')
def fixt_func(request, resource, fixt_prm):
    print fixt_prm

class TestA():
    @pytest.mark.parametrize('resource', ['x'], scope='class')
    @pytest.mark.parametrize(fixt_prm ', ['x'], scope='class')
    @pytest.mark.parametrize('prm', ['a', 'b'])
    def test_a(self, prm, fixt_func)
        assert True

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20151214/44e4b967/attachment.html>

From holger at merlinux.eu  Mon Dec 14 11:17:24 2015
From: holger at merlinux.eu (holger krekel)
Date: Mon, 14 Dec 2015 16:17:24 +0000
Subject: [pytest-dev] Parametrized scope question
In-Reply-To: <9DD36B231B342345A5CE849F546273BA7BC40FEF@mail-01>
References: <9DD36B231B342345A5CE849F546273BA7BC40FEF@mail-01>
Message-ID: <20151214161724.GJ3793@merlinux.eu>

Hi Alex,

On Mon, Dec 14, 2015 at 15:50 +0000, Alex Netes wrote:
> Hello guys,
> 
> I'm new to Pytest and I encounter something I cannot explain.

I also hit many things which i can not explain, even with pytest 
and maybe even with this very mail.

> I'm trying to give fixture fixt_func() a parameter fixt_prm and expect the fixture to be called only once as it defined with 'class' scope, but the fixture is called twice as it ignores the scope. What am I missing?
> 
> 
> @pytest.fixture(scope='class')
> def fixt_func(request, resource, fixt_prm):
>     print fixt_prm
> 
> class TestA():
>     @pytest.mark.parametrize('resource', ['x'], scope='class')
>     @pytest.mark.parametrize(fixt_prm ', ['x'], scope='class')
>     @pytest.mark.parametrize('prm', ['a', 'b'])
>     def test_a(self, prm, fixt_func)
>         assert True

You are doing something i wasn't aware is possible. You pass a parameter
to the fixture function fixt_func through parametrization but as a fixture.
In any case, if we modify your example to:

    import pytest
    @pytest.fixture(scope='class')
    def fixt_func(request, fixt_prm):
        print "fixt_func"

    class TestA():
        @pytest.mark.parametrize('fixt_prm', ['x', 'y'], scope='class')
        def test_a(self, fixt_func):
            assert True

this will also call fixt_func twice for the two executing tests.
It's argubaly "correct" behaviour from a certain point of view.
fixt_prm is class-scoped so each parameter instance exists as a
different "class-level" value so we interpret it to mean each
class-scoped fixture function needs to be executed with both values.

Just imagine we wouldn't parametrize on the function directly 
but through a fixture function:

    import pytest
    @pytest.fixture(scope='class')
    def fixt_func(request, fixt_prm):
        print "fixt_func"

    @pytest.fixture(scope='class', params=["x", "y"])
    def fixt_prm(request):
        print "fixt_prm"

    class TestA():
        def test_a(self, fixt_func):
            assert True

Here it's maybe more obvious why this executes both
fixture functions twice.

however, i am not sure about your precise example above.  I can see why
you expect the two different "prm" values (and thus test functions) to
execute with the same class-level fixtures.  Maybe others can chime in
and say if they consider your example a bug or a "usual" behaviour.

holger




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


-- 
about me:    http://holgerkrekel.net/about-me/
contracting: http://merlinux.eu

From alexn at final.co.il  Tue Dec 15 04:18:59 2015
From: alexn at final.co.il (Alex Netes)
Date: Tue, 15 Dec 2015 09:18:59 +0000
Subject: [pytest-dev] Parametrized scope question
In-Reply-To: <20151214161724.GJ3793@merlinux.eu>
References: <9DD36B231B342345A5CE849F546273BA7BC40FEF@mail-01>
 <20151214161724.GJ3793@merlinux.eu>
Message-ID: <9DD36B231B342345A5CE849F546273BA7BC41147@mail-01>

Hi holger,

Thanks for your help.

> Hi Alex,
> 
> On Mon, Dec 14, 2015 at 15:50 +0000, Alex Netes wrote:
>> Hello guys,
>>
>> I'm new to Pytest and I encounter something I cannot explain.
> 
> I also hit many things which i can not explain, even with pytest and maybe even with this very mail.
> 

I'll try to explain my intention in behind my code, instead of showing my nitty code.

>> I'm trying to give fixture fixt_func() a parameter fixt_prm and expect the fixture to be called only
>> once as it defined with 'class' scope, but the fixture is called twice as it ignores the scope. What am I
>> missing?
>>
>>
>> @pytest.fixture(scope='class')
>> def fixt_func(request, resource, fixt_prm):
>>     print fixt_prm
>>
>> class TestA():
>>     @pytest.mark.parametrize('resource', ['x'], scope='class')
>>     @pytest.mark.parametrize(fixt_prm ', ['x'], scope='class')
>>     @pytest.mark.parametrize('prm', ['a', 'b'])
>>     def test_a(self, prm, fixt_func)
>>         assert True
> 
> You are doing something i wasn't aware is possible. You pass a parameter to the fixture function
> fixt_func through parametrization but as a fixture.
> In any case, if we modify your example to:
> 
>     import pytest
>     @pytest.fixture(scope='class')
>     def fixt_func(request, fixt_prm):
>         print "fixt_func"
> 
>     class TestA():
>         @pytest.mark.parametrize('fixt_prm', ['x', 'y'], scope='class')
>         def test_a(self, fixt_func):
>             assert True
> 
> this will also call fixt_func twice for the two executing tests.
> It's argubaly "correct" behaviour from a certain point of view.
> fixt_prm is class-scoped so each parameter instance exists as a different "class-level" value so we
> interpret it to mean each class-scoped fixture function needs to be executed with both values.
> 
> Just imagine we wouldn't parametrize on the function directly but through a fixture function:
> 
>     import pytest
>     @pytest.fixture(scope='class')
>     def fixt_func(request, fixt_prm):
>         print "fixt_func"
> 
>     @pytest.fixture(scope='class', params=["x", "y"])
>     def fixt_prm(request):
>         print "fixt_prm"
> 
>     class TestA():
>         def test_a(self, fixt_func):
>             assert True
> 
> Here it's maybe more obvious why this executes both fixture functions twice.
> 
> however, i am not sure about your precise example above.  I can see why you expect the two
> different "prm" values (and thus test functions) to execute with the same class-level fixtures.  Maybe
> others can chime in and say if they consider your example a bug or a "usual" behaviour.
> 

Your examples makes sense. I'm trying to do something more complex and maybe I look at it in a wrong
way. I want to define a fixture "fixt_func" so it would be able to receive a parameter defined by different
test classes. Moreover I want "fixt_func" to have Class scope, so I can call finalize when all tests of the
same class finished running. That's why I came up with the above "solution". 

> holger
> 
> 
> 
> 
> > _______________________________________________
> > pytest-dev mailing list
> > pytest-dev at python.org
> > https://mail.python.org/mailman/listinfo/pytest-dev
> 
> 
> --
> about me:    http://holgerkrekel.net/about-me/
> contracting: http://merlinux.eu
> 
> 
> 
> ************************************************************************************
> This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the
> presence of malicious code, vandals & computer viruses.
> ************************************************************************************
> 
> 


From holger at merlinux.eu  Tue Dec 15 05:17:04 2015
From: holger at merlinux.eu (holger krekel)
Date: Tue, 15 Dec 2015 10:17:04 +0000
Subject: [pytest-dev] Parametrized scope question
In-Reply-To: <9DD36B231B342345A5CE849F546273BA7BC41147@mail-01>
References: <9DD36B231B342345A5CE849F546273BA7BC40FEF@mail-01>
 <20151214161724.GJ3793@merlinux.eu>
 <9DD36B231B342345A5CE849F546273BA7BC41147@mail-01>
Message-ID: <20151215101704.GO3793@merlinux.eu>

Hi Alex,

On Tue, Dec 15, 2015 at 09:18 +0000, Alex Netes wrote:
> Hi holger,
> 
> Thanks for your help.
> 
> > Hi Alex,
> > 
> > On Mon, Dec 14, 2015 at 15:50 +0000, Alex Netes wrote:
> >> Hello guys,
> >>
> >> I'm new to Pytest and I encounter something I cannot explain.
> > 
> > I also hit many things which i can not explain, even with pytest and maybe even with this very mail.
> > 
> 
> I'll try to explain my intention in behind my code, instead of showing my nitty code.
> 
> >> I'm trying to give fixture fixt_func() a parameter fixt_prm and expect the fixture to be called only
> >> once as it defined with 'class' scope, but the fixture is called twice as it ignores the scope. What am I
> >> missing?
> >>
> >>
> >> @pytest.fixture(scope='class')
> >> def fixt_func(request, resource, fixt_prm):
> >>     print fixt_prm
> >>
> >> class TestA():
> >>     @pytest.mark.parametrize('resource', ['x'], scope='class')
> >>     @pytest.mark.parametrize(fixt_prm ', ['x'], scope='class')
> >>     @pytest.mark.parametrize('prm', ['a', 'b'])
> >>     def test_a(self, prm, fixt_func)
> >>         assert True
> > 
> > You are doing something i wasn't aware is possible. You pass a parameter to the fixture function
> > fixt_func through parametrization but as a fixture.
> > In any case, if we modify your example to:
> > 
> >     import pytest
> >     @pytest.fixture(scope='class')
> >     def fixt_func(request, fixt_prm):
> >         print "fixt_func"
> > 
> >     class TestA():
> >         @pytest.mark.parametrize('fixt_prm', ['x', 'y'], scope='class')
> >         def test_a(self, fixt_func):
> >             assert True
> > 
> > this will also call fixt_func twice for the two executing tests.
> > It's argubaly "correct" behaviour from a certain point of view.
> > fixt_prm is class-scoped so each parameter instance exists as a different "class-level" value so we
> > interpret it to mean each class-scoped fixture function needs to be executed with both values.
> > 
> > Just imagine we wouldn't parametrize on the function directly but through a fixture function:
> > 
> >     import pytest
> >     @pytest.fixture(scope='class')
> >     def fixt_func(request, fixt_prm):
> >         print "fixt_func"
> > 
> >     @pytest.fixture(scope='class', params=["x", "y"])
> >     def fixt_prm(request):
> >         print "fixt_prm"
> > 
> >     class TestA():
> >         def test_a(self, fixt_func):
> >             assert True
> > 
> > Here it's maybe more obvious why this executes both fixture functions twice.
> > 
> > however, i am not sure about your precise example above.  I can see why you expect the two
> > different "prm" values (and thus test functions) to execute with the same class-level fixtures.  Maybe
> > others can chime in and say if they consider your example a bug or a "usual" behaviour.
> > 
> 
> Your examples makes sense. I'm trying to do something more complex and maybe I look at it in a wrong
> way. I want to define a fixture "fixt_func" so it would be able to receive a parameter defined by different
> test classes. Moreover I want "fixt_func" to have Class scope, so I can call finalize when all tests of the
> same class finished running. That's why I came up with the above "solution". 

I think you could use a marker on the class or even just a class attribute:

    import pytest
    
    @pytest.fixture(scope="class")
    def fix(request):
        return request.cls.attr * 10

    class TestA:
        attr = 1

        def test_one(self, fix):
            assert 0

    class TestB:
        attr = 2

        def test_one(self, fix):
            assert 0

The "request" object gives you back references into the context
of the test which requests fixtures.

HTH,
holger

From alexn at final.co.il  Tue Dec 15 09:11:17 2015
From: alexn at final.co.il (Alex Netes)
Date: Tue, 15 Dec 2015 14:11:17 +0000
Subject: [pytest-dev] Parametrized scope question
In-Reply-To: <20151215101704.GO3793@merlinux.eu>
References: <9DD36B231B342345A5CE849F546273BA7BC40FEF@mail-01>
 <20151214161724.GJ3793@merlinux.eu>
 <9DD36B231B342345A5CE849F546273BA7BC41147@mail-01>
 <20151215101704.GO3793@merlinux.eu>
Message-ID: <9DD36B231B342345A5CE849F546273BA7BC41261@mail-01>

Hi holger,

> Hi Alex,
> 
> On Tue, Dec 15, 2015 at 09:18 +0000, Alex Netes wrote:
> > Hi holger,
> >
> > Thanks for your help.
> >
> > > Hi Alex,
> > >
> > > On Mon, Dec 14, 2015 at 15:50 +0000, Alex Netes wrote:
> > >> Hello guys,
> > >>
> > >> I'm new to Pytest and I encounter something I cannot explain.
> > >
> > > I also hit many things which i can not explain, even with pytest and maybe even with this very mail.
> > >
> >
> > I'll try to explain my intention in behind my code, instead of showing my nitty code.
> >
> > >> I'm trying to give fixture fixt_func() a parameter fixt_prm and expect the fixture to be called only
> > >> once as it defined with 'class' scope, but the fixture is called twice as it ignores the scope. What
> am I
> > >> missing?
> > >>
> > >>
> > >> @pytest.fixture(scope='class')
> > >> def fixt_func(request, resource, fixt_prm):
> > >>     print fixt_prm
> > >>
> > >> class TestA():
> > >>     @pytest.mark.parametrize('resource', ['x'], scope='class')
> > >>     @pytest.mark.parametrize(fixt_prm ', ['x'], scope='class')
> > >>     @pytest.mark.parametrize('prm', ['a', 'b'])
> > >>     def test_a(self, prm, fixt_func)
> > >>         assert True
> > >
> > > You are doing something i wasn't aware is possible. You pass a parameter to the fixture function
> > > fixt_func through parametrization but as a fixture.
> > > In any case, if we modify your example to:
> > >
> > >     import pytest
> > >     @pytest.fixture(scope='class')
> > >     def fixt_func(request, fixt_prm):
> > >         print "fixt_func"
> > >
> > >     class TestA():
> > >         @pytest.mark.parametrize('fixt_prm', ['x', 'y'], scope='class')
> > >         def test_a(self, fixt_func):
> > >             assert True
> > >
> > > this will also call fixt_func twice for the two executing tests.
> > > It's argubaly "correct" behaviour from a certain point of view.
> > > fixt_prm is class-scoped so each parameter instance exists as a different "class-level" value so we
> > > interpret it to mean each class-scoped fixture function needs to be executed with both values.
> > >
> > > Just imagine we wouldn't parametrize on the function directly but through a fixture function:
> > >
> > >     import pytest
> > >     @pytest.fixture(scope='class')
> > >     def fixt_func(request, fixt_prm):
> > >         print "fixt_func"
> > >
> > >     @pytest.fixture(scope='class', params=["x", "y"])
> > >     def fixt_prm(request):
> > >         print "fixt_prm"
> > >
> > >     class TestA():
> > >         def test_a(self, fixt_func):
> > >             assert True
> > >
> > > Here it's maybe more obvious why this executes both fixture functions twice.
> > >
> > > however, i am not sure about your precise example above.  I can see why you expect the two
> > > different "prm" values (and thus test functions) to execute with the same class-level fixtures.
> Maybe
> > > others can chime in and say if they consider your example a bug or a "usual" behaviour.
> > >
> >
> > Your examples makes sense. I'm trying to do something more complex and maybe I look at it in a
> wrong
> > way. I want to define a fixture "fixt_func" so it would be able to receive a parameter defined by
> different
> > test classes. Moreover I want "fixt_func" to have Class scope, so I can call finalize when all tests of
> the
> > same class finished running. That's why I came up with the above "solution".
> 
> I think you could use a marker on the class or even just a class attribute:
> 
>     import pytest
> 
>     @pytest.fixture(scope="class")
>     def fix(request):
>         return request.cls.attr * 10
> 
>     class TestA:
>         attr = 1
> 
>         def test_one(self, fix):
>             assert 0
> 
>     class TestB:
>         attr = 2
> 
>         def test_one(self, fix):
>             assert 0
> 
> The "request" object gives you back references into the context
> of the test which requests fixtures.

Thanks. I think marker option better suite my needs. However, I have two questions.
1. I hit a problem with getting marker parameter from the fixture when it defined
with 'class' scope. When I remove the scope, it works.

     Import pytest

    @pytest.fixture(scope="class")
    def fix(request):
        print request.node.get_marker('attr') # None

    @pytest.mark.attr('something')
    class TestA:
        def test_one(self, fix):
            assert 0

     ------------------------------
     Import pytest

    @pytest.fixture
    def fix(request):
        print request.node.get_marker('attr') # <MarkInfo 'attr' args=('something',) kwargs={}>

    @pytest.mark.attr('something')
    class TestA:
        def test_one(self, fix):
            assert 0

2. Is it possible to provide arguments to the marker via the command line?

From nicoddemus at gmail.com  Tue Dec 15 10:21:42 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 15 Dec 2015 15:21:42 +0000
Subject: [pytest-dev] Parametrized scope question
In-Reply-To: <20151215101704.GO3793@merlinux.eu>
References: <9DD36B231B342345A5CE849F546273BA7BC40FEF@mail-01>
 <20151214161724.GJ3793@merlinux.eu>
 <9DD36B231B342345A5CE849F546273BA7BC41147@mail-01>
 <20151215101704.GO3793@merlinux.eu>
Message-ID: <CA+RQFfe94eqqLJnQbLfafRqjThY7+0ez-Fu-uMudwa+WdAdxVg@mail.gmail.com>

Hi,

Another option is to use fixtures to obtain the values, since fixtures can
be overwritten in subclasses:

import pytest
class Base:

    @pytest.fixture(scope='class')
    def param(self):
        assert 0

    @pytest.yield_fixture(scope='class')
    def fix(self, param, request):
        print 'setup:', request.cls, param
        yield
        print 'teardown:', request.cls, param
class TestA(Base):

    @pytest.fixture(scope='class')
    def param(self):
        return 'value from A'

    def test_1(self, fix):
        pass

    def test_2(self, fix):
        pass
class TestB(Base):

    @pytest.fixture(scope='class')
    def param(self):
        return 'value from B'

    def test_3(self, fix):
        pass

    def test_4(self, fix):
        pass

This yields the expected results:

foo.py::TestA::test_1 setup: foo.TestA value from A
PASSED
foo.py::TestA::test_2 PASSEDteardown: foo.TestA value from A

foo.py::TestB::test_3 setup: foo.TestB value from B
PASSED
foo.py::TestB::test_4 PASSEDteardown: foo.TestB value from B

If your parameters to the fixtures are simple values (like in my example),
I would go with Holger?s suggestion of using simple class attributes.

Fixtures might be useful thought if you are returning more complex objects,
because then you have the full power of the fixtures machinery to access
other fixtures if needed. For example, one of the subclasses might need a
temporary directory to create a file in.

As a more detailed example, suppose you plan to test several data
serializers, like json and pickle. Most of the tests are nearly the same,
create a python data structure, dump, load and compare. One approach is to
put the tests in a base class, and have subclasses with fixtures that
provide a serializer instance for their tests:

class BaseSerializerTests:

    def test_dict(self, serializer):
        d = {'x': 1, 'y': 2}
        stream = serializer.dumps(d)
        d2 = serializer.loads(stream)
        assert d == d2
class TestPickle(BaseSerializerTests):

    @pytest.fixture
    def serializer(self):
        return pickle.PicklerCodec()
class TestJSON(BaseSerializerTests):

    @pytest.fixture
    def serializer(self):
        return json.JSONCodec()

Cheers,
?

On Tue, Dec 15, 2015 at 8:17 AM holger krekel <holger at merlinux.eu> wrote:

> Hi Alex,
>
> On Tue, Dec 15, 2015 at 09:18 +0000, Alex Netes wrote:
> > Hi holger,
> >
> > Thanks for your help.
> >
> > > Hi Alex,
> > >
> > > On Mon, Dec 14, 2015 at 15:50 +0000, Alex Netes wrote:
> > >> Hello guys,
> > >>
> > >> I'm new to Pytest and I encounter something I cannot explain.
> > >
> > > I also hit many things which i can not explain, even with pytest and
> maybe even with this very mail.
> > >
> >
> > I'll try to explain my intention in behind my code, instead of showing
> my nitty code.
> >
> > >> I'm trying to give fixture fixt_func() a parameter fixt_prm and
> expect the fixture to be called only
> > >> once as it defined with 'class' scope, but the fixture is called
> twice as it ignores the scope. What am I
> > >> missing?
> > >>
> > >>
> > >> @pytest.fixture(scope='class')
> > >> def fixt_func(request, resource, fixt_prm):
> > >>     print fixt_prm
> > >>
> > >> class TestA():
> > >>     @pytest.mark.parametrize('resource', ['x'], scope='class')
> > >>     @pytest.mark.parametrize(fixt_prm ', ['x'], scope='class')
> > >>     @pytest.mark.parametrize('prm', ['a', 'b'])
> > >>     def test_a(self, prm, fixt_func)
> > >>         assert True
> > >
> > > You are doing something i wasn't aware is possible. You pass a
> parameter to the fixture function
> > > fixt_func through parametrization but as a fixture.
> > > In any case, if we modify your example to:
> > >
> > >     import pytest
> > >     @pytest.fixture(scope='class')
> > >     def fixt_func(request, fixt_prm):
> > >         print "fixt_func"
> > >
> > >     class TestA():
> > >         @pytest.mark.parametrize('fixt_prm', ['x', 'y'], scope='class')
> > >         def test_a(self, fixt_func):
> > >             assert True
> > >
> > > this will also call fixt_func twice for the two executing tests.
> > > It's argubaly "correct" behaviour from a certain point of view.
> > > fixt_prm is class-scoped so each parameter instance exists as a
> different "class-level" value so we
> > > interpret it to mean each class-scoped fixture function needs to be
> executed with both values.
> > >
> > > Just imagine we wouldn't parametrize on the function directly but
> through a fixture function:
> > >
> > >     import pytest
> > >     @pytest.fixture(scope='class')
> > >     def fixt_func(request, fixt_prm):
> > >         print "fixt_func"
> > >
> > >     @pytest.fixture(scope='class', params=["x", "y"])
> > >     def fixt_prm(request):
> > >         print "fixt_prm"
> > >
> > >     class TestA():
> > >         def test_a(self, fixt_func):
> > >             assert True
> > >
> > > Here it's maybe more obvious why this executes both fixture functions
> twice.
> > >
> > > however, i am not sure about your precise example above.  I can see
> why you expect the two
> > > different "prm" values (and thus test functions) to execute with the
> same class-level fixtures.  Maybe
> > > others can chime in and say if they consider your example a bug or a
> "usual" behaviour.
> > >
> >
> > Your examples makes sense. I'm trying to do something more complex and
> maybe I look at it in a wrong
> > way. I want to define a fixture "fixt_func" so it would be able to
> receive a parameter defined by different
> > test classes. Moreover I want "fixt_func" to have Class scope, so I can
> call finalize when all tests of the
> > same class finished running. That's why I came up with the above
> "solution".
>
> I think you could use a marker on the class or even just a class attribute:
>
>     import pytest
>
>     @pytest.fixture(scope="class")
>     def fix(request):
>         return request.cls.attr * 10
>
>     class TestA:
>         attr = 1
>
>         def test_one(self, fix):
>             assert 0
>
>     class TestB:
>         attr = 2
>
>         def test_one(self, fix):
>             assert 0
>
> The "request" object gives you back references into the context
> of the test which requests fixtures.
>
> HTH,
> 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/20151215/00638224/attachment-0001.html>

From opensource at ronnypfannschmidt.de  Tue Dec 15 11:34:36 2015
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Tue, 15 Dec 2015 17:34:36 +0100
Subject: [pytest-dev] Unforseen delay wrt hangout,
 might not make it before 21:15
Message-ID: <F10FF1A5-60BD-4410-8A22-48E26083A77B@ronnypfannschmidt.de>

Hi,

As of now in the best case, I can still arrive home at 21:00

But please be prepared that I might be up to 15 minutes late.

Sorry for the inconvenience.
MFG Ronny

From holger at merlinux.eu  Tue Dec 15 15:07:04 2015
From: holger at merlinux.eu (holger krekel)
Date: Tue, 15 Dec 2015 20:07:04 +0000
Subject: [pytest-dev] Parametrized scope question
In-Reply-To: <9DD36B231B342345A5CE849F546273BA7BC41261@mail-01>
References: <9DD36B231B342345A5CE849F546273BA7BC40FEF@mail-01>
 <20151214161724.GJ3793@merlinux.eu>
 <9DD36B231B342345A5CE849F546273BA7BC41147@mail-01>
 <20151215101704.GO3793@merlinux.eu>
 <9DD36B231B342345A5CE849F546273BA7BC41261@mail-01>
Message-ID: <20151215200704.GR3793@merlinux.eu>

On Tue, Dec 15, 2015 at 14:11 +0000, Alex Netes wrote:
> > I think you could use a marker on the class or even just a class attribute:
> > 
> >     import pytest
> > 
> >     @pytest.fixture(scope="class")
> >     def fix(request):
> >         return request.cls.attr * 10
> > 
> >     class TestA:
> >         attr = 1
> > 
> >         def test_one(self, fix):
> >             assert 0
> > 
> >     class TestB:
> >         attr = 2
> > 
> >         def test_one(self, fix):
> >             assert 0
> > 
> > The "request" object gives you back references into the context
> > of the test which requests fixtures.
> 
> Thanks. I think marker option better suite my needs. However, I have two questions.
> 1. I hit a problem with getting marker parameter from the fixture when it defined
> with 'class' scope. When I remove the scope, it works.
> 
>      Import pytest
> 
>     @pytest.fixture(scope="class")
>     def fix(request):
>         print request.node.get_marker('attr') # None
> 
>     @pytest.mark.attr('something')
>     class TestA:
>         def test_one(self, fix):
>             assert 0

I don't think there is much point in using a marker.
IISIC the missing marker on class-level is something
that should work.

>      ------------------------------
>      Import pytest
> 
>     @pytest.fixture
>     def fix(request):
>         print request.node.get_marker('attr') # <MarkInfo 'attr' args=('something',) kwargs={}>
> 
>     @pytest.mark.attr('something')
>     class TestA:
>         def test_one(self, fix):
>             assert 0
> 
> 2. Is it possible to provide arguments to the marker via the command line?

You can receive options via request.config.getoption(...) from a fixture
function.  You can not easily access command line options when applying
a marker because that happens at import time when options might not be
available yet. In some cases it might work to use ``pytest.config.getoption()``
within a marker however.

holger


From nicoddemus at gmail.com  Tue Dec 15 15:10:05 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 15 Dec 2015 20:10:05 +0000
Subject: [pytest-dev] Unforseen delay wrt hangout,
 might not make it before 21:15
In-Reply-To: <F10FF1A5-60BD-4410-8A22-48E26083A77B@ronnypfannschmidt.de>
References: <F10FF1A5-60BD-4410-8A22-48E26083A77B@ronnypfannschmidt.de>
Message-ID: <CA+RQFfc4iez3yVSAZ3s4waZuWCj8nSvTQkenw=QNxdUer8U3Xg@mail.gmail.com>

Guys,

Hangout is open at
https://talkgadget.google.com/hangouts/_/ckbezpa6xwy4zczmrqchkgm2vqa

See you there. :)

On Tue, Dec 15, 2015 at 3:03 PM Ronny Pfannschmidt <
opensource at ronnypfannschmidt.de> wrote:

> Hi,
>
> As of now in the best case, I can still arrive home at 21:00
>
> But please be prepared that I might be up to 15 minutes late.
>
> Sorry for the inconvenience.
> MFG Ronny
> _______________________________________________
> 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/20151215/c63fcce7/attachment.html>

From me at the-compiler.org  Tue Dec 15 16:42:18 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Tue, 15 Dec 2015 22:42:18 +0100
Subject: [pytest-dev] pytest hangout meeting minutes
Message-ID: <20151215214218.GN13519@tonks>

We had an (experimental) Google Hangout meeting with some core
developers today - here are the notes I took, completely unedited
because I want to go to sleep ;)

If I missed or misrepresented something, please let me know - sorry!

pytest hangout meeting
======================

people
------

- Bruno/nicoddemus
- Holger/hpk
- Florian/The-Compiler
- Floris/flub
- abusalimov (pytest-catchlog contributor)
- Ronny/ronny

ronny: meta-organization
------------------------

ronny proposes to have a meta-organization to have an issue tracker and wiki to
collect tasks/informations involving more than one pytest-dev project.
Something similar to metaflask.

Meta-things like how pytest-dev work, how to release those, etc.

Also collect infos about the members of the project.

-> Task workflow for management tasks which would feel clunky on a ML
   https://github.com/pocoo/metaflask


Bruno sees some value as there's a plugin index thing there.

flub asks if this isn't basically the same than using a prefix on PyPI.

ronny/bruno: There's much more information than you could have on PyPI, you
could add information like compatibility etc.

flub: Let's try it - worried that it's another data source to get out of data

ronny: We should re-evaluate it in 6-12 months and see how well it worked.

hpk: plugincompat is already there and interesting - why not just add a
'people' page on the website?

flo: I think having a machine-readable represenation of plugins and people
doesn't make sense, even metaflask is a graveyard.

flub: We already have an overview of recommended plugins in the docs, as for
logging, just let's clarify there.

ronny: but what about cross-project issues, I don't want those in the pytest
tracker. e.g. a plugin moving to github. I'd like to see a separate bug tracker
for ecosystem tasks.

hpk: Why not just a 'cross' label for pytest issues. I don't think it's worth
it to have a repo just for issue tracking? The issues also are more visibile
like currently.

flo: I don't see why pytest (as an ecosystem) is concerned about other projects
moving.

bruno: Other than movements, what do you think should be there?

ronny: e.g. maintainer applications or moving to pytest-dev?

hpk: I think that's fine on the mailinglist (flo points out it's documented
that way already)

ronny: okay, let's do labels for issues then and use the ML for other stuff.


hpk: sprint
-----------

What about a pytest sprint in spring and doing crowd-funding for travel?

ronny: he'd like to ask one of the Plone maintainers who's interested in pytest
and experienced in setting up those sprints.

everyone likes the idea!

ronny: moving other projects to github
--------------------------------------

ronny is currently working on a better import from bitbucket to github.
ronny would like to migrate stuff from bb to gh

flub: the maintainer of that would definitely need to agree, ronny agrees.

-> move every project where the maintainers agree to github

ronny: automated releases
-------------------------

ronny: pushing signed tag to github -> get release uploaded to PyPI

hpk: that's the golden aim, but regendoc is still not completely automated.

ronny: I want to work on that, with Travis creating a PR every time something
changes via regendoc.

florian/ronny: Only signed tags should cause releases!

hpk: I'm still very sceptical about that - it often takes a couple of tries to
release something.

ronny: but you can create rc tags, etc. etc. until things look right.

hpk: I like to create an artefact, test that, and release *exactly that*. With
a tag workflow you lose that ability.

ronny: But it would with reducable builds. The build system should create the
same artefact.

hpk: Let's do a PR against howtorelease. I want an automated process, I just
don't think tagging is the right way to do that.

-> The work is a good idea either way, no matter whether we trigger the process
via tags or another mechanism.

bruno: At work we create a release branch, that branch generates artefacts
which aren't published yet. I can *manually* publish and tag it then.

flo: I'd like it most if *testing* was automated.

bruno: What about using devpi via travis?

ronny: We could have a release branch and then make travis do something
different there.

general idea: PR -> release branch -> travis uploads a release somewhere and
tests it -> you can publish that artifact

holger: I'm doing releases for 7-8 projects - we do want to be sure wheels are
working properly. wheels already were broken earlier.

flub: But that works already with an option? I manually build with setup.py and
use tox to test those?

==> we can all agree on automating steps and the general idea

holger: other issues are the changelog or merging features/master. Usually when
I merge something into master I merge it into features as well.

holger: What about doing auto-merges via bot of master -> features

flo: I think this is too noisy, what about weekly or so?

holger: We don't really have a way to do this systematically so far.

bruno: Why not just before every master/bugfix release? If we fix a bug we'll
do a release anyways, so why not do it then?

(holger leaves)

ronny: subtests
---------------

new concept introduced to unittest.py with py3 - you can have sub-tests which
means the test still continues when an assertion fails.

this would allow to create "sections" with proper names (and reporting) for
larger tests.

flub: So what's the challenge about that?

[I couldn't really follow, so no logs here, sorry]

ronny: capturing
----------------

ronny: We currently replace sys.std... objects and replace them by capturing
ones. I'd like to add a kind of capturing where the capturing captures the
whole test run.

[I couldn't really follow, so no logs here, sorry]

--> let's move it to the ML because it's better when written

deferred until later
--------------------

- unittests in pytest testsuite
- DI framework
- 3.x plans

-- Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20151215/46e504d2/attachment.sig>

From nicoddemus at gmail.com  Tue Dec 15 19:38:42 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Wed, 16 Dec 2015 00:38:42 +0000
Subject: [pytest-dev] pytest hangout meeting minutes
In-Reply-To: <20151215214218.GN13519@tonks>
References: <20151215214218.GN13519@tonks>
Message-ID: <CA+RQFffN7TFUXJYziXjsQNBjaydA9hxHsTBb6kbfW+4gSh=7RA@mail.gmail.com>

Thanks Florian for taking the time to create this transcript! :)

On Tue, Dec 15, 2015 at 7:42 PM Florian Bruhin <me at the-compiler.org> wrote:

> We had an (experimental) Google Hangout meeting with some core
> developers today - here are the notes I took, completely unedited
> because I want to go to sleep ;)
>
> If I missed or misrepresented something, please let me know - sorry!
>
> pytest hangout meeting
> ======================
>
> people
> ------
>
> - Bruno/nicoddemus
> - Holger/hpk
> - Florian/The-Compiler
> - Floris/flub
> - abusalimov (pytest-catchlog contributor)
> - Ronny/ronny
>
> ronny: meta-organization
> ------------------------
>
> ronny proposes to have a meta-organization to have an issue tracker and
> wiki to
> collect tasks/informations involving more than one pytest-dev project.
> Something similar to metaflask.
>
> Meta-things like how pytest-dev work, how to release those, etc.
>
> Also collect infos about the members of the project.
>
> -> Task workflow for management tasks which would feel clunky on a ML
>    https://github.com/pocoo/metaflask
>
>
> Bruno sees some value as there's a plugin index thing there.
>
> flub asks if this isn't basically the same than using a prefix on PyPI.
>
> ronny/bruno: There's much more information than you could have on PyPI, you
> could add information like compatibility etc.
>
> flub: Let's try it - worried that it's another data source to get out of
> data
>
> ronny: We should re-evaluate it in 6-12 months and see how well it worked.
>
> hpk: plugincompat is already there and interesting - why not just add a
> 'people' page on the website?
>
> flo: I think having a machine-readable represenation of plugins and people
> doesn't make sense, even metaflask is a graveyard.
>
> flub: We already have an overview of recommended plugins in the docs, as
> for
> logging, just let's clarify there.
>
> ronny: but what about cross-project issues, I don't want those in the
> pytest
> tracker. e.g. a plugin moving to github. I'd like to see a separate bug
> tracker
> for ecosystem tasks.
>
> hpk: Why not just a 'cross' label for pytest issues. I don't think it's
> worth
> it to have a repo just for issue tracking? The issues also are more
> visibile
> like currently.
>
> flo: I don't see why pytest (as an ecosystem) is concerned about other
> projects
> moving.
>
> bruno: Other than movements, what do you think should be there?
>
> ronny: e.g. maintainer applications or moving to pytest-dev?
>
> hpk: I think that's fine on the mailinglist (flo points out it's documented
> that way already)
>
> ronny: okay, let's do labels for issues then and use the ML for other
> stuff.
>
>
> hpk: sprint
> -----------
>
> What about a pytest sprint in spring and doing crowd-funding for travel?
>
> ronny: he'd like to ask one of the Plone maintainers who's interested in
> pytest
> and experienced in setting up those sprints.
>
> everyone likes the idea!
>
> ronny: moving other projects to github
> --------------------------------------
>
> ronny is currently working on a better import from bitbucket to github.
> ronny would like to migrate stuff from bb to gh
>
> flub: the maintainer of that would definitely need to agree, ronny agrees.
>
> -> move every project where the maintainers agree to github
>
> ronny: automated releases
> -------------------------
>
> ronny: pushing signed tag to github -> get release uploaded to PyPI
>
> hpk: that's the golden aim, but regendoc is still not completely automated.
>
> ronny: I want to work on that, with Travis creating a PR every time
> something
> changes via regendoc.
>
> florian/ronny: Only signed tags should cause releases!
>
> hpk: I'm still very sceptical about that - it often takes a couple of
> tries to
> release something.
>
> ronny: but you can create rc tags, etc. etc. until things look right.
>
> hpk: I like to create an artefact, test that, and release *exactly that*.
> With
> a tag workflow you lose that ability.
>
> ronny: But it would with reducable builds. The build system should create
> the
> same artefact.
>
> hpk: Let's do a PR against howtorelease. I want an automated process, I
> just
> don't think tagging is the right way to do that.
>
> -> The work is a good idea either way, no matter whether we trigger the
> process
> via tags or another mechanism.
>
> bruno: At work we create a release branch, that branch generates artefacts
> which aren't published yet. I can *manually* publish and tag it then.
>
> flo: I'd like it most if *testing* was automated.
>
> bruno: What about using devpi via travis?
>
> ronny: We could have a release branch and then make travis do something
> different there.
>
> general idea: PR -> release branch -> travis uploads a release somewhere
> and
> tests it -> you can publish that artifact
>
> holger: I'm doing releases for 7-8 projects - we do want to be sure wheels
> are
> working properly. wheels already were broken earlier.
>
> flub: But that works already with an option? I manually build with
> setup.py and
> use tox to test those?
>
> ==> we can all agree on automating steps and the general idea
>
> holger: other issues are the changelog or merging features/master. Usually
> when
> I merge something into master I merge it into features as well.
>
> holger: What about doing auto-merges via bot of master -> features
>
> flo: I think this is too noisy, what about weekly or so?
>
> holger: We don't really have a way to do this systematically so far.
>
> bruno: Why not just before every master/bugfix release? If we fix a bug
> we'll
> do a release anyways, so why not do it then?
>
> (holger leaves)
>
> ronny: subtests
> ---------------
>
> new concept introduced to unittest.py with py3 - you can have sub-tests
> which
> means the test still continues when an assertion fails.
>
> this would allow to create "sections" with proper names (and reporting) for
> larger tests.
>
> flub: So what's the challenge about that?
>
> [I couldn't really follow, so no logs here, sorry]
>
> ronny: capturing
> ----------------
>
> ronny: We currently replace sys.std... objects and replace them by
> capturing
> ones. I'd like to add a kind of capturing where the capturing captures the
> whole test run.
>
> [I couldn't really follow, so no logs here, sorry]
>
> --> let's move it to the ML because it's better when written
>
> deferred until later
> --------------------
>
> - unittests in pytest testsuite
> - DI framework
> - 3.x plans
>
> -- Florian
>
> --
> http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
>    GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
>          I love long mails! | http://email.is-not-s.ms/
> _______________________________________________
> 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/20151216/78e5cd9f/attachment-0001.html>

From me at the-compiler.org  Wed Dec 16 04:34:12 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Wed, 16 Dec 2015 10:34:12 +0100
Subject: [pytest-dev] State of pytest-bdd
Message-ID: <20151216093411.GR13519@tonks>

Hey,

I'm quite a happy user of pytest-bdd[1], but it has some issues with
deprecation warnings of Python[2] and pytest[3] which I fixed in the
linked PRs.

This was a month ago, unfortunately I still got zero reactions on
those PRs... What can I do in such a case?

It seems Anatoly Bubenkov isn't very active anymore on the plugin, and
Oleg Pidsadnyi who has answered to some of the issues I opened seems
very busy as well.

I'd like to get that plugin in shape a bit more (e.g. by fixing those
things and getting the tests/Travis to pass[4] again), but that'd mean
I'd really like some more people (e.g. me :P) to be able to do
releases on PyPI, and ideally have the OK of Anatoly/Oleg to actually
do a release.

Right now I could just merge my own PRs, but of course I'd prefer not
doing that, and it doesn't help much without a release.

Otherwise I'd have to fork the plugin as I'm a happy user of it other
than those issues, and I'd really like to avoid that...

Florian

[1] https://github.com/pytest-dev/pytest-bdd
[2] https://github.com/pytest-dev/pytest-bdd/pull/164
[3] https://github.com/pytest-dev/pytest-bdd/pull/163
[4] https://github.com/pytest-dev/pytest-bdd/issues/162

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20151216/f293a246/attachment.sig>

From nicoddemus at gmail.com  Wed Dec 16 06:55:48 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Wed, 16 Dec 2015 11:55:48 +0000
Subject: [pytest-dev] State of pytest-bdd
In-Reply-To: <20151216093411.GR13519@tonks>
References: <20151216093411.GR13519@tonks>
Message-ID: <CA+RQFfcJMx7OwVh3bFeSRO3vpBEh8dPPtAFoaqZ7LaeY6xHyOQ@mail.gmail.com>

On Wed, Dec 16, 2015 at 7:34 AM Florian Bruhin <me at the-compiler.org> wrote:

> It seems Anatoly Bubenkov isn't very active anymore on the plugin, and
> Oleg Pidsadnyi who has answered to some of the issues I opened seems
> very busy as well.
>
> I'd like to get that plugin in shape a bit more (e.g. by fixing those
> things and getting the tests/Travis to pass[4] again), but that'd mean
> I'd really like some more people (e.g. me :P) to be able to do
> releases on PyPI, and ideally have the OK of Anatoly/Oleg to actually
> do a release.
>

I guess Anatoly and Oleg could share their thoughts here, but one of the
ideas of the pytest-dev organization was to provide a way for package
maintainers which have limited time to work on a plugin to at least share
the burden with some other interested members of the organization,
including PyPI publishing rights to some trusted users (such as yourself
:)).

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

From bubenkoff at gmail.com  Wed Dec 16 09:28:18 2015
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Wed, 16 Dec 2015 15:28:18 +0100
Subject: [pytest-dev] State of pytest-bdd
In-Reply-To: <20151216093411.GR13519@tonks>
References: <20151216093411.GR13519@tonks>
Message-ID: <CACTnz+Hv3CKVznZodbz3LGWpV+kJAX4L0QmspEv2pHVsMcMHwA@mail.gmail.com>

Hey Florian
yes I'm very busy with a lot of other things, unfortunately
I've added you to that package on the pypi
also on the pytest-splinter
The rule of thumb for PRs i think is:
- tested
- reviewed by 1-2 people

go ahead, i'd say, and thanks for the initiative!

On 16 December 2015 at 10:34, Florian Bruhin <me at the-compiler.org> wrote:

> Hey,
>
> I'm quite a happy user of pytest-bdd[1], but it has some issues with
> deprecation warnings of Python[2] and pytest[3] which I fixed in the
> linked PRs.
>
> This was a month ago, unfortunately I still got zero reactions on
> those PRs... What can I do in such a case?
>
> It seems Anatoly Bubenkov isn't very active anymore on the plugin, and
> Oleg Pidsadnyi who has answered to some of the issues I opened seems
> very busy as well.
>
> I'd like to get that plugin in shape a bit more (e.g. by fixing those
> things and getting the tests/Travis to pass[4] again), but that'd mean
> I'd really like some more people (e.g. me :P) to be able to do
> releases on PyPI, and ideally have the OK of Anatoly/Oleg to actually
> do a release.
>
> Right now I could just merge my own PRs, but of course I'd prefer not
> doing that, and it doesn't help much without a release.
>
> Otherwise I'd have to fork the plugin as I'm a happy user of it other
> than those issues, and I'd really like to avoid that...
>
> Florian
>
> [1] https://github.com/pytest-dev/pytest-bdd
> [2] https://github.com/pytest-dev/pytest-bdd/pull/164
> [3] https://github.com/pytest-dev/pytest-bdd/pull/163
> [4] https://github.com/pytest-dev/pytest-bdd/issues/162
>
> --
> http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
>    GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
>          I love long mails! | http://email.is-not-s.ms/
>



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

From me at the-compiler.org  Sun Dec 20 14:10:00 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Sun, 20 Dec 2015 20:10:00 +0100
Subject: [pytest-dev] pytest-bdd 2.16.0 released
Message-ID: <20151220190959.GH533@tonks>

Hey,

I'm happy to announce I was added as a PyPI maintainer for pytest-bdd
(thanks, Oleg!) and just released 2.16.0.

This fixes deprecation warnings emitted by python 3.5 (because of
inspect.getargspec) and pytest 2.8 (because of addhooks and
__multicall__). It's still compatible with pytest 2.7 for now.

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20151220/6cbfb046/attachment.sig>