From opensource at ronnypfannschmidt.de  Fri Sep  4 22:52:30 2015
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Fri, 4 Sep 2015 22:52:30 +0200
Subject: [pytest-dev] Thinking bout a pathlib dependency and a
 tmppath/tmppath_factory fixture
Message-ID: <55EA048E.3050008@ronnypfannschmidt.de>

Hi everyone,

as part of detaching from pylib, its necessary to provide some kind of
alternative for py.path.local

in order to get started with that, i propose to start with proviing
plugisn a pathlib based core for obtaining temporary folders

later on we an extend on that and slowly migrate more apis, as well as
warn about py.path usage in user code to ease the transition

what do the rest of you think about that?

-- Ronny

From encukou at gmail.com  Sat Sep  5 22:20:49 2015
From: encukou at gmail.com (Petr Viktorin)
Date: Sat, 5 Sep 2015 22:20:49 +0200
Subject: [pytest-dev] Vendoring pluggy with pytest
In-Reply-To: <20150826084340.GB509@tonks>
References: <20150826084340.GB509@tonks>
Message-ID: <CA+=+wqAT64MkwKubGes2GU7bkTG73Wiu1y3nJ88n-iqWRw_gdg@mail.gmail.com>

On Wed, Aug 26, 2015 at 10:43 AM, Florian Bruhin <me at the-compiler.org> wrote:
> Hi!
>
> I'm part of the pytest-dev team, the developers of the pytest[1] test
> runner. I'm writing to you because I'd like to have some opinions on
> the following PR/issue about vendoring pluggy into pytest:
>
> https://github.com/pytest-dev/pytest/issues/944
> https://github.com/pytest-dev/pytest/pull/959
>
> The common logic behind the plugin API of pytest recently got split
> into a separate library, pluggy[2].
>
> However, the public API of pluggy might still change in the near
> future - which means pytest would need to require a specific version
> of pluggy to be sure there's no breakage.
>
> Normally, this wouldn't be an issue - but as a test runner, I believe
> we're in a bit of a special position: Users should still be able to
> use pytest to test their projects, even if their projects use a more
> recent version of pluggy - or they use other projects which might use
> pluggy in the future, like devpi or tox.
>
> Because of this, since it's a very small library, and because the code
> originated from pytest, I wonder what distribution's views are on
> bundling the library for pytest 2.8 until things are expected to be a
> bit more stable.
>
> What do you think?

Hello,
I haven't seen a reply here, but I can say what's customary in Fedora.

Per our packaging guidelines, we would need to unbundle pluggy. So, if
you install pytest from a RPM, you'd get the matching version of
pluggy from a separate RPM. These will be synchronized via the package
manager, so that you can't end up with incompatible versions there.
Any system package that needs pytest will need to use the system
versions of pytest and pluggy -- so devpi or tox packagers would need
to coordinate with the pytest/pluggy packagers, and use versions that
all work together. (Making sure things work together is the job of a
distribution, after all.)

If a Fedora user installs pytest from pypi into a virtualenv, they
would get your bundled copy. Virtualenvs are isolated from the system,
so I see no problems there.

From thomas.moschny at gmx.de  Sun Sep  6 08:34:04 2015
From: thomas.moschny at gmx.de (Thomas Moschny)
Date: Sun, 6 Sep 2015 08:34:04 +0200
Subject: [pytest-dev] Fw:  Vendoring pluggy with pytest
Message-ID: <20150906083404.7b35365d@dose.fritz.box>

Beginn der weitergeleiteten Nachricht:

Datum: Sun, 6 Sep 2015 08:18:17 +0200
Von: Thomas Moschny <thomas.moschny at gmx.de>
An: Petr Viktorin <encukou at gmail.com>
Cc: Florian Bruhin <me at the-compiler.org>, "pytest-dev at python.org"
<pytest-dev at python.org>, pytest-owner at fedoraproject.org
Betreff: Re: [pytest-dev] Vendoring pluggy with pytest


Hi,

sorry for not answering earlier. What Petr says is absolutely right.
Fedora packaging guidelines in general forbid bundling:

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

For example, we are striving for unbundling apipkg in pylib and
execnet, see
  https://bugzilla.redhat.com/show_bug.cgi?id=790163 and
  https://bugzilla.redhat.com/show_bug.cgi?id=790165
respectively, and the corresponding upstream bugs
  https://bitbucket.org/pytest-dev/py/issues/31 and 
  https://bitbucket.org/hpk42/execnet/issues/13

So, as per guidelines, we'd have to unbundle pluggy for the pytest RPM
package as well.

Exceptions are possible under certain circumstances, but need
a blessing from the Fedora Packaging Committee - but this creates some
bureaucratic overhead, so as a packager, I am not really keen on going
through that, and needs to be justified.

One of the reasons for granting an exception can be: "Needing
unreleased features" - however, in the scenario we discuss here, that
would apply to *other* projects using a more recent snapshot of pluggy,
not pytest, so they'd have to (ask for an exception and) bundle that
snapshot of pluggy. For pytest we'd still have to unbundle it.

Another option could be to package more than one version of pluggy.
This is in general possible, but of course has other disadvantages, and
also creates a lot of overhead.

So, to summarize things from a distribution point of view:
Please don't bundle.

Regards,
Thomas


Am Sat, 5 Sep 2015 22:20:49 +0200
schrieb Petr Viktorin <encukou at gmail.com>:

> On Wed, Aug 26, 2015 at 10:43 AM, Florian Bruhin
> <me at the-compiler.org> wrote:
> > Hi!
> >
> > I'm part of the pytest-dev team, the developers of the pytest[1]
> > test runner. I'm writing to you because I'd like to have some
> > opinions on the following PR/issue about vendoring pluggy into
> > pytest:
> >
> > https://github.com/pytest-dev/pytest/issues/944
> > https://github.com/pytest-dev/pytest/pull/959
> >
> > The common logic behind the plugin API of pytest recently got split
> > into a separate library, pluggy[2].
> >
> > However, the public API of pluggy might still change in the near
> > future - which means pytest would need to require a specific version
> > of pluggy to be sure there's no breakage.
> >
> > Normally, this wouldn't be an issue - but as a test runner, I
> > believe we're in a bit of a special position: Users should still be
> > able to use pytest to test their projects, even if their projects
> > use a more recent version of pluggy - or they use other projects
> > which might use pluggy in the future, like devpi or tox.
> >
> > Because of this, since it's a very small library, and because the
> > code originated from pytest, I wonder what distribution's views are
> > on bundling the library for pytest 2.8 until things are expected to
> > be a bit more stable.
> >
> > What do you think?
> 
> Hello,
> I haven't seen a reply here, but I can say what's customary in Fedora.
> 
> Per our packaging guidelines, we would need to unbundle pluggy. So, if
> you install pytest from a RPM, you'd get the matching version of
> pluggy from a separate RPM. These will be synchronized via the package
> manager, so that you can't end up with incompatible versions there.
> Any system package that needs pytest will need to use the system
> versions of pytest and pluggy -- so devpi or tox packagers would need
> to coordinate with the pytest/pluggy packagers, and use versions that
> all work together. (Making sure things work together is the job of a
> distribution, after all.)
> 
> If a Fedora user installs pytest from pypi into a virtualenv, they
> would get your bundled copy. Virtualenvs are isolated from the system,
> so I see no problems there.
> 


From holger at merlinux.eu  Mon Sep  7 10:01:43 2015
From: holger at merlinux.eu (holger krekel)
Date: Mon, 7 Sep 2015 08:01:43 +0000
Subject: [pytest-dev] Working with other dependency injection systems
In-Reply-To: <CALiRuxmcQmrM4X8fPaFBCajZMOEjcL4DenK2hksHe1YABSXRNw@mail.gmail.com>
References: <CALiRux=JiSht3dEENkEWaP5Ob9gzGADFJAS74Pu5qq-9sP2gEQ@mail.gmail.com>
 <20150507112107.GA28354@merlinux.eu>
 <CALiRuxmcQmrM4X8fPaFBCajZMOEjcL4DenK2hksHe1YABSXRNw@mail.gmail.com>
Message-ID: <20150907080143.GV9401@merlinux.eu>

On Thu, Aug 13, 2015 at 17:47 -0400, Kai Groner wrote:
> Hi holger,
> 
> Thanks for your response.  Sorry I haven't followed up sooner.

same here :)

> On Thu, May 7, 2015 at 7:21 AM, holger krekel <holger at merlinux.eu> wrote:
> 
> > Hi Kai,
> >
> > On Thu, Apr 30, 2015 at 19:28 -0400, Kai Groner wrote:
> > > I'm trying to figure out how I can test a code base that uses an existing
> > > dependency injection system.  I've run into two problems, and I have
> > > solutions for each of them but I think maybe there is a better way, so
> > I'm
> > > looking for some advice.
> >
> > Could you provide a simple abstract example?
> > Here and also in the following i don't really understand the background.
> >
> 
> The DI system we are using is called jeni.  I'll try to keep things simple
> here so you don't need to know a lot about it, but here's the url.
> https://github.com/rduplain/jeni-python
> 
> This is untested code, that I hope will be illustrative.  If you think it
> would be helpful to run it, let me know and I will make sure it works.
> 
> We write code sort of like this:
> 
> @route('login', method='POST')
> @jeni.annotate
> def login(
>         username: 'form:username',
>         password: 'form:password',
>         user_lookup: 'user_lookup',
>         session_init: 'session_init'):
>     user = user_lookup(username)
>     if user is None:
>         raise ValueError
>     if not user.check_password(password):
>         raise ValueError
>     session_init(user)
> 
> 
> Here is an example of an injector prototyped with a trivial user_lookup
> implementation:
> 
> class Injector(jeni.Injector): pass
> 
> @Injector.factory
> def user_lookup_factory():
>     class User:
>         def __init__(self, username, password=None):
>             self.username, self.password = username, password
> 
>         def check_password(self, password):
>             return password == self.password
> 
>     def user_lookup(username):
>         return User(username, username)
> 
> 
> Calling this, looks like:
> 
> 
> with Injector() as inj:
>     inj.apply(login)
> 
> There is a partial application mechanism, that creates a wrapper that
> resolves injector bindings at call time.
> 
> @jeni.annotate
> def test_login(login: jeni.partial(login)):
> 
>     login(username='kai', password='kai')
> 
>     with raises(LookupError):
> 
>         login(username='kai', password='KAI')
> 
> 
> with Injector() as inj:
> 
>     inj.apply(test_login)
> 
> Because we need to write a lot of tests, I want to avoid writing the with
> block with every test.  I thought maybe I could use py.test hooks to do
> this.

Please checkout https://pytest.org/latest/plugins.html#hookwrapper-executing-around-other-hooks

It should be the right hook to systematically do your with-injector
logic.


> > The first problem is how do I override how a test using this injector is
> > > called?  I think I want to use the pytest_runtest_call hook, but it still
> > > tries to invoke the test without the injector.  My current solution is to
> > > use the experimental hookwrapper mechanism to replace item.obj with a
> > > partially bound version, then restore it afterward.
> >
> 
> Here my problem is that py.test looks for a ``login`` fixture and when it
> finds none it decides the test cannot proceed.

You probably need to provide this "login" fixture even if it's empty
and work is done in the hook above. not sure i get all your semantics
100 % though.

best,
holger


> > > The second problem I'm having is the py.test fixture system is trying to
> > > resolve arguments that are provided by this other injector.  How can I
> > tell
> > > it that some of these don't need to be provided?  My current solution is
> > to
> > > blind py.test with a wrapper function with a *a, **kw signature.  I use
> > > functools.wraps, so annotations are introspectable for the other
> > injector,
> > > and delete the __wrapped__ attribute to prevent py.test from
> > introspecting
> > > it.  Is there a nicer, and perhaps less blunt, way to influence the
> > funcarg
> > > fixture behaviors?  I've tried a couple things with the
> > > pytest_collection_modifyitems hook, but haven't gotten anything that
> > works
> > > yet.
> > >
> > > Other details to know about this injection system:
> > > - we want to build and teardown the injector with each test
> > > - we may want to configure the injector differently for some tests
> > > (possibly with fixture data from py.test)
> 
> 
> 
> Kai

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

From holger at merlinux.eu  Mon Sep  7 10:15:52 2015
From: holger at merlinux.eu (holger krekel)
Date: Mon, 7 Sep 2015 08:15:52 +0000
Subject: [pytest-dev] Releases
In-Reply-To: <20150809215509.GA14835@tonks>
References: <20150809215509.GA14835@tonks>
Message-ID: <20150907081552.GY9401@merlinux.eu>

Hi Florian, all,

i am finally getting back into coding/project work again. 
FWIW i think we should get 2.8 out the door ASAP.  Before
i can help much with it i need to get new devpi releases out
and i am not sure at the moment how much work that is.

If anyone can point me to where my feedback/work for pytest-2.8
would be most needed, i'd be grateful. (still catching up with
my mail box after >4 weeks offtime and that will take some whiles ...)

cheers,
holger


On Sun, Aug 09, 2015 at 23:55 +0200, Florian Bruhin wrote:
> Hi!
> 
> We've been talking about doing a release since somewhen before
> EuroPython and there's still no release with Python 3.5 support out
> yet ;)
> 
> What's missing for a 2.7.3, and what for 2.8.0? Does it make sense to
> release 2.7.3, or should we go for 2.8.0 directly?
> 
> Looking at the changelog, 2.8 has some bugfixes as well (I'm guilty on
> that one), so I wonder if we should just release that directly (and
> when).
> 
> Either way, both have features/fixes I'm eagerly waiting for, and
> enough changes to warrant a release IMHO.
> 
> 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


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

From holger at merlinux.eu  Mon Sep  7 10:22:50 2015
From: holger at merlinux.eu (holger krekel)
Date: Mon, 7 Sep 2015 08:22:50 +0000
Subject: [pytest-dev] Thinking bout a pathlib dependency and a
 tmppath/tmppath_factory fixture
In-Reply-To: <55EA048E.3050008@ronnypfannschmidt.de>
References: <55EA048E.3050008@ronnypfannschmidt.de>
Message-ID: <20150907082250.GA30417@merlinux.eu>

Hi Ronny,

On Fri, Sep 04, 2015 at 22:52 +0200, Ronny Pfannschmidt wrote:
> Hi everyone,
> 
> as part of detaching from pylib, its necessary to provide some kind of
> alternative for py.path.local
> 
> in order to get started with that, i propose to start with proviing
> plugisn a pathlib based core for obtaining temporary folders
> 
> later on we an extend on that and slowly migrate more apis, as well as
> warn about py.path usage in user code to ease the transition
> 
> what do the rest of you think about that?

What about an experiment: identify which methods from py.path.local 
are used from pytest and write a little class on top of pathlib which
provides them (maybe as part of pytest for now) and see what issues
come up in the pytest regression suite?

Based on the experience with that we could see about strategies 
how to move on, considering packaging, compatibility and other issues.

cheers,

holger


> -- Ronny
> _______________________________________________
> 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  Mon Sep  7 16:39:23 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Mon, 07 Sep 2015 14:39:23 +0000
Subject: [pytest-dev] Releases
In-Reply-To: <20150907081552.GY9401@merlinux.eu>
References: <20150809215509.GA14835@tonks> <20150907081552.GY9401@merlinux.eu>
Message-ID: <CA+RQFfep+w6mtMxmTvgt0ZaJFdpHb6Ae4Gju2oTKJ38F=D=BpQ@mail.gmail.com>

Hi Holger,

Glad to have you back. :)

The main points holding back 2.8 I think are:

* vendoring pluggy (https://github.com/pytest-dev/pytest/pull/959)
* merge pytest-cache into core (
https://github.com/pytest-dev/pytest/pull/828)

Cheers,
Bruno.


On Mon, Sep 7, 2015 at 5:16 AM holger krekel <holger at merlinux.eu> wrote:

> Hi Florian, all,
>
> i am finally getting back into coding/project work again.
> FWIW i think we should get 2.8 out the door ASAP.  Before
> i can help much with it i need to get new devpi releases out
> and i am not sure at the moment how much work that is.
>
> If anyone can point me to where my feedback/work for pytest-2.8
> would be most needed, i'd be grateful. (still catching up with
> my mail box after >4 weeks offtime and that will take some whiles ...)
>
> cheers,
> holger
>
>
> On Sun, Aug 09, 2015 at 23:55 +0200, Florian Bruhin wrote:
> > Hi!
> >
> > We've been talking about doing a release since somewhen before
> > EuroPython and there's still no release with Python 3.5 support out
> > yet ;)
> >
> > What's missing for a 2.7.3, and what for 2.8.0? Does it make sense to
> > release 2.7.3, or should we go for 2.8.0 directly?
> >
> > Looking at the changelog, 2.8 has some bugfixes as well (I'm guilty on
> > that one), so I wonder if we should just release that directly (and
> > when).
> >
> > Either way, both have features/fixes I'm eagerly waiting for, and
> > enough changes to warrant a release IMHO.
> >
> > 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
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150907/1a5349a6/attachment.html>

From kai at gronr.com  Tue Sep  8 20:33:32 2015
From: kai at gronr.com (Kai Groner)
Date: Tue, 8 Sep 2015 14:33:32 -0400
Subject: [pytest-dev] Working with other dependency injection systems
In-Reply-To: <20150907080143.GV9401@merlinux.eu>
References: <CALiRux=JiSht3dEENkEWaP5Ob9gzGADFJAS74Pu5qq-9sP2gEQ@mail.gmail.com>
 <20150507112107.GA28354@merlinux.eu>
 <CALiRuxmcQmrM4X8fPaFBCajZMOEjcL4DenK2hksHe1YABSXRNw@mail.gmail.com>
 <20150907080143.GV9401@merlinux.eu>
Message-ID: <CALiRuxmvc2iOGY-wcJaA+3RoeK1TzmNSr0NtqrrAuZdUr6jDYw@mail.gmail.com>

On Mon, Sep 7, 2015 at 4:01 AM, holger krekel <holger at merlinux.eu> wrote:

> On Thu, Aug 13, 2015 at 17:47 -0400, Kai Groner wrote:
> > Hi holger,
> >
> > Thanks for your response.  Sorry I haven't followed up sooner.
>
> same here :)
>
> > On Thu, May 7, 2015 at 7:21 AM, holger krekel <holger at merlinux.eu>
> wrote:
> >
> > > Hi Kai,
> > >
> > > On Thu, Apr 30, 2015 at 19:28 -0400, Kai Groner wrote:
> > > > I'm trying to figure out how I can test a code base that uses an
> existing
> > > > dependency injection system.  I've run into two problems, and I have
> > > > solutions for each of them but I think maybe there is a better way,
> so
> > > I'm
> > > > looking for some advice.
> > >
> > > Could you provide a simple abstract example?
> > > Here and also in the following i don't really understand the
> background.
> > >
> >
> > The DI system we are using is called jeni.  I'll try to keep things
> simple
> > here so you don't need to know a lot about it, but here's the url.
> > https://github.com/rduplain/jeni-python
> >
> > This is untested code, that I hope will be illustrative.  If you think it
> > would be helpful to run it, let me know and I will make sure it works.
> >
> > We write code sort of like this:
> >
> > @route('login', method='POST')
> > @jeni.annotate
> > def login(
> >         username: 'form:username',
> >         password: 'form:password',
> >         user_lookup: 'user_lookup',
> >         session_init: 'session_init'):
> >     user = user_lookup(username)
> >     if user is None:
> >         raise ValueError
> >     if not user.check_password(password):
> >         raise ValueError
> >     session_init(user)
> >
> >
> > Here is an example of an injector prototyped with a trivial user_lookup
> > implementation:
> >
> > class Injector(jeni.Injector): pass
> >
> > @Injector.factory
> > def user_lookup_factory():
> >     class User:
> >         def __init__(self, username, password=None):
> >             self.username, self.password = username, password
> >
> >         def check_password(self, password):
> >             return password == self.password
> >
> >     def user_lookup(username):
> >         return User(username, username)
> >
> >
> > Calling this, looks like:
> >
> >
> > with Injector() as inj:
> >     inj.apply(login)
> >
> > There is a partial application mechanism, that creates a wrapper that
> > resolves injector bindings at call time.
> >
> > @jeni.annotate
> > def test_login(login: jeni.partial(login)):
> >
> >     login(username='kai', password='kai')
> >
> >     with raises(LookupError):
> >
> >         login(username='kai', password='KAI')
> >
> >
> > with Injector() as inj:
> >
> >     inj.apply(test_login)
> >
> > Because we need to write a lot of tests, I want to avoid writing the with
> > block with every test.  I thought maybe I could use py.test hooks to do
> > this.
>
> Please checkout
> https://pytest.org/latest/plugins.html#hookwrapper-executing-around-other-hooks
>
> It should be the right hook to systematically do your with-injector
> logic.


I think so.  I just need to get it to run the test without certain
"fixtures".

> > The first problem is how do I override how a test using this injector is
> > > > called?  I think I want to use the pytest_runtest_call hook, but it
> still
> > > > tries to invoke the test without the injector.  My current solution
> is to
> > > > use the experimental hookwrapper mechanism to replace item.obj with a
> > > > partially bound version, then restore it afterward.
> > >
> >
> > Here my problem is that py.test looks for a ``login`` fixture and when it
> > finds none it decides the test cannot proceed.
>
> You probably need to provide this "login" fixture even if it's empty
> and work is done in the hook above. not sure i get all your semantics
> 100 % though.
>

The thing is that these aren't really fixtures and the dependencies are
selected by annotation rather than argument name.  What login means in one
test won't match what login means in another test.  Even when it is the
same service, it will be a new instance/partial created by a new injector
with new services.

I do want to use py.test fixtures for parametrization.  Is there a way I
can tell py.test that certain arguments aren't fixtures and it shouldn't
worry about providing them?


Kai

best,
> holger
>
>
> > > > The second problem I'm having is the py.test fixture system is
> trying to
> > > > resolve arguments that are provided by this other injector.  How can
> I
> > > tell
> > > > it that some of these don't need to be provided?  My current
> solution is
> > > to
> > > > blind py.test with a wrapper function with a *a, **kw signature.  I
> use
> > > > functools.wraps, so annotations are introspectable for the other
> > > injector,
> > > > and delete the __wrapped__ attribute to prevent py.test from
> > > introspecting
> > > > it.  Is there a nicer, and perhaps less blunt, way to influence the
> > > funcarg
> > > > fixture behaviors?  I've tried a couple things with the
> > > > pytest_collection_modifyitems hook, but haven't gotten anything that
> > > works
> > > > yet.
> > > >
> > > > Other details to know about this injection system:
> > > > - we want to build and teardown the injector with each test
> > > > - we may want to configure the injector differently for some tests
> > > > (possibly with fixture data from py.test)
> >
> >
> >
> > Kai
>
> --
> about me:    http://holgerkrekel.net/about-me/
> contracting: http://merlinux.eu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150908/9a1dc434/attachment.html>

From holger at merlinux.eu  Thu Sep 10 09:12:50 2015
From: holger at merlinux.eu (holger krekel)
Date: Thu, 10 Sep 2015 07:12:50 +0000
Subject: [pytest-dev] Working with other dependency injection systems
In-Reply-To: <CALiRuxmvc2iOGY-wcJaA+3RoeK1TzmNSr0NtqrrAuZdUr6jDYw@mail.gmail.com>
References: <CALiRux=JiSht3dEENkEWaP5Ob9gzGADFJAS74Pu5qq-9sP2gEQ@mail.gmail.com>
 <20150507112107.GA28354@merlinux.eu>
 <CALiRuxmcQmrM4X8fPaFBCajZMOEjcL4DenK2hksHe1YABSXRNw@mail.gmail.com>
 <20150907080143.GV9401@merlinux.eu>
 <CALiRuxmvc2iOGY-wcJaA+3RoeK1TzmNSr0NtqrrAuZdUr6jDYw@mail.gmail.com>
Message-ID: <20150910071250.GI26059@merlinux.eu>

On Tue, Sep 08, 2015 at 14:33 -0400, Kai Groner wrote:
> On Mon, Sep 7, 2015 at 4:01 AM, holger krekel <holger at merlinux.eu> wrote:
> 
> > On Thu, Aug 13, 2015 at 17:47 -0400, Kai Groner wrote:
> > > Hi holger,
> > >
> > > Thanks for your response.  Sorry I haven't followed up sooner.
> >
> > same here :)
> >
> > > On Thu, May 7, 2015 at 7:21 AM, holger krekel <holger at merlinux.eu>
> > wrote:
> > >
> > > > Hi Kai,
> > > >
> > > > On Thu, Apr 30, 2015 at 19:28 -0400, Kai Groner wrote:
> > > > > I'm trying to figure out how I can test a code base that uses an
> > existing
> > > > > dependency injection system.  I've run into two problems, and I have
> > > > > solutions for each of them but I think maybe there is a better way,
> > so
> > > > I'm
> > > > > looking for some advice.
> > > >
> > > > Could you provide a simple abstract example?
> > > > Here and also in the following i don't really understand the
> > background.
> > > >
> > >
> > > The DI system we are using is called jeni.  I'll try to keep things
> > simple
> > > here so you don't need to know a lot about it, but here's the url.
> > > https://github.com/rduplain/jeni-python
> > >
> > > This is untested code, that I hope will be illustrative.  If you think it
> > > would be helpful to run it, let me know and I will make sure it works.
> > >
> > > We write code sort of like this:
> > >
> > > @route('login', method='POST')
> > > @jeni.annotate
> > > def login(
> > >         username: 'form:username',
> > >         password: 'form:password',
> > >         user_lookup: 'user_lookup',
> > >         session_init: 'session_init'):
> > >     user = user_lookup(username)
> > >     if user is None:
> > >         raise ValueError
> > >     if not user.check_password(password):
> > >         raise ValueError
> > >     session_init(user)
> > >
> > >
> > > Here is an example of an injector prototyped with a trivial user_lookup
> > > implementation:
> > >
> > > class Injector(jeni.Injector): pass
> > >
> > > @Injector.factory
> > > def user_lookup_factory():
> > >     class User:
> > >         def __init__(self, username, password=None):
> > >             self.username, self.password = username, password
> > >
> > >         def check_password(self, password):
> > >             return password == self.password
> > >
> > >     def user_lookup(username):
> > >         return User(username, username)
> > >
> > >
> > > Calling this, looks like:
> > >
> > >
> > > with Injector() as inj:
> > >     inj.apply(login)
> > >
> > > There is a partial application mechanism, that creates a wrapper that
> > > resolves injector bindings at call time.
> > >
> > > @jeni.annotate
> > > def test_login(login: jeni.partial(login)):
> > >
> > >     login(username='kai', password='kai')
> > >
> > >     with raises(LookupError):
> > >
> > >         login(username='kai', password='KAI')
> > >
> > >
> > > with Injector() as inj:
> > >
> > >     inj.apply(test_login)
> > >
> > > Because we need to write a lot of tests, I want to avoid writing the with
> > > block with every test.  I thought maybe I could use py.test hooks to do
> > > this.
> >
> > Please checkout
> > https://pytest.org/latest/plugins.html#hookwrapper-executing-around-other-hooks
> >
> > It should be the right hook to systematically do your with-injector
> > logic.
> 
> 
> I think so.  I just need to get it to run the test without certain
> "fixtures".
> 
> > > The first problem is how do I override how a test using this injector is
> > > > > called?  I think I want to use the pytest_runtest_call hook, but it
> > still
> > > > > tries to invoke the test without the injector.  My current solution
> > is to
> > > > > use the experimental hookwrapper mechanism to replace item.obj with a
> > > > > partially bound version, then restore it afterward.
> > > >
> > >
> > > Here my problem is that py.test looks for a ``login`` fixture and when it
> > > finds none it decides the test cannot proceed.
> >
> > You probably need to provide this "login" fixture even if it's empty
> > and work is done in the hook above. not sure i get all your semantics
> > 100 % though.
> >
> 
> The thing is that these aren't really fixtures and the dependencies are
> selected by annotation rather than argument name.  What login means in one
> test won't match what login means in another test.  Even when it is the
> same service, it will be a new instance/partial created by a new injector
> with new services.
> 
> I do want to use py.test fixtures for parametrization.  Is there a way I
> can tell py.test that certain arguments aren't fixtures and it shouldn't
> worry about providing them?

Not really.  Why can't you have a fixture function that selects an 
implementation based on annotations associated with the test function?

holger

From me at the-compiler.org  Thu Sep 10 17:05:36 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Thu, 10 Sep 2015 17:05:36 +0200
Subject: [pytest-dev] Disabling third-party application access on GitHub
Message-ID: <20150910150536.GB18577@tonks>

Hi,

currently, if I enable an application to access my GitHub account,
it'll also have the same access to all pytest-dev repositories.

This is obviously... not so cool.

I'd like to change[1] that, however that comes with a few caveats[2]
unfortunately.

The most important is probably this one:

- SSH keys created before February 2014 immediately lose access to the
  organization's resources (this includes user and deploy keys).

  When an SSH key created before February 2014 loses access to an
  organization with third-party application restrictions enabled,
  subsequent SSH access attempts will fail. Users will encounter an
  error message directing them to a URL where they can approve the key
  or upload a trusted key in its place.

I'm guessing the reason for this is (random guess) because there
wasn't any distinction between user- and application-keys before then.

I'm not 100% sure what exactly the impact will be, but this might
impact pushing until the key is re-approved for everyone with a key
older than that.

Any objections? If not, I'd like to flip the switch on Saturday.

Florian

[1] https://help.github.com/articles/disabling-third-party-application-restrictions-for-your-organization/
[2] https://help.github.com/articles/about-third-party-application-restrictions/

-- 
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: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150910/29034c98/attachment.sig>

From kai at gronr.com  Thu Sep 10 18:15:03 2015
From: kai at gronr.com (Kai Groner)
Date: Thu, 10 Sep 2015 12:15:03 -0400
Subject: [pytest-dev] Working with other dependency injection systems
In-Reply-To: <20150910071250.GI26059@merlinux.eu>
References: <CALiRux=JiSht3dEENkEWaP5Ob9gzGADFJAS74Pu5qq-9sP2gEQ@mail.gmail.com>
 <20150507112107.GA28354@merlinux.eu>
 <CALiRuxmcQmrM4X8fPaFBCajZMOEjcL4DenK2hksHe1YABSXRNw@mail.gmail.com>
 <20150907080143.GV9401@merlinux.eu>
 <CALiRuxmvc2iOGY-wcJaA+3RoeK1TzmNSr0NtqrrAuZdUr6jDYw@mail.gmail.com>
 <20150910071250.GI26059@merlinux.eu>
Message-ID: <CALiRuxkk=hyAsoae+OsHZC6bCuQP8m+4=AiKRQ5_gzP7m1hXrg@mail.gmail.com>

On Thu, Sep 10, 2015 at 3:12 AM, holger krekel <holger at merlinux.eu> wrote:

> On Tue, Sep 08, 2015 at 14:33 -0400, Kai Groner wrote:
> > On Mon, Sep 7, 2015 at 4:01 AM, holger krekel <holger at merlinux.eu>
> wrote:
> >
> > > On Thu, Aug 13, 2015 at 17:47 -0400, Kai Groner wrote:
> > > > Here my problem is that py.test looks for a ``login`` fixture and
> when it
> > > > finds none it decides the test cannot proceed.
> > >
> > > You probably need to provide this "login" fixture even if it's empty
> > > and work is done in the hook above. not sure i get all your semantics
> > > 100 % though.
> > >
> >
> > The thing is that these aren't really fixtures and the dependencies are
> > selected by annotation rather than argument name.  What login means in
> one
> > test won't match what login means in another test.  Even when it is the
> > same service, it will be a new instance/partial created by a new injector
> > with new services.
> >
> > I do want to use py.test fixtures for parametrization.  Is there a way I
> > can tell py.test that certain arguments aren't fixtures and it shouldn't
> > worry about providing them?
>
> Not really.  Why can't you have a fixture function that selects an
> implementation based on annotations associated with the test function?


This would probably work, but we use injection pretty extensively, and this
would require a lot of extra fixture definitions.

Experimentally, I wrote the following (annotate is part of jeni):

def pytest_collection_modifyitems(session, config, items):
>     for item in items:

        if item.fixturenames and annotate.has_annotations(item.function):
>             arg_notes, kwarg_notes =
> annotate.get_annotations(item.function)
>             fixtureinfo = item._fixtureinfo
>             fixtureinfo.argnames = tuple(
>                     name for name in fixtureinfo.argnames
>                     if name not in kwarg_notes )
>             item.fixturenames[:] = (
>                     name for name in item.fixturenames
>                     if name not in kwarg_notes )
>

This does what I'm looking for, but having a sanctioned API would probably
be better than accessing item._fixtureinfo directly.


Kai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150910/f903349b/attachment.html>

From contact at ionelmc.ro  Thu Sep 10 20:26:24 2015
From: contact at ionelmc.ro (=?UTF-8?Q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Thu, 10 Sep 2015 21:26:24 +0300
Subject: [pytest-dev] Disabling third-party application access on GitHub
In-Reply-To: <20150910150536.GB18577@tonks>
References: <20150910150536.GB18577@tonks>
Message-ID: <CANkHFr8+ZRQDC6ObCBW1nAcD6Qhmz8Ppe=DJo5uNAM6b30iXKg@mail.gmail.com>

Hey,

(I don't really know how github orgs work)

Is there a list of apps that we want to whitelist? What's the process to
whitelist an app later?


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

On Thu, Sep 10, 2015 at 6:05 PM, Florian Bruhin <me at the-compiler.org> wrote:

> Hi,
>
> currently, if I enable an application to access my GitHub account,
> it'll also have the same access to all pytest-dev repositories.
>
> This is obviously... not so cool.
>
> I'd like to change[1] that, however that comes with a few caveats[2]
> unfortunately.
>
> The most important is probably this one:
>
> - SSH keys created before February 2014 immediately lose access to the
>   organization's resources (this includes user and deploy keys).
>
>   When an SSH key created before February 2014 loses access to an
>   organization with third-party application restrictions enabled,
>   subsequent SSH access attempts will fail. Users will encounter an
>   error message directing them to a URL where they can approve the key
>   or upload a trusted key in its place.
>
> I'm guessing the reason for this is (random guess) because there
> wasn't any distinction between user- and application-keys before then.
>
> I'm not 100% sure what exactly the impact will be, but this might
> impact pushing until the key is re-approved for everyone with a key
> older than that.
>
> Any objections? If not, I'd like to flip the switch on Saturday.
>
> Florian
>
> [1]
> https://help.github.com/articles/disabling-third-party-application-restrictions-for-your-organization/
> [2]
> https://help.github.com/articles/about-third-party-application-restrictions/
>
> --
> 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/20150910/d5a5cfd9/attachment.html>

From me at the-compiler.org  Sat Sep 12 15:36:16 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Sat, 12 Sep 2015 15:36:16 +0200
Subject: [pytest-dev] Disabling third-party application access on GitHub
In-Reply-To: <20150910150536.GB18577@tonks>
References: <20150910150536.GB18577@tonks>
Message-ID: <20150912133616.GI18577@tonks>

* Florian Bruhin <me at the-compiler.org> [2015-09-10 17:05:36 +0200]:
> I'm not 100% sure what exactly the impact will be, but this might
> impact pushing until the key is re-approved for everyone with a key
> older than that.
> 
> Any objections? If not, I'd like to flip the switch on Saturday.

I changed the settings now, let's see what will break...

If I understand it correctly, AppVeyor and probably Travis will need
re-authorizing now.

Who has the credentials for the pytestbot account? Bruno? I think
you'll need to remove and re-add them, and then a pytest-dev owner
needs to approve it there.

Sorry again for the disruption, but I think it's better than allowing
everything any member has activated for their own account.

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: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150912/abfc01e6/attachment.sig>

From nicoddemus at gmail.com  Sat Sep 12 15:54:54 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Sat, 12 Sep 2015 13:54:54 +0000
Subject: [pytest-dev] Disabling third-party application access on GitHub
In-Reply-To: <20150912133616.GI18577@tonks>
References: <20150910150536.GB18577@tonks> <20150912133616.GI18577@tonks>
Message-ID: <CA+RQFfe2pRO7nnc1nvppVThOZ5wGbkWU_x3iZceFVSaiPQJBww@mail.gmail.com>

On Sat, Sep 12, 2015 at 10:36 AM Florian Bruhin <me at the-compiler.org> wrote:

> * Florian Bruhin <me at the-compiler.org> [2015-09-10 17:05:36 +0200]:
> Who has the credentials for the pytestbot account? Bruno? I think
> you'll need to remove and re-add them, and then a pytest-dev owner
> needs to approve it there.
>

I and a few other pytestdev owners have the credentials for pytestdev, I
have shared it with you too in a separate email. If others would like to
have it too drop me a line.

I checked pytestbot "Applications" settings on GitHub and AppVeyor is
authorized there, didn't ask me to re-authorized or anything.


> Sorry again for the disruption, but I think it's better than allowing
> everything any member has activated for their own account.
>

Thanks for looking into this!

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

From nicoddemus at gmail.com  Sat Sep 12 23:45:02 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Sat, 12 Sep 2015 21:45:02 +0000
Subject: [pytest-dev] Disabling third-party application access on GitHub
In-Reply-To: <CA+RQFfe2pRO7nnc1nvppVThOZ5wGbkWU_x3iZceFVSaiPQJBww@mail.gmail.com>
References: <20150910150536.GB18577@tonks> <20150912133616.GI18577@tonks>
 <CA+RQFfe2pRO7nnc1nvppVThOZ5wGbkWU_x3iZceFVSaiPQJBww@mail.gmail.com>
Message-ID: <CA+RQFfd=WSnzTE3ns1dcbStwaqH5784smesigx9Um9o=uDLFdg@mail.gmail.com>

Hmm it seems that after this change I can't browse pytest-dev repositories
on AppVeyor anymore from my account or pytestbot's. IIUC, now AppVeyor must
be authorized again to browse pytest-dev repositories, but I don't see any
option either on the GitHub interface (
https://github.com/organizations/pytest-dev/settings/oauth_application_policy)
or in AppVeyor.

Does anyone have any tips how to do this? I was trying to add
pytest-faulthandler to AppVeyor, if it is relevant.

Cheers,


On Sat, Sep 12, 2015 at 10:54 AM Bruno Oliveira <nicoddemus at gmail.com>
wrote:

> On Sat, Sep 12, 2015 at 10:36 AM Florian Bruhin <me at the-compiler.org>
> wrote:
>
>> * Florian Bruhin <me at the-compiler.org> [2015-09-10 17:05:36 +0200]:
>>
> Who has the credentials for the pytestbot account? Bruno? I think
>> you'll need to remove and re-add them, and then a pytest-dev owner
>> needs to approve it there.
>>
>
> I and a few other pytestdev owners have the credentials for pytestdev, I
> have shared it with you too in a separate email. If others would like to
> have it too drop me a line.
>
> I checked pytestbot "Applications" settings on GitHub and AppVeyor is
> authorized there, didn't ask me to re-authorized or anything.
>
>
>> Sorry again for the disruption, but I think it's better than allowing
>> everything any member has activated for their own account.
>>
>
> Thanks for looking into this!
>
> Cheers,
> Bruno.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150912/c501438f/attachment.html>

From me at the-compiler.org  Sat Sep 12 23:57:20 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Sat, 12 Sep 2015 23:57:20 +0200
Subject: [pytest-dev] Disabling third-party application access on GitHub
In-Reply-To: <CA+RQFfd=WSnzTE3ns1dcbStwaqH5784smesigx9Um9o=uDLFdg@mail.gmail.com>
References: <20150910150536.GB18577@tonks> <20150912133616.GI18577@tonks>
 <CA+RQFfe2pRO7nnc1nvppVThOZ5wGbkWU_x3iZceFVSaiPQJBww@mail.gmail.com>
 <CA+RQFfd=WSnzTE3ns1dcbStwaqH5784smesigx9Um9o=uDLFdg@mail.gmail.com>
Message-ID: <20150912215720.GJ18577@tonks>

* Bruno Oliveira <nicoddemus at gmail.com> [2015-09-12 21:45:02 +0000]:
> Hmm it seems that after this change I can't browse pytest-dev repositories
> on AppVeyor anymore from my account or pytestbot's. IIUC, now AppVeyor must
> be authorized again to browse pytest-dev repositories, but I don't see any
> option either on the GitHub interface (
> https://github.com/organizations/pytest-dev/settings/oauth_application_policy)
> or in AppVeyor.
> 
> Does anyone have any tips how to do this? I was trying to add
> pytest-faulthandler to AppVeyor, if it is relevant.

I did the following to fix it:

- Log in to GitHub as pytestbot
- Go to the profile settings of pytestbot and revoke access for
  AppVeyor
- Try to log in to AppVeyor again with the pytestbot account, which
  will bring up the GitHub "Authorize application" screen.
- Click "Grant access" for the pytest-dev organization and "Authorize
  application".
- Go to the repo list and grant access again (for some reason,
  AppVeyor is split across two GitHub applications).

Then I could add pytest-faulthandler :)

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: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150912/51c9b0e7/attachment.sig>

From nicoddemus at gmail.com  Sat Sep 12 23:59:33 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Sat, 12 Sep 2015 21:59:33 +0000
Subject: [pytest-dev] Disabling third-party application access on GitHub
In-Reply-To: <20150912215720.GJ18577@tonks>
References: <20150910150536.GB18577@tonks> <20150912133616.GI18577@tonks>
 <CA+RQFfe2pRO7nnc1nvppVThOZ5wGbkWU_x3iZceFVSaiPQJBww@mail.gmail.com>
 <CA+RQFfd=WSnzTE3ns1dcbStwaqH5784smesigx9Um9o=uDLFdg@mail.gmail.com>
 <20150912215720.GJ18577@tonks>
Message-ID: <CA+RQFfdZGXnH3zBg0tvj3u9LEvz2mvihbPyQCd7z+R9oEc7uZQ@mail.gmail.com>

So you had to actually revoke it, like you said earlier. :)

Nice, thank you very much!

Cheers,

On Sat, Sep 12, 2015 at 6:57 PM Florian Bruhin <me at the-compiler.org> wrote:

> * Bruno Oliveira <nicoddemus at gmail.com> [2015-09-12 21:45:02 +0000]:
> > Hmm it seems that after this change I can't browse pytest-dev
> repositories
> > on AppVeyor anymore from my account or pytestbot's. IIUC, now AppVeyor
> must
> > be authorized again to browse pytest-dev repositories, but I don't see
> any
> > option either on the GitHub interface (
> >
> https://github.com/organizations/pytest-dev/settings/oauth_application_policy
> )
> > or in AppVeyor.
> >
> > Does anyone have any tips how to do this? I was trying to add
> > pytest-faulthandler to AppVeyor, if it is relevant.
>
> I did the following to fix it:
>
> - Log in to GitHub as pytestbot
> - Go to the profile settings of pytestbot and revoke access for
>   AppVeyor
> - Try to log in to AppVeyor again with the pytestbot account, which
>   will bring up the GitHub "Authorize application" screen.
> - Click "Grant access" for the pytest-dev organization and "Authorize
>   application".
> - Go to the repo list and grant access again (for some reason,
>   AppVeyor is split across two GitHub applications).
>
> Then I could add pytest-faulthandler :)
>
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150912/a3594752/attachment-0001.html>

From nicoddemus at gmail.com  Sun Sep 13 00:29:37 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Sat, 12 Sep 2015 22:29:37 +0000
Subject: [pytest-dev] Disabling third-party application access on GitHub
In-Reply-To: <CA+RQFfdZGXnH3zBg0tvj3u9LEvz2mvihbPyQCd7z+R9oEc7uZQ@mail.gmail.com>
References: <20150910150536.GB18577@tonks> <20150912133616.GI18577@tonks>
 <CA+RQFfe2pRO7nnc1nvppVThOZ5wGbkWU_x3iZceFVSaiPQJBww@mail.gmail.com>
 <CA+RQFfd=WSnzTE3ns1dcbStwaqH5784smesigx9Um9o=uDLFdg@mail.gmail.com>
 <20150912215720.GJ18577@tonks>
 <CA+RQFfdZGXnH3zBg0tvj3u9LEvz2mvihbPyQCd7z+R9oEc7uZQ@mail.gmail.com>
Message-ID: <CA+RQFfdGrE11YOcAaEqweSToc2h_MiWon-K4L3MrcLaNvPNong@mail.gmail.com>

I did the same for Travis, hopefully everything is working now. :)

Cheers,

On Sat, Sep 12, 2015 at 6:59 PM Bruno Oliveira <nicoddemus at gmail.com> wrote:

> So you had to actually revoke it, like you said earlier. :)
>
> Nice, thank you very much!
>
> Cheers,
>
> On Sat, Sep 12, 2015 at 6:57 PM Florian Bruhin <me at the-compiler.org>
> wrote:
>
>> * Bruno Oliveira <nicoddemus at gmail.com> [2015-09-12 21:45:02 +0000]:
>> > Hmm it seems that after this change I can't browse pytest-dev
>> repositories
>> > on AppVeyor anymore from my account or pytestbot's. IIUC, now AppVeyor
>> must
>> > be authorized again to browse pytest-dev repositories, but I don't see
>> any
>> > option either on the GitHub interface (
>> >
>> https://github.com/organizations/pytest-dev/settings/oauth_application_policy
>> )
>> > or in AppVeyor.
>> >
>> > Does anyone have any tips how to do this? I was trying to add
>> > pytest-faulthandler to AppVeyor, if it is relevant.
>>
>> I did the following to fix it:
>>
>> - Log in to GitHub as pytestbot
>> - Go to the profile settings of pytestbot and revoke access for
>>   AppVeyor
>> - Try to log in to AppVeyor again with the pytestbot account, which
>>   will bring up the GitHub "Authorize application" screen.
>> - Click "Grant access" for the pytest-dev organization and "Authorize
>>   application".
>> - Go to the repo list and grant access again (for some reason,
>>   AppVeyor is split across two GitHub applications).
>>
>> Then I could add pytest-faulthandler :)
>>
>> 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 --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150912/6c2a3953/attachment.html>

From opensource at ronnypfannschmidt.de  Mon Sep 14 20:21:01 2015
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Mon, 14 Sep 2015 20:21:01 +0200
Subject: [pytest-dev] Releasing a pytest-2.7.3? - can someone do it before
	the weekend?
Message-ID: <55F7100D.1010306@ronnypfannschmidt.de>

Hi,

it seems Bruno already merged a working Backport of the python 3.5 fixes
a while back,
It looks like the release can be done nicely,
but i feel like i can't do a proper release before the weekend.

-- Ronny

From holger at merlinux.eu  Mon Sep 14 12:52:50 2015
From: holger at merlinux.eu (holger krekel)
Date: Mon, 14 Sep 2015 10:52:50 +0000
Subject: [pytest-dev] Releases
In-Reply-To: <CA+RQFfep+w6mtMxmTvgt0ZaJFdpHb6Ae4Gju2oTKJ38F=D=BpQ@mail.gmail.com>
References: <20150809215509.GA14835@tonks> <20150907081552.GY9401@merlinux.eu>
 <CA+RQFfep+w6mtMxmTvgt0ZaJFdpHb6Ae4Gju2oTKJ38F=D=BpQ@mail.gmail.com>
Message-ID: <20150914105250.GV26059@merlinux.eu>

Hi Bruno, all,

On Mon, Sep 07, 2015 at 14:39 +0000, Bruno Oliveira wrote:
> Hi Holger,
> 
> Glad to have you back. :)

still struggling to get back on pytest tracks ...

> The main points holding back 2.8 I think are:
> 
> * vendoring pluggy (https://github.com/pytest-dev/pytest/pull/959)
> * merge pytest-cache into core (
> https://github.com/pytest-dev/pytest/pull/828)

thanks.  looked at both and made minor comments.  they are 99% ready for
merge from my side.

I'll plan to help with pytest-2.8 from wednesday on.  I suggest we push
ahead with releasing with the two above PRs merged (and whatever else
gets done before wednesday).

Can someone check if 2.8 works good with the just released python3.5?

Bruno, do you maybe want to be the one releasing and announcing pytest-2.8?
I'd be helping with testing and whatever comes up -- ideally through IRC.
And i guess others would be ready to help as well.  If not, anyone else
stepping forward?

cheers,
holger


> Cheers,
> Bruno.
> 
> 
> On Mon, Sep 7, 2015 at 5:16 AM holger krekel <holger at merlinux.eu> wrote:
> 
> > Hi Florian, all,
> >
> > i am finally getting back into coding/project work again.
> > FWIW i think we should get 2.8 out the door ASAP.  Before
> > i can help much with it i need to get new devpi releases out
> > and i am not sure at the moment how much work that is.
> >
> > If anyone can point me to where my feedback/work for pytest-2.8
> > would be most needed, i'd be grateful. (still catching up with
> > my mail box after >4 weeks offtime and that will take some whiles ...)
> >
> > cheers,
> > holger
> >
> >
> > On Sun, Aug 09, 2015 at 23:55 +0200, Florian Bruhin wrote:
> > > Hi!
> > >
> > > We've been talking about doing a release since somewhen before
> > > EuroPython and there's still no release with Python 3.5 support out
> > > yet ;)
> > >
> > > What's missing for a 2.7.3, and what for 2.8.0? Does it make sense to
> > > release 2.7.3, or should we go for 2.8.0 directly?
> > >
> > > Looking at the changelog, 2.8 has some bugfixes as well (I'm guilty on
> > > that one), so I wonder if we should just release that directly (and
> > > when).
> > >
> > > Either way, both have features/fixes I'm eagerly waiting for, and
> > > enough changes to warrant a release IMHO.
> > >
> > > 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
> >
> >
> > --
> > 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
> >

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

From holger at merlinux.eu  Tue Sep 15 13:57:02 2015
From: holger at merlinux.eu (holger krekel)
Date: Tue, 15 Sep 2015 11:57:02 +0000
Subject: [pytest-dev] pytest-2.7.3: fixes and py35 compat
Message-ID: <20150915115702.GY26059@merlinux.eu>

Hi all,

I just pushed pytest-2.7.3 to pypi which contains bugfixes including
compatibility to python3.5 which was released yesterday.

In case you wonder, pytest is a widely used mature test runner both for
unit and functional test purposes in python.  See http://pytest.org for
documentation and examples.

Thanks to contributors for this release, among them:

Bruno Oliveira, Florian Bruhin, Floris Bruynooghe, Ronny Pfannschmidt,
Eric Hunsberg, Barney Gale, Guido van Rossum, Matthias Matthias
Bussonier, Stefan Zimmermann, Thomas Kluyver, Pieter Mulder, Raphael
Pierzina.

best,
holger krekel 

P.S.: we are also preparing a pytest-2.8 which has a much longer list of
changes/features.


2.7.3 (compared to 2.7.2)
-----------------------------

- Allow 'dev', 'rc', or other non-integer version strings in `importorskip`.
  Thanks to Eric Hunsberger for the PR.

- fix issue856: consider --color parameter in all outputs (for example
  --fixtures). Thanks Barney Gale for the report and Bruno Oliveira for the PR.

- fix issue855: passing str objects as `plugins` argument to pytest.main
  is now interpreted as a module name to be imported and registered as a
  plugin, instead of silently having no effect.
  Thanks xmo-odoo for the report and Bruno Oliveira for the PR.

- fix issue744: fix for ast.Call changes in Python 3.5+.  Thanks
  Guido van Rossum, Matthias Bussonnier, Stefan Zimmermann and
  Thomas Kluyver.

- fix issue842: applying markers in classes no longer propagate this markers
  to superclasses which also have markers.
  Thanks xmo-odoo for the report and Bruno Oliveira for the PR.

- preserve warning functions after call to pytest.deprecated_call. Thanks
  Pieter Mulder for PR.

- fix issue854: autouse yield_fixtures defined as class members of
  unittest.TestCase subclasses now work as expected.
  Thannks xmo-odoo for the report and Bruno Oliveira for the PR.

- fix issue833: --fixtures now shows all fixtures of collected test files, instead of just the
  fixtures declared on the first one.
  Thanks Florian Bruhin for reporting and Bruno Oliveira for the PR.

- fix issue863: skipped tests now report the correct reason when a skip/xfail
  condition is met when using multiple markers.
  Thanks Raphael Pierzina for reporting and Bruno Oliveira for the PR.

- optimized tmpdir fixture initialization, which should make test sessions
  faster (specially when using pytest-xdist). The only visible effect
  is that now pytest uses a subdirectory in the $TEMP directory for all
  directories created by this fixture (defaults to $TEMP/pytest-$USER).
  Thanks Bruno Oliveira for the PR.

From nicoddemus at gmail.com  Tue Sep 15 16:41:21 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 15 Sep 2015 14:41:21 +0000
Subject: [pytest-dev] Releases
In-Reply-To: <20150914105250.GV26059@merlinux.eu>
References: <20150809215509.GA14835@tonks> <20150907081552.GY9401@merlinux.eu>
 <CA+RQFfep+w6mtMxmTvgt0ZaJFdpHb6Ae4Gju2oTKJ38F=D=BpQ@mail.gmail.com>
 <20150914105250.GV26059@merlinux.eu>
Message-ID: <CA+RQFferMboY2LLHXmL8z9W6UQ-FbXYwr0_Wd8mtrv3xWdeYfw@mail.gmail.com>

On Tue, Sep 15, 2015 at 5:37 AM holger krekel <holger at merlinux.eu> wrote:

> Bruno, do you maybe want to be the one releasing and announcing pytest-2.8?
> I'd be helping with testing and whatever comes up -- ideally through IRC.
> And i guess others would be ready to help as well.  If not, anyone else
> stepping forward?
>

No problem, I will start the release process Wednesday then.

Cheers,
Bruno.


> cheers,
> holger
>
>
> > Cheers,
> > Bruno.
> >
> >
> > On Mon, Sep 7, 2015 at 5:16 AM holger krekel <holger at merlinux.eu> wrote:
> >
> > > Hi Florian, all,
> > >
> > > i am finally getting back into coding/project work again.
> > > FWIW i think we should get 2.8 out the door ASAP.  Before
> > > i can help much with it i need to get new devpi releases out
> > > and i am not sure at the moment how much work that is.
> > >
> > > If anyone can point me to where my feedback/work for pytest-2.8
> > > would be most needed, i'd be grateful. (still catching up with
> > > my mail box after >4 weeks offtime and that will take some whiles ...)
> > >
> > > cheers,
> > > holger
> > >
> > >
> > > On Sun, Aug 09, 2015 at 23:55 +0200, Florian Bruhin wrote:
> > > > Hi!
> > > >
> > > > We've been talking about doing a release since somewhen before
> > > > EuroPython and there's still no release with Python 3.5 support out
> > > > yet ;)
> > > >
> > > > What's missing for a 2.7.3, and what for 2.8.0? Does it make sense to
> > > > release 2.7.3, or should we go for 2.8.0 directly?
> > > >
> > > > Looking at the changelog, 2.8 has some bugfixes as well (I'm guilty
> on
> > > > that one), so I wonder if we should just release that directly (and
> > > > when).
> > > >
> > > > Either way, both have features/fixes I'm eagerly waiting for, and
> > > > enough changes to warrant a release IMHO.
> > > >
> > > > 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
> > >
> > >
> > > --
> > > 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
> > >
>
> --
> about me:    http://holgerkrekel.net/about-me/
> contracting: http://merlinux.eu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150915/913cb020/attachment.html>

From holger at merlinux.eu  Thu Sep 17 14:37:48 2015
From: holger at merlinux.eu (holger krekel)
Date: Thu, 17 Sep 2015 12:37:48 +0000
Subject: [pytest-dev] Releases
In-Reply-To: <CA+RQFferMboY2LLHXmL8z9W6UQ-FbXYwr0_Wd8mtrv3xWdeYfw@mail.gmail.com>
References: <20150809215509.GA14835@tonks> <20150907081552.GY9401@merlinux.eu>
 <CA+RQFfep+w6mtMxmTvgt0ZaJFdpHb6Ae4Gju2oTKJ38F=D=BpQ@mail.gmail.com>
 <20150914105250.GV26059@merlinux.eu>
 <CA+RQFferMboY2LLHXmL8z9W6UQ-FbXYwr0_Wd8mtrv3xWdeYfw@mail.gmail.com>
Message-ID: <20150917123748.GD26059@merlinux.eu>

Hi Bruno, all,

i've also done some release preps now, merged some PRs etc.  The
current release testing candidate looks good testing wise:

    https://devpi.net/hpk/dev/pytest/2.8.0.dev6

The one "flakes" env failing for the wheel has to do with the cx_freeze
tests which were run with the "sdist" pacckage, the latter pollutes the
testing directory which then lets flakes fail.  I think cx_freeze should
not create anything in testing but rather in maybe ROOT/.tmp/ or something.
This we could also use "detox" to run tests concurrently more safely.
Could you look into this?

What is otherwise missing is a release announcement and doc regen
and maybe some last PRs :)

Speaking of doc regen: when i do "tox -e regen" i am getting it works for
a while and then results in:
OSError: [Errno 17] File exists: '/tmp/regendoc-exec-GzZfWJ/nonpython.rst-76/nonpython'

Does it work for you?

holger



On Tue, Sep 15, 2015 at 14:41 +0000, Bruno Oliveira wrote:
> On Tue, Sep 15, 2015 at 5:37 AM holger krekel <holger at merlinux.eu> wrote:
> 
> > Bruno, do you maybe want to be the one releasing and announcing pytest-2.8?
> > I'd be helping with testing and whatever comes up -- ideally through IRC.
> > And i guess others would be ready to help as well.  If not, anyone else
> > stepping forward?
> >
> 
> No problem, I will start the release process Wednesday then.
> 
> Cheers,
> Bruno.
> 
> 
> > cheers,
> > holger
> >
> >
> > > Cheers,
> > > Bruno.
> > >
> > >
> > > On Mon, Sep 7, 2015 at 5:16 AM holger krekel <holger at merlinux.eu> wrote:
> > >
> > > > Hi Florian, all,
> > > >
> > > > i am finally getting back into coding/project work again.
> > > > FWIW i think we should get 2.8 out the door ASAP.  Before
> > > > i can help much with it i need to get new devpi releases out
> > > > and i am not sure at the moment how much work that is.
> > > >
> > > > If anyone can point me to where my feedback/work for pytest-2.8
> > > > would be most needed, i'd be grateful. (still catching up with
> > > > my mail box after >4 weeks offtime and that will take some whiles ...)
> > > >
> > > > cheers,
> > > > holger
> > > >
> > > >
> > > > On Sun, Aug 09, 2015 at 23:55 +0200, Florian Bruhin wrote:
> > > > > Hi!
> > > > >
> > > > > We've been talking about doing a release since somewhen before
> > > > > EuroPython and there's still no release with Python 3.5 support out
> > > > > yet ;)
> > > > >
> > > > > What's missing for a 2.7.3, and what for 2.8.0? Does it make sense to
> > > > > release 2.7.3, or should we go for 2.8.0 directly?
> > > > >
> > > > > Looking at the changelog, 2.8 has some bugfixes as well (I'm guilty
> > on
> > > > > that one), so I wonder if we should just release that directly (and
> > > > > when).
> > > > >
> > > > > Either way, both have features/fixes I'm eagerly waiting for, and
> > > > > enough changes to warrant a release IMHO.
> > > > >
> > > > > 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
> > > >
> > > >
> > > > --
> > > > 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
> > > >
> >
> > --
> > about me:    http://holgerkrekel.net/about-me/
> > contracting: http://merlinux.eu
> >

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

From holger at merlinux.eu  Thu Sep 17 15:04:05 2015
From: holger at merlinux.eu (holger krekel)
Date: Thu, 17 Sep 2015 13:04:05 +0000
Subject: [pytest-dev] Releases
In-Reply-To: <BCA0B0DD-701A-4124-A7BE-B33698E964EC@ronnypfannschmidt.de>
References: <20150809215509.GA14835@tonks> <20150907081552.GY9401@merlinux.eu>
 <CA+RQFfep+w6mtMxmTvgt0ZaJFdpHb6Ae4Gju2oTKJ38F=D=BpQ@mail.gmail.com>
 <20150914105250.GV26059@merlinux.eu>
 <CA+RQFferMboY2LLHXmL8z9W6UQ-FbXYwr0_Wd8mtrv3xWdeYfw@mail.gmail.com>
 <20150917123748.GD26059@merlinux.eu>
 <BCA0B0DD-701A-4124-A7BE-B33698E964EC@ronnypfannschmidt.de>
Message-ID: <20150917130405.GE26059@merlinux.eu>

On Thu, Sep 17, 2015 at 14:53 +0200, Ronny Pfannschmidt wrote:
> Can you review the 2.8 milestone on. Gh?

I'll take a brief look and see what can be done within my time limits

however, i think we shouldn't block 2.8 for any of the issues -- it
already contains more changes and fixes/improvements than most the
pytest releases of the last 1-2 years or so.

best,
holger


> Am 17. September 2015 14:37:48 MESZ, schrieb holger krekel <holger at merlinux.eu>:
> >Hi Bruno, all,
> >
> >i've also done some release preps now, merged some PRs etc.  The
> >current release testing candidate looks good testing wise:
> >
> >    https://devpi.net/hpk/dev/pytest/2.8.0.dev6
> >
> >The one "flakes" env failing for the wheel has to do with the cx_freeze
> >tests which were run with the "sdist" pacckage, the latter pollutes the
> >testing directory which then lets flakes fail.  I think cx_freeze
> >should
> >not create anything in testing but rather in maybe ROOT/.tmp/ or
> >something.
> >This we could also use "detox" to run tests concurrently more safely.
> >Could you look into this?
> >
> >What is otherwise missing is a release announcement and doc regen
> >and maybe some last PRs :)
> >
> >Speaking of doc regen: when i do "tox -e regen" i am getting it works
> >for
> >a while and then results in:
> >OSError: [Errno 17] File exists:
> >'/tmp/regendoc-exec-GzZfWJ/nonpython.rst-76/nonpython'
> >
> >Does it work for you?
> >
> >holger
> >
> >
> >
> >On Tue, Sep 15, 2015 at 14:41 +0000, Bruno Oliveira wrote:
> >> On Tue, Sep 15, 2015 at 5:37 AM holger krekel <holger at merlinux.eu>
> >wrote:
> >> 
> >> > Bruno, do you maybe want to be the one releasing and announcing
> >pytest-2.8?
> >> > I'd be helping with testing and whatever comes up -- ideally
> >through IRC.
> >> > And i guess others would be ready to help as well.  If not, anyone
> >else
> >> > stepping forward?
> >> >
> >> 
> >> No problem, I will start the release process Wednesday then.
> >> 
> >> Cheers,
> >> Bruno.
> >> 
> >> 
> >> > cheers,
> >> > holger
> >> >
> >> >
> >> > > Cheers,
> >> > > Bruno.
> >> > >
> >> > >
> >> > > On Mon, Sep 7, 2015 at 5:16 AM holger krekel <holger at merlinux.eu>
> >wrote:
> >> > >
> >> > > > Hi Florian, all,
> >> > > >
> >> > > > i am finally getting back into coding/project work again.
> >> > > > FWIW i think we should get 2.8 out the door ASAP.  Before
> >> > > > i can help much with it i need to get new devpi releases out
> >> > > > and i am not sure at the moment how much work that is.
> >> > > >
> >> > > > If anyone can point me to where my feedback/work for pytest-2.8
> >> > > > would be most needed, i'd be grateful. (still catching up with
> >> > > > my mail box after >4 weeks offtime and that will take some
> >whiles ...)
> >> > > >
> >> > > > cheers,
> >> > > > holger
> >> > > >
> >> > > >
> >> > > > On Sun, Aug 09, 2015 at 23:55 +0200, Florian Bruhin wrote:
> >> > > > > Hi!
> >> > > > >
> >> > > > > We've been talking about doing a release since somewhen
> >before
> >> > > > > EuroPython and there's still no release with Python 3.5
> >support out
> >> > > > > yet ;)
> >> > > > >
> >> > > > > What's missing for a 2.7.3, and what for 2.8.0? Does it make
> >sense to
> >> > > > > release 2.7.3, or should we go for 2.8.0 directly?
> >> > > > >
> >> > > > > Looking at the changelog, 2.8 has some bugfixes as well (I'm
> >guilty
> >> > on
> >> > > > > that one), so I wonder if we should just release that
> >directly (and
> >> > > > > when).
> >> > > > >
> >> > > > > Either way, both have features/fixes I'm eagerly waiting for,
> >and
> >> > > > > enough changes to warrant a release IMHO.
> >> > > > >
> >> > > > > 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
> >> > > >
> >> > > >
> >> > > > --
> >> > > > 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
> >> > > >
> >> >
> >> > --
> >> > about me:    http://holgerkrekel.net/about-me/
> >> > contracting: http://merlinux.eu
> >> >
> 
> MFG Ronny
> 

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

From nicoddemus at gmail.com  Thu Sep 17 17:16:46 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Thu, 17 Sep 2015 15:16:46 +0000
Subject: [pytest-dev] Releases
In-Reply-To: <20150917123748.GD26059@merlinux.eu>
References: <20150809215509.GA14835@tonks> <20150907081552.GY9401@merlinux.eu>
 <CA+RQFfep+w6mtMxmTvgt0ZaJFdpHb6Ae4Gju2oTKJ38F=D=BpQ@mail.gmail.com>
 <20150914105250.GV26059@merlinux.eu>
 <CA+RQFferMboY2LLHXmL8z9W6UQ-FbXYwr0_Wd8mtrv3xWdeYfw@mail.gmail.com>
 <20150917123748.GD26059@merlinux.eu>
Message-ID: <CA+RQFffvooAwQUgs+dRQWJ=xbSt9pK0N4XXzcJK=wn_8bObLUg@mail.gmail.com>

On Thu, Sep 17, 2015 at 9:37 AM holger krekel <holger at merlinux.eu> wrote:

> The one "flakes" env failing for the wheel has to do with the cx_freeze
> tests which were run with the "sdist" pacckage, the latter pollutes the
> testing directory which then lets flakes fail.  I think cx_freeze should
> not create anything in testing but rather in maybe ROOT/.tmp/ or something.
> This we could also use "detox" to run tests concurrently more safely.
> Could you look into this?
>

Opened a PR with that change. :)



> What is otherwise missing is a release announcement and doc regen
> and maybe some last PRs :)
>

I will make the release tomorrow to get sometime to merge those PRs.

Speaking of doc regen: when i do "tox -e regen" i am getting it works for
> a while and then results in:
> OSError: [Errno 17] File exists:
> '/tmp/regendoc-exec-GzZfWJ/nonpython.rst-76/nonpython'
>
> Does it work for you?
>

Hmm I get the same error when running on a ubuntu virtualbox... perhaps
Ronny can chip in?

Cheers,
Bruno.

On Tue, Sep 15, 2015 at 14:41 +0000, Bruno Oliveira wrote:
> > On Tue, Sep 15, 2015 at 5:37 AM holger krekel <holger at merlinux.eu>
> wrote:
> >
> > > Bruno, do you maybe want to be the one releasing and announcing
> pytest-2.8?
> > > I'd be helping with testing and whatever comes up -- ideally through
> IRC.
> > > And i guess others would be ready to help as well.  If not, anyone else
> > > stepping forward?
> > >
> >
> > No problem, I will start the release process Wednesday then.
> >
> > Cheers,
> > Bruno.
> >
> >
> > > cheers,
> > > holger
> > >
> > >
> > > > Cheers,
> > > > Bruno.
> > > >
> > > >
> > > > On Mon, Sep 7, 2015 at 5:16 AM holger krekel <holger at merlinux.eu>
> wrote:
> > > >
> > > > > Hi Florian, all,
> > > > >
> > > > > i am finally getting back into coding/project work again.
> > > > > FWIW i think we should get 2.8 out the door ASAP.  Before
> > > > > i can help much with it i need to get new devpi releases out
> > > > > and i am not sure at the moment how much work that is.
> > > > >
> > > > > If anyone can point me to where my feedback/work for pytest-2.8
> > > > > would be most needed, i'd be grateful. (still catching up with
> > > > > my mail box after >4 weeks offtime and that will take some whiles
> ...)
> > > > >
> > > > > cheers,
> > > > > holger
> > > > >
> > > > >
> > > > > On Sun, Aug 09, 2015 at 23:55 +0200, Florian Bruhin wrote:
> > > > > > Hi!
> > > > > >
> > > > > > We've been talking about doing a release since somewhen before
> > > > > > EuroPython and there's still no release with Python 3.5 support
> out
> > > > > > yet ;)
> > > > > >
> > > > > > What's missing for a 2.7.3, and what for 2.8.0? Does it make
> sense to
> > > > > > release 2.7.3, or should we go for 2.8.0 directly?
> > > > > >
> > > > > > Looking at the changelog, 2.8 has some bugfixes as well (I'm
> guilty
> > > on
> > > > > > that one), so I wonder if we should just release that directly
> (and
> > > > > > when).
> > > > > >
> > > > > > Either way, both have features/fixes I'm eagerly waiting for, and
> > > > > > enough changes to warrant a release IMHO.
> > > > > >
> > > > > > 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
> > > > >
> > > > >
> > > > > --
> > > > > 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
> > > > >
> > >
> > > --
> > > about me:    http://holgerkrekel.net/about-me/
> > > contracting: http://merlinux.eu
> > >
>
> --
> about me:    http://holgerkrekel.net/about-me/
> contracting: http://merlinux.eu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150917/cdf5f310/attachment-0001.html>

From nicoddemus at gmail.com  Sat Sep 19 00:09:15 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Fri, 18 Sep 2015 22:09:15 +0000
Subject: [pytest-dev] pytest 2.8
Message-ID: <CA+RQFfd_kT0sdKL9F7WytVXGuGNOMNREcjfJDwiMWNdkN99+nQ@mail.gmail.com>

Hi all,

pytest 2.8 has been released to pypi, with significant bug-fixes and
features.

In case you wonder, pytest is a widely used mature test runner both for
unit and functional test purposes in python.  See http://pytest.org for
documentation and examples.

Here's the changelog for this version:

- new ``--lf`` and ``-ff`` options to run only the last failing tests or
  "failing tests first" from the last run.  This functionality is provided
  through porting the formerly external pytest-cache plugin into pytest
core.
  BACKWARD INCOMPAT: if you used pytest-cache's functionality to persist
  data between test runs be aware that we don't serialize sets anymore.
  Thanks Ronny Pfannschmidt for most of the merging work.

- "-r" option now accepts "a" to include all possible reports, similar
  to passing "fEsxXw" explicitly (isse960).
  Thanks Abhijeet Kasurde for the PR.

- avoid python3.5 deprecation warnings by introducing version
  specific inspection helpers, thanks Michael Droettboom.

- fix issue562: @nose.tools.istest now fully respected.

- fix issue934: when string comparison fails and a diff is too large to
display
  without passing -vv, still show a few lines of the diff.
  Thanks Florian Bruhin for the report and Bruno Oliveira for the PR.

- fix issue736: Fix a bug where fixture params would be discarded when
combined
  with parametrization markers.
  Thanks to Markus Unterwaditzer for the PR.

- fix issue710: introduce ALLOW_UNICODE doctest option: when enabled, the
  ``u`` prefix is stripped from unicode strings in expected doctest output.
This
  allows doctests which use unicode to run in Python 2 and 3 unchanged.
  Thanks Jason R. Coombs for the report and Bruno Oliveira for the PR.

- parametrize now also generates meaningful test IDs for enum, regex and
class
  objects (as opposed to class instances).
  Thanks to Florian Bruhin for the PR.

- Add 'warns' to assert that warnings are thrown (like 'raises').
  Thanks to Eric Hunsberger for the PR.

- Fix issue683: Do not apply an already applied mark.  Thanks ojake for the
PR.

- Deal with capturing failures better so fewer exceptions get lost to
  /dev/null.  Thanks David Szotten for the PR.

- fix issue730: deprecate and warn about the --genscript option.
  Thanks Ronny Pfannschmidt for the report and Christian Pommranz for the
PR.

- fix issue751: multiple parametrize with ids bug if it parametrizes class
with
  two or more test methods. Thanks Sergey Chipiga for reporting and Jan
  Bednarik for PR.

- fix issue82: avoid loading conftest files from
setup.cfg/pytest.ini/tox.ini
  files and upwards by default (--confcutdir can still be set to override
this).
  Thanks Bruno Oliveira for the PR.

- fix issue768: docstrings found in python modules were not setting up
session
  fixtures. Thanks Jason R. Coombs for reporting and Bruno Oliveira for the
PR.

- added `tmpdir_factory`, a session-scoped fixture that can be used to
create
  directories under the base temporary directory. Previously this object was
  installed as a `_tmpdirhandler` attribute of the `config` object, but now
it
  is part of the official API and using `config._tmpdirhandler` is
  deprecated.
  Thanks Bruno Oliveira for the PR.

- fix issue808: pytest's internal assertion rewrite hook now implements the
  optional PEP302 get_data API so tests can access data files next to them.
  Thanks xmo-odoo for request and example and Bruno Oliveira for
  the PR.

- rootdir and inifile are now displayed during usage errors to help
  users diagnose problems such as unexpected ini files which add
  unknown options being picked up by pytest. Thanks to Pavel Savchenko for
  bringing the problem to attention in #821 and Bruno Oliveira for the PR.

- Summary bar now is colored yellow for warning
  situations such as: all tests either were skipped or xpass/xfailed,
  or no tests were run at all (this is a partial fix for issue500).

- fix issue812: pytest now exits with status code 5 in situations where no
  tests were run at all, such as the directory given in the command line
does
  not contain any tests or as result of a command line option filters
  all out all tests (-k for example).
  Thanks Eric Siegerman (issue812) and Bruno Oliveira for the PR.

- Summary bar now is colored yellow for warning
  situations such as: all tests either were skipped or xpass/xfailed,
  or no tests were run at all (related to issue500).
  Thanks Eric Siegerman.

- New `testpaths` ini option: list of directories to search for tests
  when executing pytest from the root directory. This can be used
  to speed up test collection when a project has well specified directories
  for tests, being usually more practical than configuring norecursedirs for
  all directories that do not contain tests.
  Thanks to Adrian for idea (#694) and Bruno Oliveira for the PR.

- fix issue713: JUnit XML reports for doctest failures.
  Thanks Punyashloka Biswal.

- fix issue970: internal pytest warnings now appear as "pytest-warnings" in
  the terminal instead of "warnings", so it is clear for users that those
  warnings are from pytest and not from the builtin "warnings" module.
  Thanks Bruno Oliveira.

- Include setup and teardown in junitxml test durations.
  Thanks Janne Vanhala.

- fix issue735: assertion failures on debug versions of Python 3.4+

- new option ``--import-mode`` to allow to change test module importing
  behaviour to append to sys.path instead of prepending.  This better
allows
  to run test modules against installated versions of a package even if the
  package under test has the same import root.  In this example::

        testing/__init__.py
        testing/test_pkg_under_test.py
        pkg_under_test/

  the tests will run against the installed version
  of pkg_under_test when ``--import-mode=append`` is used whereas
  by default they would always pick up the local version.  Thanks Holger
Krekel.

- pytester: add method ``TmpTestdir.delete_loaded_modules()``, and call it
  from ``inline_run()`` to allow temporary modules to be reloaded.
  Thanks Eduardo Schettino.

- internally refactor pluginmanager API and code so that there
  is a clear distinction between a pytest-agnostic rather simple
  pluginmanager and the PytestPluginManager which adds a lot of
  behaviour, among it handling of the local conftest files.
  In terms of documented methods this is a backward compatible
  change but it might still break 3rd party plugins which relied on
  details like especially the pluginmanager.add_shutdown() API.
  Thanks Holger Krekel.

- pluginmanagement: introduce ``pytest.hookimpl`` and
  ``pytest.hookspec`` decorators for setting impl/spec
  specific parameters.  This substitutes the previous
  now deprecated use of ``pytest.mark`` which is meant to
  contain markers for test functions only.

- write/refine docs for "writing plugins" which now have their
  own page and are separate from the "using/installing plugins`` page.

- fix issue732: properly unregister plugins from any hook calling
  sites allowing to have temporary plugins during test execution.

- deprecate and warn about ``__multicall__`` argument in hook
  implementations.  Use the ``hookwrapper`` mechanism instead already
  introduced with pytest-2.7.

- speed up pytest's own test suite considerably by using inprocess
  tests by default (testrun can be modified with --runpytest=subprocess
  to create subprocesses in many places instead).  The main
  APIs to run pytest in a test is "runpytest()" or "runpytest_subprocess"
  and "runpytest_inprocess" if you need a particular way of running
  the test.  In all cases you get back a RunResult but the inprocess
  one will also have a "reprec" attribute with the recorded events/reports.

- fix monkeypatch.setattr("x.y", raising=False) to actually not raise
  if "y" is not a pre-existing attribute. Thanks Florian Bruhin.

- fix issue741: make running output from testdir.run copy/pasteable
  Thanks Bruno Oliveira.

- add a new ``--noconftest`` argument which ignores all ``conftest.py``
files.

- add ``file`` and ``line`` attributes to JUnit-XML output.

- fix issue890: changed extension of all documentation files from ``txt`` to
  ``rst``. Thanks to Abhijeet for the PR.

- fix issue714: add ability to apply indirect=True parameter on particular
argnames.
  Thanks Elizaveta239.

- fix issue714: add ability to apply indirect=True parameter on particular
argnames.

- fix issue890: changed extension of all documentation files from ``txt`` to
  ``rst``. Thanks to Abhijeet for the PR.

- fix issue957: "# doctest: SKIP" option will now register doctests as
SKIPPED
  rather than PASSED.
  Thanks Thomas Grainger for the report and Bruno Oliveira for the PR.

- issue951: add new record_xml_property fixture, that supports logging
  additional information on xml output. Thanks David Diaz for the PR.

- issue949: paths after normal options (for example `-s`, `-v`, etc) are now
  properly used to discover `rootdir` and `ini` files.
  Thanks Peter Lauri 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/20150918/9dc6da6e/attachment.html>

From holger at merlinux.eu  Sat Sep 19 09:34:58 2015
From: holger at merlinux.eu (holger krekel)
Date: Sat, 19 Sep 2015 07:34:58 +0000
Subject: [pytest-dev] [TIP] pytest 2.8
In-Reply-To: <CA+RQFfd_kT0sdKL9F7WytVXGuGNOMNREcjfJDwiMWNdkN99+nQ@mail.gmail.com>
References: <CA+RQFfd_kT0sdKL9F7WytVXGuGNOMNREcjfJDwiMWNdkN99+nQ@mail.gmail.com>
Message-ID: <20150919073458.GM26059@merlinux.eu>

Hi Bruno,

thanks for all the work on pytest-2.8 and the release!

Was wondering -- did you conciously choose to not re-create and install
docs before releasing? 

FWIW I just regen'ed docs and pointed pytest.org/latest to 2.8 (it previously
had "latest" point to 2.7).  The regen did not run fully to the end
so some examples have not been regenerated yet but it's better than having
a fully outdated doc version i think.  Maybe ronny could take a look why
"tox -e regen" chokes? 

cheers,
holger



On Fri, Sep 18, 2015 at 22:09 +0000, Bruno Oliveira wrote:
> Hi all,
> 
> pytest 2.8 has been released to pypi, with significant bug-fixes and
> features.
> 
> In case you wonder, pytest is a widely used mature test runner both for
> unit and functional test purposes in python.  See http://pytest.org for
> documentation and examples.
> 
> Here's the changelog for this version:
> 
> - new ``--lf`` and ``-ff`` options to run only the last failing tests or
>   "failing tests first" from the last run.  This functionality is provided
>   through porting the formerly external pytest-cache plugin into pytest
> core.
>   BACKWARD INCOMPAT: if you used pytest-cache's functionality to persist
>   data between test runs be aware that we don't serialize sets anymore.
>   Thanks Ronny Pfannschmidt for most of the merging work.
> 
> - "-r" option now accepts "a" to include all possible reports, similar
>   to passing "fEsxXw" explicitly (isse960).
>   Thanks Abhijeet Kasurde for the PR.
> 
> - avoid python3.5 deprecation warnings by introducing version
>   specific inspection helpers, thanks Michael Droettboom.
> 
> - fix issue562: @nose.tools.istest now fully respected.
> 
> - fix issue934: when string comparison fails and a diff is too large to
> display
>   without passing -vv, still show a few lines of the diff.
>   Thanks Florian Bruhin for the report and Bruno Oliveira for the PR.
> 
> - fix issue736: Fix a bug where fixture params would be discarded when
> combined
>   with parametrization markers.
>   Thanks to Markus Unterwaditzer for the PR.
> 
> - fix issue710: introduce ALLOW_UNICODE doctest option: when enabled, the
>   ``u`` prefix is stripped from unicode strings in expected doctest output.
> This
>   allows doctests which use unicode to run in Python 2 and 3 unchanged.
>   Thanks Jason R. Coombs for the report and Bruno Oliveira for the PR.
> 
> - parametrize now also generates meaningful test IDs for enum, regex and
> class
>   objects (as opposed to class instances).
>   Thanks to Florian Bruhin for the PR.
> 
> - Add 'warns' to assert that warnings are thrown (like 'raises').
>   Thanks to Eric Hunsberger for the PR.
> 
> - Fix issue683: Do not apply an already applied mark.  Thanks ojake for the
> PR.
> 
> - Deal with capturing failures better so fewer exceptions get lost to
>   /dev/null.  Thanks David Szotten for the PR.
> 
> - fix issue730: deprecate and warn about the --genscript option.
>   Thanks Ronny Pfannschmidt for the report and Christian Pommranz for the
> PR.
> 
> - fix issue751: multiple parametrize with ids bug if it parametrizes class
> with
>   two or more test methods. Thanks Sergey Chipiga for reporting and Jan
>   Bednarik for PR.
> 
> - fix issue82: avoid loading conftest files from
> setup.cfg/pytest.ini/tox.ini
>   files and upwards by default (--confcutdir can still be set to override
> this).
>   Thanks Bruno Oliveira for the PR.
> 
> - fix issue768: docstrings found in python modules were not setting up
> session
>   fixtures. Thanks Jason R. Coombs for reporting and Bruno Oliveira for the
> PR.
> 
> - added `tmpdir_factory`, a session-scoped fixture that can be used to
> create
>   directories under the base temporary directory. Previously this object was
>   installed as a `_tmpdirhandler` attribute of the `config` object, but now
> it
>   is part of the official API and using `config._tmpdirhandler` is
>   deprecated.
>   Thanks Bruno Oliveira for the PR.
> 
> - fix issue808: pytest's internal assertion rewrite hook now implements the
>   optional PEP302 get_data API so tests can access data files next to them.
>   Thanks xmo-odoo for request and example and Bruno Oliveira for
>   the PR.
> 
> - rootdir and inifile are now displayed during usage errors to help
>   users diagnose problems such as unexpected ini files which add
>   unknown options being picked up by pytest. Thanks to Pavel Savchenko for
>   bringing the problem to attention in #821 and Bruno Oliveira for the PR.
> 
> - Summary bar now is colored yellow for warning
>   situations such as: all tests either were skipped or xpass/xfailed,
>   or no tests were run at all (this is a partial fix for issue500).
> 
> - fix issue812: pytest now exits with status code 5 in situations where no
>   tests were run at all, such as the directory given in the command line
> does
>   not contain any tests or as result of a command line option filters
>   all out all tests (-k for example).
>   Thanks Eric Siegerman (issue812) and Bruno Oliveira for the PR.
> 
> - Summary bar now is colored yellow for warning
>   situations such as: all tests either were skipped or xpass/xfailed,
>   or no tests were run at all (related to issue500).
>   Thanks Eric Siegerman.
> 
> - New `testpaths` ini option: list of directories to search for tests
>   when executing pytest from the root directory. This can be used
>   to speed up test collection when a project has well specified directories
>   for tests, being usually more practical than configuring norecursedirs for
>   all directories that do not contain tests.
>   Thanks to Adrian for idea (#694) and Bruno Oliveira for the PR.
> 
> - fix issue713: JUnit XML reports for doctest failures.
>   Thanks Punyashloka Biswal.
> 
> - fix issue970: internal pytest warnings now appear as "pytest-warnings" in
>   the terminal instead of "warnings", so it is clear for users that those
>   warnings are from pytest and not from the builtin "warnings" module.
>   Thanks Bruno Oliveira.
> 
> - Include setup and teardown in junitxml test durations.
>   Thanks Janne Vanhala.
> 
> - fix issue735: assertion failures on debug versions of Python 3.4+
> 
> - new option ``--import-mode`` to allow to change test module importing
>   behaviour to append to sys.path instead of prepending.  This better
> allows
>   to run test modules against installated versions of a package even if the
>   package under test has the same import root.  In this example::
> 
>         testing/__init__.py
>         testing/test_pkg_under_test.py
>         pkg_under_test/
> 
>   the tests will run against the installed version
>   of pkg_under_test when ``--import-mode=append`` is used whereas
>   by default they would always pick up the local version.  Thanks Holger
> Krekel.
> 
> - pytester: add method ``TmpTestdir.delete_loaded_modules()``, and call it
>   from ``inline_run()`` to allow temporary modules to be reloaded.
>   Thanks Eduardo Schettino.
> 
> - internally refactor pluginmanager API and code so that there
>   is a clear distinction between a pytest-agnostic rather simple
>   pluginmanager and the PytestPluginManager which adds a lot of
>   behaviour, among it handling of the local conftest files.
>   In terms of documented methods this is a backward compatible
>   change but it might still break 3rd party plugins which relied on
>   details like especially the pluginmanager.add_shutdown() API.
>   Thanks Holger Krekel.
> 
> - pluginmanagement: introduce ``pytest.hookimpl`` and
>   ``pytest.hookspec`` decorators for setting impl/spec
>   specific parameters.  This substitutes the previous
>   now deprecated use of ``pytest.mark`` which is meant to
>   contain markers for test functions only.
> 
> - write/refine docs for "writing plugins" which now have their
>   own page and are separate from the "using/installing plugins`` page.
> 
> - fix issue732: properly unregister plugins from any hook calling
>   sites allowing to have temporary plugins during test execution.
> 
> - deprecate and warn about ``__multicall__`` argument in hook
>   implementations.  Use the ``hookwrapper`` mechanism instead already
>   introduced with pytest-2.7.
> 
> - speed up pytest's own test suite considerably by using inprocess
>   tests by default (testrun can be modified with --runpytest=subprocess
>   to create subprocesses in many places instead).  The main
>   APIs to run pytest in a test is "runpytest()" or "runpytest_subprocess"
>   and "runpytest_inprocess" if you need a particular way of running
>   the test.  In all cases you get back a RunResult but the inprocess
>   one will also have a "reprec" attribute with the recorded events/reports.
> 
> - fix monkeypatch.setattr("x.y", raising=False) to actually not raise
>   if "y" is not a pre-existing attribute. Thanks Florian Bruhin.
> 
> - fix issue741: make running output from testdir.run copy/pasteable
>   Thanks Bruno Oliveira.
> 
> - add a new ``--noconftest`` argument which ignores all ``conftest.py``
> files.
> 
> - add ``file`` and ``line`` attributes to JUnit-XML output.
> 
> - fix issue890: changed extension of all documentation files from ``txt`` to
>   ``rst``. Thanks to Abhijeet for the PR.
> 
> - fix issue714: add ability to apply indirect=True parameter on particular
> argnames.
>   Thanks Elizaveta239.
> 
> - fix issue714: add ability to apply indirect=True parameter on particular
> argnames.
> 
> - fix issue890: changed extension of all documentation files from ``txt`` to
>   ``rst``. Thanks to Abhijeet for the PR.
> 
> - fix issue957: "# doctest: SKIP" option will now register doctests as
> SKIPPED
>   rather than PASSED.
>   Thanks Thomas Grainger for the report and Bruno Oliveira for the PR.
> 
> - issue951: add new record_xml_property fixture, that supports logging
>   additional information on xml output. Thanks David Diaz for the PR.
> 
> - issue949: paths after normal options (for example `-s`, `-v`, etc) are now
>   properly used to discover `rootdir` and `ini` files.
>   Thanks Peter Lauri for the report and Bruno Oliveira for the PR.

> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python


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

From nicoddemus at gmail.com  Sat Sep 19 18:37:47 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Sat, 19 Sep 2015 16:37:47 +0000
Subject: [pytest-dev] [TIP] pytest 2.8
In-Reply-To: <20150919073458.GM26059@merlinux.eu>
References: <CA+RQFfd_kT0sdKL9F7WytVXGuGNOMNREcjfJDwiMWNdkN99+nQ@mail.gmail.com>
 <20150919073458.GM26059@merlinux.eu>
Message-ID: <CA+RQFfeOXsqxr3t1VjJfooG=cYEpVYugMT3p2mrAj70G+PNYqw@mail.gmail.com>

Hi Holger,

On Sat, Sep 19, 2015 at 4:34 AM holger krekel <holger at merlinux.eu> wrote:

> Was wondering -- did you conciously choose to not re-create and install
> docs before releasing?
>

I did forget that, sorry about it!


> FWIW I just regen'ed docs and pointed pytest.org/latest to 2.8 (it
> previously
> had "latest" point to 2.7).  The regen did not run fully to the end
> so some examples have not been regenerated yet but it's better than having
> a fully outdated doc version i think.  Maybe ronny could take a look why
> "tox -e regen" chokes?
>

I have the same results here on Windows, FWIW.

Cheers,
Bruno.

On Fri, Sep 18, 2015 at 22:09 +0000, Bruno Oliveira wrote:
> > Hi all,
> >
> > pytest 2.8 has been released to pypi, with significant bug-fixes and
> > features.
> >
> > In case you wonder, pytest is a widely used mature test runner both for
> > unit and functional test purposes in python.  See http://pytest.org for
> > documentation and examples.
> >
> > Here's the changelog for this version:
> >
> > - new ``--lf`` and ``-ff`` options to run only the last failing tests or
> >   "failing tests first" from the last run.  This functionality is
> provided
> >   through porting the formerly external pytest-cache plugin into pytest
> > core.
> >   BACKWARD INCOMPAT: if you used pytest-cache's functionality to persist
> >   data between test runs be aware that we don't serialize sets anymore.
> >   Thanks Ronny Pfannschmidt for most of the merging work.
> >
> > - "-r" option now accepts "a" to include all possible reports, similar
> >   to passing "fEsxXw" explicitly (isse960).
> >   Thanks Abhijeet Kasurde for the PR.
> >
> > - avoid python3.5 deprecation warnings by introducing version
> >   specific inspection helpers, thanks Michael Droettboom.
> >
> > - fix issue562: @nose.tools.istest now fully respected.
> >
> > - fix issue934: when string comparison fails and a diff is too large to
> > display
> >   without passing -vv, still show a few lines of the diff.
> >   Thanks Florian Bruhin for the report and Bruno Oliveira for the PR.
> >
> > - fix issue736: Fix a bug where fixture params would be discarded when
> > combined
> >   with parametrization markers.
> >   Thanks to Markus Unterwaditzer for the PR.
> >
> > - fix issue710: introduce ALLOW_UNICODE doctest option: when enabled, the
> >   ``u`` prefix is stripped from unicode strings in expected doctest
> output.
> > This
> >   allows doctests which use unicode to run in Python 2 and 3 unchanged.
> >   Thanks Jason R. Coombs for the report and Bruno Oliveira for the PR.
> >
> > - parametrize now also generates meaningful test IDs for enum, regex and
> > class
> >   objects (as opposed to class instances).
> >   Thanks to Florian Bruhin for the PR.
> >
> > - Add 'warns' to assert that warnings are thrown (like 'raises').
> >   Thanks to Eric Hunsberger for the PR.
> >
> > - Fix issue683: Do not apply an already applied mark.  Thanks ojake for
> the
> > PR.
> >
> > - Deal with capturing failures better so fewer exceptions get lost to
> >   /dev/null.  Thanks David Szotten for the PR.
> >
> > - fix issue730: deprecate and warn about the --genscript option.
> >   Thanks Ronny Pfannschmidt for the report and Christian Pommranz for the
> > PR.
> >
> > - fix issue751: multiple parametrize with ids bug if it parametrizes
> class
> > with
> >   two or more test methods. Thanks Sergey Chipiga for reporting and Jan
> >   Bednarik for PR.
> >
> > - fix issue82: avoid loading conftest files from
> > setup.cfg/pytest.ini/tox.ini
> >   files and upwards by default (--confcutdir can still be set to override
> > this).
> >   Thanks Bruno Oliveira for the PR.
> >
> > - fix issue768: docstrings found in python modules were not setting up
> > session
> >   fixtures. Thanks Jason R. Coombs for reporting and Bruno Oliveira for
> the
> > PR.
> >
> > - added `tmpdir_factory`, a session-scoped fixture that can be used to
> > create
> >   directories under the base temporary directory. Previously this object
> was
> >   installed as a `_tmpdirhandler` attribute of the `config` object, but
> now
> > it
> >   is part of the official API and using `config._tmpdirhandler` is
> >   deprecated.
> >   Thanks Bruno Oliveira for the PR.
> >
> > - fix issue808: pytest's internal assertion rewrite hook now implements
> the
> >   optional PEP302 get_data API so tests can access data files next to
> them.
> >   Thanks xmo-odoo for request and example and Bruno Oliveira for
> >   the PR.
> >
> > - rootdir and inifile are now displayed during usage errors to help
> >   users diagnose problems such as unexpected ini files which add
> >   unknown options being picked up by pytest. Thanks to Pavel Savchenko
> for
> >   bringing the problem to attention in #821 and Bruno Oliveira for the
> PR.
> >
> > - Summary bar now is colored yellow for warning
> >   situations such as: all tests either were skipped or xpass/xfailed,
> >   or no tests were run at all (this is a partial fix for issue500).
> >
> > - fix issue812: pytest now exits with status code 5 in situations where
> no
> >   tests were run at all, such as the directory given in the command line
> > does
> >   not contain any tests or as result of a command line option filters
> >   all out all tests (-k for example).
> >   Thanks Eric Siegerman (issue812) and Bruno Oliveira for the PR.
> >
> > - Summary bar now is colored yellow for warning
> >   situations such as: all tests either were skipped or xpass/xfailed,
> >   or no tests were run at all (related to issue500).
> >   Thanks Eric Siegerman.
> >
> > - New `testpaths` ini option: list of directories to search for tests
> >   when executing pytest from the root directory. This can be used
> >   to speed up test collection when a project has well specified
> directories
> >   for tests, being usually more practical than configuring norecursedirs
> for
> >   all directories that do not contain tests.
> >   Thanks to Adrian for idea (#694) and Bruno Oliveira for the PR.
> >
> > - fix issue713: JUnit XML reports for doctest failures.
> >   Thanks Punyashloka Biswal.
> >
> > - fix issue970: internal pytest warnings now appear as "pytest-warnings"
> in
> >   the terminal instead of "warnings", so it is clear for users that those
> >   warnings are from pytest and not from the builtin "warnings" module.
> >   Thanks Bruno Oliveira.
> >
> > - Include setup and teardown in junitxml test durations.
> >   Thanks Janne Vanhala.
> >
> > - fix issue735: assertion failures on debug versions of Python 3.4+
> >
> > - new option ``--import-mode`` to allow to change test module importing
> >   behaviour to append to sys.path instead of prepending.  This better
> > allows
> >   to run test modules against installated versions of a package even if
> the
> >   package under test has the same import root.  In this example::
> >
> >         testing/__init__.py
> >         testing/test_pkg_under_test.py
> >         pkg_under_test/
> >
> >   the tests will run against the installed version
> >   of pkg_under_test when ``--import-mode=append`` is used whereas
> >   by default they would always pick up the local version.  Thanks Holger
> > Krekel.
> >
> > - pytester: add method ``TmpTestdir.delete_loaded_modules()``, and call
> it
> >   from ``inline_run()`` to allow temporary modules to be reloaded.
> >   Thanks Eduardo Schettino.
> >
> > - internally refactor pluginmanager API and code so that there
> >   is a clear distinction between a pytest-agnostic rather simple
> >   pluginmanager and the PytestPluginManager which adds a lot of
> >   behaviour, among it handling of the local conftest files.
> >   In terms of documented methods this is a backward compatible
> >   change but it might still break 3rd party plugins which relied on
> >   details like especially the pluginmanager.add_shutdown() API.
> >   Thanks Holger Krekel.
> >
> > - pluginmanagement: introduce ``pytest.hookimpl`` and
> >   ``pytest.hookspec`` decorators for setting impl/spec
> >   specific parameters.  This substitutes the previous
> >   now deprecated use of ``pytest.mark`` which is meant to
> >   contain markers for test functions only.
> >
> > - write/refine docs for "writing plugins" which now have their
> >   own page and are separate from the "using/installing plugins`` page.
> >
> > - fix issue732: properly unregister plugins from any hook calling
> >   sites allowing to have temporary plugins during test execution.
> >
> > - deprecate and warn about ``__multicall__`` argument in hook
> >   implementations.  Use the ``hookwrapper`` mechanism instead already
> >   introduced with pytest-2.7.
> >
> > - speed up pytest's own test suite considerably by using inprocess
> >   tests by default (testrun can be modified with --runpytest=subprocess
> >   to create subprocesses in many places instead).  The main
> >   APIs to run pytest in a test is "runpytest()" or "runpytest_subprocess"
> >   and "runpytest_inprocess" if you need a particular way of running
> >   the test.  In all cases you get back a RunResult but the inprocess
> >   one will also have a "reprec" attribute with the recorded
> events/reports.
> >
> > - fix monkeypatch.setattr("x.y", raising=False) to actually not raise
> >   if "y" is not a pre-existing attribute. Thanks Florian Bruhin.
> >
> > - fix issue741: make running output from testdir.run copy/pasteable
> >   Thanks Bruno Oliveira.
> >
> > - add a new ``--noconftest`` argument which ignores all ``conftest.py``
> > files.
> >
> > - add ``file`` and ``line`` attributes to JUnit-XML output.
> >
> > - fix issue890: changed extension of all documentation files from
> ``txt`` to
> >   ``rst``. Thanks to Abhijeet for the PR.
> >
> > - fix issue714: add ability to apply indirect=True parameter on
> particular
> > argnames.
> >   Thanks Elizaveta239.
> >
> > - fix issue714: add ability to apply indirect=True parameter on
> particular
> > argnames.
> >
> > - fix issue890: changed extension of all documentation files from
> ``txt`` to
> >   ``rst``. Thanks to Abhijeet for the PR.
> >
> > - fix issue957: "# doctest: SKIP" option will now register doctests as
> > SKIPPED
> >   rather than PASSED.
> >   Thanks Thomas Grainger for the report and Bruno Oliveira for the PR.
> >
> > - issue951: add new record_xml_property fixture, that supports logging
> >   additional information on xml output. Thanks David Diaz for the PR.
> >
> > - issue949: paths after normal options (for example `-s`, `-v`, etc) are
> now
> >   properly used to discover `rootdir` and `ini` files.
> >   Thanks Peter Lauri for the report and Bruno Oliveira for the PR.
>
> > _______________________________________________
> > testing-in-python mailing list
> > testing-in-python at lists.idyll.org
> > http://lists.idyll.org/listinfo/testing-in-python
>
>
> --
> about me:    http://holgerkrekel.net/about-me/
> contracting: http://merlinux.eu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150919/352e33bd/attachment-0001.html>

From holger at merlinux.eu  Mon Sep 21 14:10:31 2015
From: holger at merlinux.eu (holger krekel)
Date: Mon, 21 Sep 2015 12:10:31 +0000
Subject: [pytest-dev] pytest-2.8 / new branches
Message-ID: <20150921121031.GS26059@merlinux.eu>

Hey all,

just changed CONTRIBUTING to reflect the pytest-2.8 reality:

    https://github.com/pytest-dev/pytest/pull/1038

In it i suggest we use a "2.8.X" branch for bugfixes of the 2.8 series
and master for features.  We could also think about using "bug" and "feature"
as branch names to relieve us from changing version numbers and to be more
obvious to people at the command line.

After that PR above is merged (or updated to the suggested alternative)
we should actually create the branches and update version numbers accordingly.

Also i noted that the 2.8.0 tag is missing unless i am missing something -- 
Bruno, did you actually follow HOWTORELEASE.rst as a checklist? :)

cheers,
holger


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

From nicoddemus at gmail.com  Mon Sep 21 14:24:03 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Mon, 21 Sep 2015 12:24:03 +0000
Subject: [pytest-dev] pytest-2.8 / new branches
In-Reply-To: <20150921121031.GS26059@merlinux.eu>
References: <20150921121031.GS26059@merlinux.eu>
Message-ID: <CA+RQFfet9AxaTiP0tybuPPiQSg9CvVfnJp_v3XG9GJpoM40U=Q@mail.gmail.com>

On Mon, Sep 21, 2015 at 9:10 AM holger krekel <holger at merlinux.eu> wrote:

> Hey all,
>
> just changed CONTRIBUTING to reflect the pytest-2.8 reality:
>
>     https://github.com/pytest-dev/pytest/pull/1038
>
> In it i suggest we use a "2.8.X" branch for bugfixes of the 2.8 series
> and master for features.  We could also think about using "bug" and
> "feature"
> as branch names to relieve us from changing version numbers and to be more
> obvious to people at the command line.
>

I like using names unrelated to the version. But what about master?


> After that PR above is merged (or updated to the suggested alternative)
> we should actually create the branches and update version numbers
> accordingly.
>
> Also i noted that the 2.8.0 tag is missing unless i am missing something --
> Bruno, did you actually follow HOWTORELEASE.rst as a checklist? :)
>

I did, but somehow skipped updating the docs, and pushed the tag to my own
fork instead to upstream. ?? Sorry, it won't happen again! :)

Cheers,
Bruno.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150921/9f8c7e56/attachment.html>

From holger at merlinux.eu  Mon Sep 21 14:40:13 2015
From: holger at merlinux.eu (holger krekel)
Date: Mon, 21 Sep 2015 12:40:13 +0000
Subject: [pytest-dev] pytest-2.8 / new branches
In-Reply-To: <CA+RQFfet9AxaTiP0tybuPPiQSg9CvVfnJp_v3XG9GJpoM40U=Q@mail.gmail.com>
References: <20150921121031.GS26059@merlinux.eu>
 <CA+RQFfet9AxaTiP0tybuPPiQSg9CvVfnJp_v3XG9GJpoM40U=Q@mail.gmail.com>
Message-ID: <20150921124013.GT26059@merlinux.eu>

On Mon, Sep 21, 2015 at 12:24 +0000, Bruno Oliveira wrote:
> On Mon, Sep 21, 2015 at 9:10 AM holger krekel <holger at merlinux.eu> wrote:
> 
> > Hey all,
> >
> > just changed CONTRIBUTING to reflect the pytest-2.8 reality:
> >
> >     https://github.com/pytest-dev/pytest/pull/1038
> >
> > In it i suggest we use a "2.8.X" branch for bugfixes of the 2.8 series
> > and master for features.  We could also think about using "bug" and
> > "feature"
> > as branch names to relieve us from changing version numbers and to be more
> > obvious to people at the command line.
> >
> 
> I like using names unrelated to the version. But what about master?

I am one of those not-yet-git-diehards and therefore naively thought
we could go for "bug/feature" as branch names and forget about master.
Florian already noted that it would violate the expectation of "master"
being there.  

If we thus take "master" as a given we need to decide what it means --
if it means "bugfixes" then we could use "features" to distinguish.

So what about these branches:

- master: bugfixes (for current latest pytest release) which will
  usually be released in a new micro revision.

- features: will result in a new minor or major revision.
  
This satisfies these conditions:

- newcomers will likely submit bugfixes/typos to master and thus don't
  need to get re-routed (like happen in the pytest-2.7/master cycle often)

- we don't need to change branch names when we do a new minor/major release

- "features" conveys an implicit meaning for master ("bugfixes")

sounds good?

best,
holger


From nicoddemus at gmail.com  Mon Sep 21 14:44:29 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Mon, 21 Sep 2015 12:44:29 +0000
Subject: [pytest-dev] pytest-2.8 / new branches
In-Reply-To: <20150921124013.GT26059@merlinux.eu>
References: <20150921121031.GS26059@merlinux.eu>
 <CA+RQFfet9AxaTiP0tybuPPiQSg9CvVfnJp_v3XG9GJpoM40U=Q@mail.gmail.com>
 <20150921124013.GT26059@merlinux.eu>
Message-ID: <CA+RQFfeBuX2zddGeAq5bYQbG5WaJ8y=7=durMhDTbdoOe+EdsA@mail.gmail.com>

On Mon, Sep 21, 2015 at 9:40 AM holger krekel <holger at merlinux.eu> wrote:

> So what about these branches:
>
> - master: bugfixes (for current latest pytest release) which will
>   usually be released in a new micro revision.
>
> - features: will result in a new minor or major revision.
>
> This satisfies these conditions:
>
> - newcomers will likely submit bugfixes/typos to master and thus don't
>   need to get re-routed (like happen in the pytest-2.7/master cycle often)
>
> - we don't need to change branch names when we do a new minor/major release
>
> - "features" conveys an implicit meaning for master ("bugfixes")
>
sounds good?
>

sounds good to me!

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

From holger at merlinux.eu  Tue Sep 22 10:45:15 2015
From: holger at merlinux.eu (holger krekel)
Date: Tue, 22 Sep 2015 08:45:15 +0000
Subject: [pytest-dev] pytest-2.8 / new branches
In-Reply-To: <CA+RQFfeBuX2zddGeAq5bYQbG5WaJ8y=7=durMhDTbdoOe+EdsA@mail.gmail.com>
References: <20150921121031.GS26059@merlinux.eu>
 <CA+RQFfet9AxaTiP0tybuPPiQSg9CvVfnJp_v3XG9GJpoM40U=Q@mail.gmail.com>
 <20150921124013.GT26059@merlinux.eu>
 <CA+RQFfeBuX2zddGeAq5bYQbG5WaJ8y=7=durMhDTbdoOe+EdsA@mail.gmail.com>
Message-ID: <20150922084515.GU26059@merlinux.eu>

On Mon, Sep 21, 2015 at 12:44 +0000, Bruno Oliveira wrote:
> On Mon, Sep 21, 2015 at 9:40 AM holger krekel <holger at merlinux.eu> wrote:
> 
> > So what about these branches:
> >
> > - master: bugfixes (for current latest pytest release) which will
> >   usually be released in a new micro revision.
> >
> > - features: will result in a new minor or major revision.
> >
> > This satisfies these conditions:
> >
> > - newcomers will likely submit bugfixes/typos to master and thus don't
> >   need to get re-routed (like happen in the pytest-2.7/master cycle often)
> >
> > - we don't need to change branch names when we do a new minor/major release
> >
> > - "features" conveys an implicit meaning for master ("bugfixes")
> >
> sounds good?
> >
> 
> sounds good to me!

I've updated the PR accordingly:

    https://github.com/pytest-dev/pytest/pull/1038

and would like to have it merged it real soon so that other ongoing PRs can
be targetted correctly.

cheers,
holger

From edluzonjr at gmail.com  Tue Sep 22 21:27:06 2015
From: edluzonjr at gmail.com (Ernesto D. Luzon Jr.)
Date: Tue, 22 Sep 2015 20:27:06 +0100
Subject: [pytest-dev] (Help) How to replace __multicall__ with hookwrapper?
Message-ID: <CAEpTN6DN-vrKHhAq7oYkp9Wjyvhc7g4pV-WsV5hqa2yzwcYv3Q@mail.gmail.com>

Hi All,

I have code below that is based from the snippet provided by Holger:
http://stackoverflow.com/questions/10754970/in-which-py-test-callout-can-i-find-both-item-and-report-data

def pytest_runtest_makereport(item, call, __multicall__):
    rep = __multicall__.execute()
    setattr(item, "rep_" + rep.when, rep)
    return rep

Now, I'm struggling how to use hookwrapper instead of __multicall__.
I'd really appreciate if someone can help, thanks!

Many thanks,
Ernesto D. Luzon Jr.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150922/233d63f0/attachment.html>

From holger at merlinux.eu  Tue Sep 22 21:31:31 2015
From: holger at merlinux.eu (holger krekel)
Date: Tue, 22 Sep 2015 19:31:31 +0000
Subject: [pytest-dev] (Help) How to replace __multicall__ with
 hookwrapper?
In-Reply-To: <CAEpTN6DN-vrKHhAq7oYkp9Wjyvhc7g4pV-WsV5hqa2yzwcYv3Q@mail.gmail.com>
References: <CAEpTN6DN-vrKHhAq7oYkp9Wjyvhc7g4pV-WsV5hqa2yzwcYv3Q@mail.gmail.com>
Message-ID: <20150922193131.GW26059@merlinux.eu>

On Tue, Sep 22, 2015 at 20:27 +0100, Ernesto D. Luzon Jr. wrote:
> Hi All,
> 
> I have code below that is based from the snippet provided by Holger:
> http://stackoverflow.com/questions/10754970/in-which-py-test-callout-can-i-find-both-item-and-report-data
> 
> def pytest_runtest_makereport(item, call, __multicall__):
>     rep = __multicall__.execute()
>     setattr(item, "rep_" + rep.when, rep)
>     return rep
> 
> Now, I'm struggling how to use hookwrapper instead of __multicall__.
> I'd really appreciate if someone can help, thanks!

did you look at:

https://pytest.org/latest/writing_plugins.html#hookwrapper-executing-around-other-hooks

?

Your above code should look like this:

    @pytest.hookwrapper
    def pytest_runtest_makereport(item, call):
         outcome = yield
         rep = outcome.get_result()
         setattr(item, "rep_" + rep.when, rep)
         return rep

best,
holger


> Many thanks,
> Ernesto D. Luzon Jr.

> _______________________________________________
> 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 holger at merlinux.eu  Tue Sep 22 21:44:07 2015
From: holger at merlinux.eu (holger krekel)
Date: Tue, 22 Sep 2015 19:44:07 +0000
Subject: [pytest-dev] (Help) How to replace __multicall__ with
 hookwrapper?
In-Reply-To: <20150922193131.GW26059@merlinux.eu>
References: <CAEpTN6DN-vrKHhAq7oYkp9Wjyvhc7g4pV-WsV5hqa2yzwcYv3Q@mail.gmail.com>
 <20150922193131.GW26059@merlinux.eu>
Message-ID: <20150922194407.GX26059@merlinux.eu>

On Tue, Sep 22, 2015 at 19:31 +0000, holger krekel wrote:
> On Tue, Sep 22, 2015 at 20:27 +0100, Ernesto D. Luzon Jr. wrote:
> > Hi All,
> > 
> > I have code below that is based from the snippet provided by Holger:
> > http://stackoverflow.com/questions/10754970/in-which-py-test-callout-can-i-find-both-item-and-report-data
> > 
> > def pytest_runtest_makereport(item, call, __multicall__):
> >     rep = __multicall__.execute()
> >     setattr(item, "rep_" + rep.when, rep)
> >     return rep
> > 
> > Now, I'm struggling how to use hookwrapper instead of __multicall__.
> > I'd really appreciate if someone can help, thanks!
> 
> did you look at:
> 
> https://pytest.org/latest/writing_plugins.html#hookwrapper-executing-around-other-hooks
> 
> ?
> 
> Your above code should look like this:
> 
>     @pytest.hookwrapper

This should rather read @pytest.hookimpl(hookwrapper=True) like stated in
the documentation.

holger

>     def pytest_runtest_makereport(item, call):
>          outcome = yield
>          rep = outcome.get_result()
>          setattr(item, "rep_" + rep.when, rep)
>          return rep
> 
> best,
> holger
> 
> 
> > Many thanks,
> > Ernesto D. Luzon Jr.
> 
> > _______________________________________________
> > 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
> 

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

From edluzonjr at gmail.com  Wed Sep 23 16:21:56 2015
From: edluzonjr at gmail.com (Ernesto D. Luzon Jr.)
Date: Wed, 23 Sep 2015 15:21:56 +0100
Subject: [pytest-dev] (Help) How to replace __multicall__ with
	hookwrapper?
Message-ID: <CAEpTN6DGfi6oocwbcgZ0sRjc4kqZ_43aBJSKTwtZJzh-S7tXXg@mail.gmail.com>

Hi Holger,

Thanks a lot!
That worked. Now I am no longer getting 'deprecated __multicall__' warnings
from pytest 2.8.

Many thanks,
Ernesto D. Luzon Jr.

On Wed, Sep 23, 2015 at 11:00 AM, <pytest-dev-request at python.org> wrote:

> Send pytest-dev mailing list submissions to
>         pytest-dev at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.python.org/mailman/listinfo/pytest-dev
> or, via email, send a message with subject or body 'help' to
>         pytest-dev-request at python.org
>
> You can reach the person managing the list at
>         pytest-dev-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of pytest-dev digest..."
>
>
> Today's Topics:
>
>    1. (Help) How to replace __multicall__ with hookwrapper?
>       (Ernesto D. Luzon Jr.)
>    2. Re: (Help) How to replace __multicall__ with hookwrapper?
>       (holger krekel)
>    3. Re: (Help) How to replace __multicall__ with hookwrapper?
>       (holger krekel)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 22 Sep 2015 20:27:06 +0100
> From: "Ernesto D. Luzon Jr." <edluzonjr at gmail.com>
> To: pytest-dev at python.org
> Subject: [pytest-dev] (Help) How to replace __multicall__ with
>         hookwrapper?
> Message-ID:
>         <
> CAEpTN6DN-vrKHhAq7oYkp9Wjyvhc7g4pV-WsV5hqa2yzwcYv3Q at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi All,
>
> I have code below that is based from the snippet provided by Holger:
>
> http://stackoverflow.com/questions/10754970/in-which-py-test-callout-can-i-find-both-item-and-report-data
>
> def pytest_runtest_makereport(item, call, __multicall__):
>     rep = __multicall__.execute()
>     setattr(item, "rep_" + rep.when, rep)
>     return rep
>
> Now, I'm struggling how to use hookwrapper instead of __multicall__.
> I'd really appreciate if someone can help, thanks!
>
> Many thanks,
> Ernesto D. Luzon Jr.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.python.org/pipermail/pytest-dev/attachments/20150922/233d63f0/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 22 Sep 2015 19:31:31 +0000
> From: holger krekel <holger at merlinux.eu>
> To: "Ernesto D. Luzon Jr." <edluzonjr at gmail.com>
> Cc: pytest-dev at python.org
> Subject: Re: [pytest-dev] (Help) How to replace __multicall__ with
>         hookwrapper?
> Message-ID: <20150922193131.GW26059 at merlinux.eu>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Sep 22, 2015 at 20:27 +0100, Ernesto D. Luzon Jr. wrote:
> > Hi All,
> >
> > I have code below that is based from the snippet provided by Holger:
> >
> http://stackoverflow.com/questions/10754970/in-which-py-test-callout-can-i-find-both-item-and-report-data
> >
> > def pytest_runtest_makereport(item, call, __multicall__):
> >     rep = __multicall__.execute()
> >     setattr(item, "rep_" + rep.when, rep)
> >     return rep
> >
> > Now, I'm struggling how to use hookwrapper instead of __multicall__.
> > I'd really appreciate if someone can help, thanks!
>
> did you look at:
>
>
> https://pytest.org/latest/writing_plugins.html#hookwrapper-executing-around-other-hooks
>
> ?
>
> Your above code should look like this:
>
>     @pytest.hookwrapper
>     def pytest_runtest_makereport(item, call):
>          outcome = yield
>          rep = outcome.get_result()
>          setattr(item, "rep_" + rep.when, rep)
>          return rep
>
> best,
> holger
>
>
> > Many thanks,
> > Ernesto D. Luzon Jr.
>
> > _______________________________________________
> > 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
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 22 Sep 2015 19:44:07 +0000
> From: holger krekel <holger at merlinux.eu>
> To: holger krekel <holger at merlinux.eu>, "Ernesto D. Luzon Jr."
>         <edluzonjr at gmail.com>, pytest-dev at python.org
> Subject: Re: [pytest-dev] (Help) How to replace __multicall__ with
>         hookwrapper?
> Message-ID: <20150922194407.GX26059 at merlinux.eu>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Sep 22, 2015 at 19:31 +0000, holger krekel wrote:
> > On Tue, Sep 22, 2015 at 20:27 +0100, Ernesto D. Luzon Jr. wrote:
> > > Hi All,
> > >
> > > I have code below that is based from the snippet provided by Holger:
> > >
> http://stackoverflow.com/questions/10754970/in-which-py-test-callout-can-i-find-both-item-and-report-data
> > >
> > > def pytest_runtest_makereport(item, call, __multicall__):
> > >     rep = __multicall__.execute()
> > >     setattr(item, "rep_" + rep.when, rep)
> > >     return rep
> > >
> > > Now, I'm struggling how to use hookwrapper instead of __multicall__.
> > > I'd really appreciate if someone can help, thanks!
> >
> > did you look at:
> >
> >
> https://pytest.org/latest/writing_plugins.html#hookwrapper-executing-around-other-hooks
> >
> > ?
> >
> > Your above code should look like this:
> >
> >     @pytest.hookwrapper
>
> This should rather read @pytest.hookimpl(hookwrapper=True) like stated in
> the documentation.
>
> holger
>
> >     def pytest_runtest_makereport(item, call):
> >          outcome = yield
> >          rep = outcome.get_result()
> >          setattr(item, "rep_" + rep.when, rep)
> >          return rep
> >
> > best,
> > holger
> >
> >
> > > Many thanks,
> > > Ernesto D. Luzon Jr.
> >
> > > _______________________________________________
> > > 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
> >
>
> --
> about me:    http://holgerkrekel.net/about-me/
> contracting: http://merlinux.eu
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>
> ------------------------------
>
> End of pytest-dev Digest, Vol 34, Issue 16
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150923/3269919e/attachment.html>

From holger at merlinux.eu  Fri Sep 25 11:43:16 2015
From: holger at merlinux.eu (holger krekel)
Date: Fri, 25 Sep 2015 09:43:16 +0000
Subject: [pytest-dev] pytest-capturelog status/merging to core?
Message-ID: <20150925094316.GB26059@merlinux.eu>

Hi all,

pytest-capturelog has been abandoned [1] but is still getting used a lot
as far as i see.  As it basically helps dealing with capturing logging 
and logging is part of the python standard lib i think we could see
to merge it into pytest and maintain it from there.  Is anyone up
for trying to do this along the lines of pytest-cache? 

FWIW I expect less breakage with pytest-capturelog because there is
no change like there was with the execnet->json move while merging.
It should be a relatively straightforward task.

Alternatively we could see to get maintainership from pypi admins
but i think in this case it's not worth it.

best,
hogler


[1] I and others tried to contact the author several times to no avail.


From holger at merlinux.eu  Fri Sep 25 13:02:16 2015
From: holger at merlinux.eu (holger krekel)
Date: Fri, 25 Sep 2015 11:02:16 +0000
Subject: [pytest-dev] pytest-capturelog status/merging to core?
In-Reply-To: <35A3A631-F757-4E19-AF4D-0CC60706034E@ronnypfannschmidt.de>
References: <20150925094316.GB26059@merlinux.eu>
 <35A3A631-F757-4E19-AF4D-0CC60706034E@ronnypfannschmidt.de>
Message-ID: <20150925110216.GC26059@merlinux.eu>

On Fri, Sep 25, 2015 at 12:24 +0200, Ronny Pfannschmidt wrote:
> Before we can merge it we need to restructure capturing, since logcapture currently incurs a huge perf cost (at least it did the last time we tried to merge it)

can't remember but ok :)  On a cursory look it seems that capturelog
creates and configures a LogHandler for each test.  We can isntead probably 
just create one log handler per session and snapshot relevant loglines per
test.  Also we probably want to add an option 
"--log-capture=yes" (default no or "auto").  Lastly, i think we should
consider merging capturelog into the core capture.py plugin as it's very
related.  Maybe I can give a PR a try next week.

In any case, pytest-2.9 is not going to be out soon so we'd have some
time to play with and settle mechanics.

holger

> Am 25. September 2015 11:43:16 MESZ, schrieb holger krekel <holger at merlinux.eu>:
> >Hi all,
> >
> >pytest-capturelog has been abandoned [1] but is still getting used a
> >lot
> >as far as i see.  As it basically helps dealing with capturing logging 
> >and logging is part of the python standard lib i think we could see
> >to merge it into pytest and maintain it from there.  Is anyone up
> >for trying to do this along the lines of pytest-cache? 
> >
> >FWIW I expect less breakage with pytest-capturelog because there is
> >no change like there was with the execnet->json move while merging.
> >It should be a relatively straightforward task.
> >
> >Alternatively we could see to get maintainership from pypi admins
> >but i think in this case it's not worth it.
> >
> >best,
> >hogler
> >
> >
> >[1] I and others tried to contact the author several times to no avail.
> >
> >_______________________________________________
> >pytest-dev mailing list
> >pytest-dev at python.org
> >https://mail.python.org/mailman/listinfo/pytest-dev
> 
> MFG Ronny
> 

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

From nicoddemus at gmail.com  Fri Sep 25 13:29:45 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Fri, 25 Sep 2015 11:29:45 +0000
Subject: [pytest-dev] pytest-capturelog status/merging to core?
In-Reply-To: <20150925094316.GB26059@merlinux.eu>
References: <20150925094316.GB26059@merlinux.eu>
Message-ID: <CA+RQFffJ-zPsoMW900SULWJGKWqCJGWB1cavL283pPV-EVLL5g@mail.gmail.com>

On Fri, Sep 25, 2015 at 6:43 AM holger krekel <holger at merlinux.eu> wrote:

> pytest-capturelog has been abandoned [1] but is still getting used a lot
> as far as i see.


Worth mentioning that there is a fork which is currently maintained,
pytest-catchlog [1].

If we are merging log capturing functionality, I think it would be nice to
consider this library too, as well as involve the author.

[1] https://pypi.python.org/pypi/pytest-catchlog

Cheers,
Bruno.

As it basically helps dealing with capturing logging
> and logging is part of the python standard lib i think we could see
> to merge it into pytest and maintain it from there.  Is anyone up
> for trying to do this along the lines of pytest-cache?
>
> FWIW I expect less breakage with pytest-capturelog because there is
> no change like there was with the execnet->json move while merging.
> It should be a relatively straightforward task.
>
> Alternatively we could see to get maintainership from pypi admins
> but i think in this case it's not worth it.
>
> best,
> hogler
>
>
> [1] I and others tried to contact the author several times to no avail.
>
> _______________________________________________
> 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/20150925/e6cc21fb/attachment.html>

From holger at merlinux.eu  Fri Sep 25 13:40:47 2015
From: holger at merlinux.eu (holger krekel)
Date: Fri, 25 Sep 2015 11:40:47 +0000
Subject: [pytest-dev] pytest-capturelog status/merging to core?
In-Reply-To: <CA+RQFffJ-zPsoMW900SULWJGKWqCJGWB1cavL283pPV-EVLL5g@mail.gmail.com>
References: <20150925094316.GB26059@merlinux.eu>
 <CA+RQFffJ-zPsoMW900SULWJGKWqCJGWB1cavL283pPV-EVLL5g@mail.gmail.com>
Message-ID: <20150925114046.GD26059@merlinux.eu>

On Fri, Sep 25, 2015 at 11:29 +0000, Bruno Oliveira wrote:
> On Fri, Sep 25, 2015 at 6:43 AM holger krekel <holger at merlinux.eu> wrote:
> 
> > pytest-capturelog has been abandoned [1] but is still getting used a lot
> > as far as i see.
> 
> 
> Worth mentioning that there is a fork which is currently maintained,
> pytest-catchlog [1].
> 
> If we are merging log capturing functionality, I think it would be nice to
> consider this library too, as well as involve the author.
> 
> [1] https://pypi.python.org/pypi/pytest-catchlog

definitely. I just created https://github.com/eisensheng/pytest-catchlog/issues/8 to ask the author for participation here.

thanks for the pointer.
cheers,
holger

> Cheers,
> Bruno.
> 
> As it basically helps dealing with capturing logging
> > and logging is part of the python standard lib i think we could see
> > to merge it into pytest and maintain it from there.  Is anyone up
> > for trying to do this along the lines of pytest-cache?
> >
> > FWIW I expect less breakage with pytest-capturelog because there is
> > no change like there was with the execnet->json move while merging.
> > It should be a relatively straightforward task.
> >
> > Alternatively we could see to get maintainership from pypi admins
> > but i think in this case it's not worth it.
> >
> > best,
> > hogler
> >
> >
> > [1] I and others tried to contact the author several times to no avail.
> >
> > _______________________________________________
> > 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 me at the-compiler.org  Fri Sep 25 14:03:12 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Fri, 25 Sep 2015 14:03:12 +0200
Subject: [pytest-dev] pytest-capturelog status/merging to core?
In-Reply-To: <20150925114046.GD26059@merlinux.eu>
References: <20150925094316.GB26059@merlinux.eu>
 <CA+RQFffJ-zPsoMW900SULWJGKWqCJGWB1cavL283pPV-EVLL5g@mail.gmail.com>
 <20150925114046.GD26059@merlinux.eu>
Message-ID: <20150925120312.GB1393@tonks>

* holger krekel <holger at merlinux.eu> [2015-09-25 11:40:47 +0000]:
> On Fri, Sep 25, 2015 at 11:29 +0000, Bruno Oliveira wrote:
> > On Fri, Sep 25, 2015 at 6:43 AM holger krekel <holger at merlinux.eu> wrote:
> > 
> > > pytest-capturelog has been abandoned [1] but is still getting used a lot
> > > as far as i see.
> > 
> > 
> > Worth mentioning that there is a fork which is currently maintained,
> > pytest-catchlog [1].
> > 
> > If we are merging log capturing functionality, I think it would be nice to
> > consider this library too, as well as involve the author.
> > 
> > [1] https://pypi.python.org/pypi/pytest-catchlog
> 
> definitely. I just created https://github.com/eisensheng/pytest-catchlog/issues/8 to ask the author for participation here.

I replied to the issue - there's an outstanding big PR (#7), and after
that's merged, I planned to help eisensheng to move it to pytest-dev
;)

Unfortunately, the PR also changes the API (for good reasons...), but
I already answered there that there should be a compatibility layer.

As I said there, I'm actually not sure if it should be merged, or at
least not yet - it's finally starting to have some bugfixes and
features compared to capturelog, and I plan to contribute some more
stuff I need when I switched over (which will be when that PR is
merged). Having an independent plugin release cycle has its benefits,
after all...

FWIW, I never noticed any performance issues with both catch- and
capturelog.

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/20150925/d2f8943e/attachment.sig>

From nicoddemus at gmail.com  Fri Sep 25 14:16:20 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Fri, 25 Sep 2015 12:16:20 +0000
Subject: [pytest-dev] pytest-capturelog status/merging to core?
In-Reply-To: <20150925120312.GB1393@tonks>
References: <20150925094316.GB26059@merlinux.eu>
 <CA+RQFffJ-zPsoMW900SULWJGKWqCJGWB1cavL283pPV-EVLL5g@mail.gmail.com>
 <20150925114046.GD26059@merlinux.eu> <20150925120312.GB1393@tonks>
Message-ID: <CA+RQFfdP0CXUyy_1mTtLcJUHVQpHbM1LWjDhxqYOrhcXBvWf0w@mail.gmail.com>

On Fri, Sep 25, 2015 at 9:03 AM Florian Bruhin <me at the-compiler.org> wrote:

> As I said there, I'm actually not sure if it should be merged, or at
> least not yet - it's finally starting to have some bugfixes and
> features compared to capturelog, and I plan to contribute some more
> stuff I need when I switched over (which will be when that PR is
> merged). Having an independent plugin release cycle has its benefits,
> after all...
>

I agree. I think the main motivation for merging was that it was a widely
used plugin which was unfortunately not maintained anymore. Since this is
no longer the case, I also wonder if perhaps leaving it as a separate
plugin would be better. :)

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

From opensource at ronnypfannschmidt.de  Fri Sep 25 14:40:04 2015
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Fri, 25 Sep 2015 14:40:04 +0200
Subject: [pytest-dev] pytest-capturelog status/merging to core?
In-Reply-To: <CA+RQFfdP0CXUyy_1mTtLcJUHVQpHbM1LWjDhxqYOrhcXBvWf0w@mail.gmail.com>
References: <20150925094316.GB26059@merlinux.eu>
 <CA+RQFffJ-zPsoMW900SULWJGKWqCJGWB1cavL283pPV-EVLL5g@mail.gmail.com>
 <20150925114046.GD26059@merlinux.eu> <20150925120312.GB1393@tonks>
 <CA+RQFfdP0CXUyy_1mTtLcJUHVQpHbM1LWjDhxqYOrhcXBvWf0w@mail.gmail.com>
Message-ID: <43A394C1-E54E-4F0A-9B9F-75F2772FD96F@ronnypfannschmidt.de>

I think we should deal with logging in core, since its in the stdlib

Am 25. September 2015 14:16:20 MESZ, schrieb Bruno Oliveira <nicoddemus at gmail.com>:
>On Fri, Sep 25, 2015 at 9:03 AM Florian Bruhin <me at the-compiler.org>
>wrote:
>
>> As I said there, I'm actually not sure if it should be merged, or at
>> least not yet - it's finally starting to have some bugfixes and
>> features compared to capturelog, and I plan to contribute some more
>> stuff I need when I switched over (which will be when that PR is
>> merged). Having an independent plugin release cycle has its benefits,
>> after all...
>>
>
>I agree. I think the main motivation for merging was that it was a
>widely
>used plugin which was unfortunately not maintained anymore. Since this
>is
>no longer the case, I also wonder if perhaps leaving it as a separate
>plugin would be better. :)
>
>Cheers,
>Bruno.
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>pytest-dev mailing list
>pytest-dev at python.org
>https://mail.python.org/mailman/listinfo/pytest-dev

MFG Ronny

From holger at merlinux.eu  Fri Sep 25 19:55:26 2015
From: holger at merlinux.eu (holger krekel)
Date: Fri, 25 Sep 2015 17:55:26 +0000
Subject: [pytest-dev] pytest-capturelog status/merging to core?
In-Reply-To: <43A394C1-E54E-4F0A-9B9F-75F2772FD96F@ronnypfannschmidt.de>
References: <20150925094316.GB26059@merlinux.eu>
 <CA+RQFffJ-zPsoMW900SULWJGKWqCJGWB1cavL283pPV-EVLL5g@mail.gmail.com>
 <20150925114046.GD26059@merlinux.eu> <20150925120312.GB1393@tonks>
 <CA+RQFfdP0CXUyy_1mTtLcJUHVQpHbM1LWjDhxqYOrhcXBvWf0w@mail.gmail.com>
 <43A394C1-E54E-4F0A-9B9F-75F2772FD96F@ronnypfannschmidt.de>
Message-ID: <20150925175526.GE26059@merlinux.eu>

On Fri, Sep 25, 2015 at 14:40 +0200, Ronny Pfannschmidt wrote:
> I think we should deal with logging in core, since its in the stdlib

I am fine with both -- leaving pytest-catchlog as 3rd party or
integrating it into core.  FWIW pytest's release speed is not that bad
especially as we are automating it further and more people can do
the releasing.

FWIW i think "catchlog" is a somewhat bad name.  Why not just
"pytest-logging" and move it to pytest-dev?

holger

> Am 25. September 2015 14:16:20 MESZ, schrieb Bruno Oliveira <nicoddemus at gmail.com>:
> >On Fri, Sep 25, 2015 at 9:03 AM Florian Bruhin <me at the-compiler.org>
> >wrote:
> >
> >> As I said there, I'm actually not sure if it should be merged, or at
> >> least not yet - it's finally starting to have some bugfixes and
> >> features compared to capturelog, and I plan to contribute some more
> >> stuff I need when I switched over (which will be when that PR is
> >> merged). Having an independent plugin release cycle has its benefits,
> >> after all...
> >>
> >
> >I agree. I think the main motivation for merging was that it was a
> >widely
> >used plugin which was unfortunately not maintained anymore. Since this
> >is
> >no longer the case, I also wonder if perhaps leaving it as a separate
> >plugin would be better. :)
> >
> >Cheers,
> >Bruno.
> >
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >pytest-dev mailing list
> >pytest-dev at python.org
> >https://mail.python.org/mailman/listinfo/pytest-dev
> 
> MFG Ronny
> _______________________________________________
> 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 opensource at ronnypfannschmidt.de  Fri Sep 25 20:11:34 2015
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Fri, 25 Sep 2015 20:11:34 +0200
Subject: [pytest-dev] pytest-capturelog status/merging to core?
In-Reply-To: <20150925175526.GE26059@merlinux.eu>
References: <20150925094316.GB26059@merlinux.eu>
 <CA+RQFffJ-zPsoMW900SULWJGKWqCJGWB1cavL283pPV-EVLL5g@mail.gmail.com>
 <20150925114046.GD26059@merlinux.eu> <20150925120312.GB1393@tonks>
 <CA+RQFfdP0CXUyy_1mTtLcJUHVQpHbM1LWjDhxqYOrhcXBvWf0w@mail.gmail.com>
 <43A394C1-E54E-4F0A-9B9F-75F2772FD96F@ronnypfannschmidt.de>
 <20150925175526.GE26059@merlinux.eu>
Message-ID: <A7BB3652-2404-49DD-963D-8FCDAC294213@ronnypfannschmidt.de>

If we give it a new name no need for compatible apis :)

Am 25. September 2015 19:55:26 MESZ, schrieb holger krekel <holger at merlinux.eu>:
>On Fri, Sep 25, 2015 at 14:40 +0200, Ronny Pfannschmidt wrote:
>> I think we should deal with logging in core, since its in the stdlib
>
>I am fine with both -- leaving pytest-catchlog as 3rd party or
>integrating it into core.  FWIW pytest's release speed is not that bad
>especially as we are automating it further and more people can do
>the releasing.
>
>FWIW i think "catchlog" is a somewhat bad name.  Why not just
>"pytest-logging" and move it to pytest-dev?
>
>holger
>
>> Am 25. September 2015 14:16:20 MESZ, schrieb Bruno Oliveira
><nicoddemus at gmail.com>:
>> >On Fri, Sep 25, 2015 at 9:03 AM Florian Bruhin <me at the-compiler.org>
>> >wrote:
>> >
>> >> As I said there, I'm actually not sure if it should be merged, or
>at
>> >> least not yet - it's finally starting to have some bugfixes and
>> >> features compared to capturelog, and I plan to contribute some
>more
>> >> stuff I need when I switched over (which will be when that PR is
>> >> merged). Having an independent plugin release cycle has its
>benefits,
>> >> after all...
>> >>
>> >
>> >I agree. I think the main motivation for merging was that it was a
>> >widely
>> >used plugin which was unfortunately not maintained anymore. Since
>this
>> >is
>> >no longer the case, I also wonder if perhaps leaving it as a
>separate
>> >plugin would be better. :)
>> >
>> >Cheers,
>> >Bruno.
>> >
>> >
>>
>>------------------------------------------------------------------------
>> >
>> >_______________________________________________
>> >pytest-dev mailing list
>> >pytest-dev at python.org
>> >https://mail.python.org/mailman/listinfo/pytest-dev
>> 
>> MFG Ronny
>> _______________________________________________
>> 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

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150925/fb1d1d24/attachment.html>

From holger at merlinux.eu  Sat Sep 26 09:02:21 2015
From: holger at merlinux.eu (holger krekel)
Date: Sat, 26 Sep 2015 07:02:21 +0000
Subject: [pytest-dev] pytest-2.8.1 monday?
Message-ID: <20150926070221.GG26059@merlinux.eu>

Hey all,

i suggest we do a 2.8.1 release so that the fixes we already gathered
reach a wider audience.  Anyone wanting to do it?  Any last PRs you
want to do/see merged? Now is the time :)

holger

From nicoddemus at gmail.com  Sat Sep 26 17:12:38 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Sat, 26 Sep 2015 15:12:38 +0000
Subject: [pytest-dev] pytest-2.8.1 monday?
In-Reply-To: <20150926070221.GG26059@merlinux.eu>
References: <20150926070221.GG26059@merlinux.eu>
Message-ID: <CA+RQFffZ6OHmwJ06MKVMjzQgpruPtTARWYOpzrhgvuXZK3TAvQ@mail.gmail.com>

Hey,

I think we should focus in fixing regressions that caused people to pin
down pytest back to 2.7.3. Looking at the issues it seems we got all of
those.

Backward compatibility issues which would be nice to have on this release:

https://github.com/pytest-dev/pytest/issues/1037
https://github.com/pytest-dev/pytest/issues/1073

It would also be nice if we merged
https://github.com/pytest-dev/pytest/pull/1060, as it was contributed by an
enthusiastic user which demonstrated interest in seeing this out soon,
besides fixing some long standing xdist problems.

As a thought, it would be nice to use the filter for the 2.8.1 milestone
[1] to see the issues which we consider critical for the 2.8.1 release. I
guess that doesn't seem to reflect this currently.

[1] https://github.com/pytest-dev/pytest/milestones/2.8.1

Cheers,
Bruno.


On Sat, Sep 26, 2015 at 4:02 AM holger krekel <holger at merlinux.eu> wrote:

> Hey all,
>
> i suggest we do a 2.8.1 release so that the fixes we already gathered
> reach a wider audience.  Anyone wanting to do it?  Any last PRs you
> want to do/see merged? Now is the time :)
>
> 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/20150926/12885fc5/attachment.html>

From opensource at ronnypfannschmidt.de  Sat Sep 26 17:30:27 2015
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Sat, 26 Sep 2015 17:30:27 +0200
Subject: [pytest-dev] pytest-2.8.1 monday?
In-Reply-To: <CA+RQFffZ6OHmwJ06MKVMjzQgpruPtTARWYOpzrhgvuXZK3TAvQ@mail.gmail.com>
References: <20150926070221.GG26059@merlinux.eu>
 <CA+RQFffZ6OHmwJ06MKVMjzQgpruPtTARWYOpzrhgvuXZK3TAvQ@mail.gmail.com>
Message-ID: <EA7504E5-6065-4E8D-8B82-2475E79B0F4C@ronnypfannschmidt.de>

We should do some grooming of the milestones before the release then

Am 26. September 2015 17:12:38 MESZ, schrieb Bruno Oliveira <nicoddemus at gmail.com>:
>Hey,
>
>I think we should focus in fixing regressions that caused people to pin
>down pytest back to 2.7.3. Looking at the issues it seems we got all of
>those.
>
>Backward compatibility issues which would be nice to have on this
>release:
>
>https://github.com/pytest-dev/pytest/issues/1037
>https://github.com/pytest-dev/pytest/issues/1073
>
>It would also be nice if we merged
>https://github.com/pytest-dev/pytest/pull/1060, as it was contributed
>by an
>enthusiastic user which demonstrated interest in seeing this out soon,
>besides fixing some long standing xdist problems.
>
>As a thought, it would be nice to use the filter for the 2.8.1
>milestone
>[1] to see the issues which we consider critical for the 2.8.1 release.
>I
>guess that doesn't seem to reflect this currently.
>
>[1] https://github.com/pytest-dev/pytest/milestones/2.8.1
>
>Cheers,
>Bruno.
>
>
>On Sat, Sep 26, 2015 at 4:02 AM holger krekel <holger at merlinux.eu>
>wrote:
>
>> Hey all,
>>
>> i suggest we do a 2.8.1 release so that the fixes we already gathered
>> reach a wider audience.  Anyone wanting to do it?  Any last PRs you
>> want to do/see merged? Now is the time :)
>>
>> holger
>> _______________________________________________
>> pytest-dev mailing list
>> pytest-dev at python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>pytest-dev mailing list
>pytest-dev at python.org
>https://mail.python.org/mailman/listinfo/pytest-dev

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150926/2dbfd737/attachment.html>

From opensource at ronnypfannschmidt.de  Mon Sep 28 08:06:44 2015
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Mon, 28 Sep 2015 08:06:44 +0200
Subject: [pytest-dev] pytest 2.8.1 issue status and blockers
Message-ID: <5608D8F4.3090300@ronnypfannschmidt.de>

Hi everyone,

over the weekend i had some time to do grooming and attempted a few
fixes and did issue grooming

the 1.8.1 milestone is down to 4 open issues

https://github.com/pytest-dev/pytest/issues/1073
* a fix in pluggy is on the way thanks to Brono!

https://github.com/pytest-dev/pytest/pull/1060
* that pull request is currently not merge-able since it brings back
regressions we fixed pre-2.8, but the items it fixes are critical
  we def want that in

  Buck did a great job of discovering the cause and doing the fixes,
  unfortunately his refracting went too far and reintroduced an internal
issue

https://github.com/pytest-dev/pytest/issues/1037
* is a regression we def want to fix

https://github.com/pytest-dev/pytest/issues/1026
* is not critical but nice to have documentation, ideally fixed in union
with #1073


i consider #1060 is a release blocker, but it has a very high backward
break potential as is,
however i cant work on it myself this week,

we can either try to include it or should make a big note as a known
issue and try to do another patch release as soon as its ready

current time-frames look like we should mark it as known issue

-- Ronny


From holger at merlinux.eu  Mon Sep 28 12:15:27 2015
From: holger at merlinux.eu (holger krekel)
Date: Mon, 28 Sep 2015 10:15:27 +0000
Subject: [pytest-dev] maintaining a synced git fork easily?
Message-ID: <20150928101527.GJ26059@merlinux.eu>

Hey git-users :)

could someone help me with how to best manage my git fork of pytest?

I currently have two separate directories for my pytest work -- one
which was cloned from pytest-dev/pytest and one from hpk42/pytest which
was forked using the github UI.  Is it a good idea to try to maintain
both "remotes" in a single directory on my laptop?  I'd basically like
to be able to make a branch from pytest-dev/pytest but have it stored
in the hpk42/pytest fork repo.  And only have a single "git pull/fetch".

Instead currently i do this:

    cd pytest ; git pull
    cd ../pytest-hpk 
    git co master ; git pull ../pytest ; git push origin
    git co features ; git pull ../pytest ; git push origin

which seems a bit much -- also the last two "git co" commands usually
involve a merge commit which seems wrong (i probably messed up at some
point -- do i need to do a fresh fork/clone?).

How are you solving this usage issue?

holger

From eldar.abusalimov at gmail.com  Mon Sep 28 12:20:19 2015
From: eldar.abusalimov at gmail.com (Eldar Abusalimov)
Date: Mon, 28 Sep 2015 13:20:19 +0300
Subject: [pytest-dev] maintaining a synced git fork easily?
In-Reply-To: <20150928101527.GJ26059@merlinux.eu>
References: <20150928101527.GJ26059@merlinux.eu>
Message-ID: <CAA8Mjn_bnvLhdUJ7p=J-C1+NO8DmA7MT0W-dOeCrJr=g6BgYMg@mail.gmail.com>

Holger,

There was a good post in the GitHub blog about multiple worktrees and
triangular workflows
<https://github.com/blog/2042-git-2-5-including-multiple-worktrees-and-triangular-workflows>.
Hope that helps!

On Mon, Sep 28, 2015 at 1:15 PM, holger krekel <holger at merlinux.eu> wrote:

> Hey git-users :)
>
> could someone help me with how to best manage my git fork of pytest?
>
> I currently have two separate directories for my pytest work -- one
> which was cloned from pytest-dev/pytest and one from hpk42/pytest which
> was forked using the github UI.  Is it a good idea to try to maintain
> both "remotes" in a single directory on my laptop?  I'd basically like
> to be able to make a branch from pytest-dev/pytest but have it stored
> in the hpk42/pytest fork repo.  And only have a single "git pull/fetch".
>
> Instead currently i do this:
>
>     cd pytest ; git pull
>     cd ../pytest-hpk
>     git co master ; git pull ../pytest ; git push origin
>     git co features ; git pull ../pytest ; git push origin
>
> which seems a bit much -- also the last two "git co" commands usually
> involve a merge commit which seems wrong (i probably messed up at some
> point -- do i need to do a fresh fork/clone?).
>
> How are you solving this usage issue?
>
> holger
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>



-- 
Best regards,
Eldar Sh. Abusalimov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150928/a5cb8fae/attachment.html>

From me at the-compiler.org  Mon Sep 28 12:25:58 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Mon, 28 Sep 2015 12:25:58 +0200
Subject: [pytest-dev] maintaining a synced git fork easily?
In-Reply-To: <20150928101527.GJ26059@merlinux.eu>
References: <20150928101527.GJ26059@merlinux.eu>
Message-ID: <20150928102558.GK1393@tonks>

* holger krekel <holger at merlinux.eu> [2015-09-28 10:15:27 +0000]:
> How are you solving this usage issue?

I usually have the following workflow when I contribute to projects:

- Fork the upstream library on GitHub, so there's a
  The-Compiler/pytest

- Clone the forked repository. This will have an 'origin' remote (as
  the default remote) which is something like
  git at github.com:The-Compiler/pytest.git

- Add a new remote, 'upstream' with the original, upstream
  repository. I usually use the https URL so I notice if I somehow
  manage to push there accidentally (because there's a password
  prompt):

  $ git remote add upstream https://github.com/pytest-dev/pytest.git

- I always keep my master in sync with the upstream master, by doing
  something like this before working on a new feature (on the master
  branch);

  $ git pull upstream master
  $ git push origin master

  (s/master/features/ as appropriate)

- Create a branch locally, work, and push to fork:

  $ git checkout -b fix-1234
  $ git commit
  $ git push    # (creates the branch on origin, i.e. my fork)

- Commit and push on that branch as necessary to update the PR

- When the PR is merged (assuming to master), clean up the branches
  and update the local and forked master:

  $ git checkout master
  $ git pull upstream master
  $ git push origin master
  $ git branch -d fix-1234
  $ git push origin :fix-1234  # deletes remote branch

I hope that helps!

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/20150928/1de270ad/attachment.sig>

From nicoddemus at gmail.com  Mon Sep 28 13:15:17 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Mon, 28 Sep 2015 11:15:17 +0000
Subject: [pytest-dev] maintaining a synced git fork easily?
In-Reply-To: <20150928102558.GK1393@tonks>
References: <20150928101527.GJ26059@merlinux.eu> <20150928102558.GK1393@tonks>
Message-ID: <CA+RQFfdnCJLbky_4ppPoTuXUvZ8Vfnp+h6rvtqKCvn2V+Hb=Sw@mail.gmail.com>

On Mon, Sep 28, 2015 at 7:26 AM Florian Bruhin <me at the-compiler.org> wrote:

> I usually have the following workflow when I contribute to projects:
>

I have the exact workflow as Florian. :)

I would only add that you can create your branches based directly on the
upstream:

$ git checkout -b fix-1234 upstream/master
$ git push origin

Cheers,
Bruno.



> 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/20150928/d30074d6/attachment.html>

From holger at merlinux.eu  Mon Sep 28 13:33:07 2015
From: holger at merlinux.eu (holger krekel)
Date: Mon, 28 Sep 2015 11:33:07 +0000
Subject: [pytest-dev] maintaining a synced git fork easily?
In-Reply-To: <CA+RQFfdnCJLbky_4ppPoTuXUvZ8Vfnp+h6rvtqKCvn2V+Hb=Sw@mail.gmail.com>
References: <20150928101527.GJ26059@merlinux.eu> <20150928102558.GK1393@tonks>
 <CA+RQFfdnCJLbky_4ppPoTuXUvZ8Vfnp+h6rvtqKCvn2V+Hb=Sw@mail.gmail.com>
Message-ID: <20150928113307.GK26059@merlinux.eu>

On Mon, Sep 28, 2015 at 11:15 +0000, Bruno Oliveira wrote:
> On Mon, Sep 28, 2015 at 7:26 AM Florian Bruhin <me at the-compiler.org> wrote:
> 
> > I usually have the following workflow when I contribute to projects:
> >
> 
> I have the exact workflow as Florian. :)
> 
> I would only add that you can create your branches based directly on the
> upstream:
> 
> $ git checkout -b fix-1234 upstream/master
> $ git push origin

thanks.  The post Eldar referenced also advertises this workflow
but additionally sets some config options:

    $ git config remote.pushdefault origin
    $ git config push.default current

which means you can just say "git push" above.

I am trying out this work flow now.
thanks everybody :)
holger

From raphael at hackebrot.de  Mon Sep 28 14:56:20 2015
From: raphael at hackebrot.de (Raphael Pierzina)
Date: Mon, 28 Sep 2015 14:56:20 +0200
Subject: [pytest-dev] maintaining a synced git fork easily?
In-Reply-To: <20150928113307.GK26059@merlinux.eu>
References: <20150928101527.GJ26059@merlinux.eu> <20150928102558.GK1393@tonks>
 <CA+RQFfdnCJLbky_4ppPoTuXUvZ8Vfnp+h6rvtqKCvn2V+Hb=Sw@mail.gmail.com>
 <20150928113307.GK26059@merlinux.eu>
Message-ID: <DFAC27F3-51D0-4621-8D46-64747A631B19@hackebrot.de>

Hi!

I also follow the workflow that Florian and Bruno explained.

It pretty much resembles theses guides:
https://help.github.com/articles/configuring-a-remote-for-a-fork/ <https://help.github.com/articles/configuring-a-remote-for-a-fork/>
https://help.github.com/articles/syncing-a-fork/ <https://help.github.com/articles/syncing-a-fork/>

As to the ``push.default`` setting, I usually go with ``simple``. It is the default starting from Git version 2.0. I found the following SO answer helpful in addition to the official docs.
http://stackoverflow.com/a/13148313 <http://stackoverflow.com/a/13148313>

I always explicitly specify the remote repository for a ``fetch`` or ``push`` to not mess up accidentally. But this is totally up to your personal preference.

```bash
# Sync local repo and fork with original repo
$ git checkout master
$ git fetch upstream
$ git merge upstream/master
$ git push origin

# Create feature branch on master
$ git checkout -b add-awesome-feature
?

# Sync master again and rebase your local branch before pushing it
...
$ git rebase master
$ git push -u origin add-awesome-feature

# Submit a Pull Request. Sync master once the PR has been accepted
# I delete my remote feature branch via the GitHub UI and clean up branch my local branch afterwards
...
$ git fetch -p origin
$ git branch -d add-awesome-feature
```

Hope this helps!
Raphael

> On 28 Sep 2015, at 13:33, holger krekel <holger at merlinux.eu> wrote:
> 
> On Mon, Sep 28, 2015 at 11:15 +0000, Bruno Oliveira wrote:
>> On Mon, Sep 28, 2015 at 7:26 AM Florian Bruhin <me at the-compiler.org> wrote:
>> 
>>> I usually have the following workflow when I contribute to projects:
>>> 
>> 
>> I have the exact workflow as Florian. :)
>> 
>> I would only add that you can create your branches based directly on the
>> upstream:
>> 
>> $ git checkout -b fix-1234 upstream/master
>> $ git push origin
> 
> thanks.  The post Eldar referenced also advertises this workflow
> but additionally sets some config options:
> 
>    $ git config remote.pushdefault origin
>    $ git config push.default current
> 
> which means you can just say "git push" above.
> 
> I am trying out this work flow now.
> thanks everybody :)
> 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/20150928/e7c34c2f/attachment-0001.html>

From holger at merlinux.eu  Mon Sep 28 17:35:37 2015
From: holger at merlinux.eu (holger krekel)
Date: Mon, 28 Sep 2015 15:35:37 +0000
Subject: [pytest-dev] pytest 2.8.1 issue status and blockers
In-Reply-To: <5608D8F4.3090300@ronnypfannschmidt.de>
References: <5608D8F4.3090300@ronnypfannschmidt.de>
Message-ID: <20150928153537.GL26059@merlinux.eu>

Hi Ronny,

On Mon, Sep 28, 2015 at 08:06 +0200, Ronny Pfannschmidt wrote:
> Hi everyone,
> 
> over the weekend i had some time to do grooming and attempted a few
> fixes and did issue grooming
> 
> the 1.8.1 milestone is down to 4 open issues
> 
> https://github.com/pytest-dev/pytest/issues/1073
> * a fix in pluggy is on the way thanks to Brono!

that is fixed now (although differently than with Bruno's PR).

> https://github.com/pytest-dev/pytest/pull/1060
> * that pull request is currently not merge-able since it brings back
> regressions we fixed pre-2.8, but the items it fixes are critical
>   we def want that in
>
>   Buck did a great job of discovering the cause and doing the fixes,
>   unfortunately his refracting went too far and reintroduced an internal
> issue

This shouldn't block IMO -- also i am not sure what the original
problem is.

> https://github.com/pytest-dev/pytest/issues/1037
> * is a regression we def want to fix

I couldn't yet reproduce -- the issue is missing an example or details.
Let's generally ask people to provide an example that fails when
they post "pytest does not work with my project".

> https://github.com/pytest-dev/pytest/issues/1026
> * is not critical but nice to have documentation, ideally fixed in union
> with #1073

right, not a blocker.

As it stands, i don't see any blocker where I could effectively work on.

Given that current master fixes a number of issues there is not much
point in blocking 2.8.1 if you ask me.

holger


> i consider #1060 is a release blocker, but it has a very high backward
> break potential as is,
> however i cant work on it myself this week,

> we can either try to include it or should make a big note as a known
> issue and try to do another patch release as soon as its ready
> 
> current time-frames look like we should mark it as known issue
> 
> -- Ronny
> 
> _______________________________________________
> 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 holger at merlinux.eu  Tue Sep 29 15:41:35 2015
From: holger at merlinux.eu (holger krekel)
Date: Tue, 29 Sep 2015 13:41:35 +0000
Subject: [pytest-dev] pytest-2.8.1: fixes and more fixes
Message-ID: <20150929134135.GB29865@merlinux.eu>


Just 11 days after 2.8 hit PyPI we published pytest-2.8.1 which fixes a
host of regressions and bugs, see the changelog excerpt below.  Docs are
also freshly generated at http://pytest.org including a streamlined PDF.

Note that the pytest team now follows more SEMVER style versioning
which currently means that you can expect bugfixes with 2.8.X and new
features with 2.9.0 and planned incompatibilities with 3.0.

Many thanks to the PR contributors and mergers of 2.8.1:

    Bruno Oliveira
    Ronny Pfannschmidt
    Florian Bruhin
    Floris Bruynooghe
    Eric Hunsberger
    Tim Staley
    Simon Gomizelj
    Russel Winder
    Oleg Alexandrov
    Michael Howitz
    Michael Birtwell
    Ben Webb
    Andy Freeland
    Abhijeet Kasurde

cheers,
holger krekel

2.8.1
-----

- fix #1034: Add missing nodeid on pytest_logwarning call in
  addhook.  Thanks Simon Gomizelj for the PR.

- 'deprecated_call' is now only satisfied with a DeprecationWarning or
  PendingDeprecationWarning. Before 2.8.0, it accepted any warning, and 2.8.0
  made it accept only DeprecationWarning (but not PendingDeprecationWarning).
  Thanks Alex Gaynor for the issue and Eric Hunsberger for the PR.

- fix issue #1073: avoid calling __getattr__ on potential plugin objects.
  This fixes an incompatibility with pytest-django.  Thanks Andreas Pelme,
  Bruno Oliveira and Ronny Pfannschmidt for contributing and Holger Krekel
  for the fix.

- Fix issue #704: handle versionconflict during plugin loading more
  gracefully.  Thanks Bruno Oliveira for the PR.

- Fix issue #1064: ""--junitxml" regression when used with the
  "pytest-xdist" plugin, with test reports being assigned to the wrong tests.
  Thanks Daniel Grunwald for the report and Bruno Oliveira for the PR.

- (experimental) adapt more SEMVER style versioning and change meaning of 
  master branch in git repo: "master" branch now keeps the bugfixes, changes 
  aimed for micro releases.  "features" branch will only be be released 
  with minor or major pytest releases.

- Fix issue #766 by removing documentation references to distutils.
  Thanks Russel Winder.

- Fix issue #1030: now byte-strings are escaped to produce item node ids
  to make them always serializable.
  Thanks Andy Freeland for the report and Bruno Oliveira for the PR.

- Python 2: if unicode parametrized values are convertible to ascii, their
  ascii representation is used for the node id.

- Fix issue #411: Add __eq__ method to assertion comparison example.
  Thanks Ben Webb.

- fix issue 877: properly handle assertion explanations with non-ascii repr
  Thanks Mathieu Agopian for the report and Ronny Pfannschmidt for the PR.

- fix issue 1029: transform errors when writing cache values into pytest-warnings


From holger at merlinux.eu  Tue Sep 29 18:26:04 2015
From: holger at merlinux.eu (holger krekel)
Date: Tue, 29 Sep 2015 16:26:04 +0000
Subject: [pytest-dev] how can one add fork to CI?
Message-ID: <20150929162604.GD29865@merlinux.eu>

Hi,

how can i add my hpk42/pytest and its 
branches to CI (travis/appveyor)testing?

holger

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

From opensource at ronnypfannschmidt.de  Tue Sep 29 19:25:36 2015
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Tue, 29 Sep 2015 19:25:36 +0200
Subject: [pytest-dev] how can one add fork to CI?
In-Reply-To: <20150929162604.GD29865@merlinux.eu>
References: <20150929162604.GD29865@merlinux.eu>
Message-ID: <4A810711-5194-4D09-8CA7-7E416CDEF836@ronnypfannschmidt.de>

Log in to the service via github, authorize them for the fork and then enable it with your user

The actual ui is with the services and not with github

Btw: IMHO a PR based workflow is preferable for giving other insight into the development process

Am 29. September 2015 18:26:04 MESZ, schrieb holger krekel <holger at merlinux.eu>:
>Hi,
>
>how can i add my hpk42/pytest and its 
>branches to CI (travis/appveyor)testing?
>
>holger

MFG Ronny