From nicoddemus at gmail.com  Wed Aug  5 00:42:53 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 04 Aug 2015 22:42:53 +0000
Subject: [pytest-dev] devpi channel for Travis CI testing of
	pytest-dev/pytest
Message-ID: <CA+RQFffYg2JJzZwwCR_+qVOu7OnD-JDEpEp=9-V30-AxwJV8rw@mail.gmail.com>

Hi everyone,

Currently we use Holger's private channel (https://devpi.net/hpk/dev) to
obtain packages for testing on Travis. How about if we create a
"pytest-dev" user on devpi.net which would be the official package source
for continuous integration of pytest-dev/pytest? This would allow other
contributors to fix CI-related problems (like recently experienced with
flakes in https://github.com/pytest-dev/pytest/pull/897).

I just noticed that AppVeyor obtains the packages directly from pip... I
think this is an oversight, correct?

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

From flub at devork.be  Wed Aug  5 11:01:27 2015
From: flub at devork.be (Floris Bruynooghe)
Date: Wed, 5 Aug 2015 10:01:27 +0100
Subject: [pytest-dev] devpi channel for Travis CI testing of
	pytest-dev/pytest
In-Reply-To: <CA+RQFffYg2JJzZwwCR_+qVOu7OnD-JDEpEp=9-V30-AxwJV8rw@mail.gmail.com>
References: <CA+RQFffYg2JJzZwwCR_+qVOu7OnD-JDEpEp=9-V30-AxwJV8rw@mail.gmail.com>
Message-ID: <CAAWk_DwPJSM3-eF7QW8gN209-Tu6R4zp4wMo3TkAcqyD0vzO=g@mail.gmail.com>

On 4 Aug 2015 23:43, "Bruno Oliveira" <nicoddemus at gmail.com> wrote:
> Currently we use Holger's private channel (https://devpi.net/hpk/dev) to
obtain packages for testing on Travis. How about if we create a
"pytest-dev" user on devpi.net which would be the official package source
for continuous integration of pytest-dev/pytest? This would allow other
contributors to fix CI-related problems (like recently experienced with
flakes in https://github.com/pytest-dev/pytest/pull/897).

Seems like a good idea. Maybe keep the channel name "dev" instead of
"pytest" though to not be too confusing as other packages like py will end
up in it too.

Floris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150805/a415043a/attachment.html>

From flub at devork.be  Wed Aug  5 19:43:59 2015
From: flub at devork.be (Floris Bruynooghe)
Date: Wed, 5 Aug 2015 18:43:59 +0100
Subject: [pytest-dev] Cheeseshop (PyPI) access
Message-ID: <20150805174359.GA26339@laurie.devork.be>

Hi all,

As discussed at EuroPython I was looking at giving everyone in the
pytest-dev groups on bitbucket and github access on the cheeseshop
(pypi) to be able to do releases.  Currently I only know the following
cheeseshop usernames however:

hpk
ronny
flub
nicoddemus
anatoly

So could other people in pytest-dev on either bitbucket or github
please let me know their usernames?  Preferably gpg signed and/or
encrypted if possible [0][1], but don't worry too much if not.

Additionally I only have the permissions to do this on the following
packages:

pytest
pytest-xdist
pytest-timeout (not yet in pytest-dev but it really should be ;-))

In particular I'm missing access to py :-)

Could owners of other repos enable other people as well if they agree?
Or if you can't be bothered to do this currently very manual task for
everyone just give me permissions and tell me to add the full list of
people and I'll patiently go through the list.

Regards,
Floris

[0] My key is 4CCB3FFC, as signed

[1] I also have keybase.io invites if you'd like some form of
    verification.  Keybase provides an easy way to "prove" a
    particular private key can control a particular github account,
    which has it's use [2].

[2] Not that this couldn't be done manually, but everyone is bad with
    manually doing things as proven by after having met Holger a few
    times in real life we still haven't verified our keys despite
    using them sometimes in email.  Ah, gpg.
-------------- 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/20150805/1bb6a5be/attachment.sig>

From holger at merlinux.eu  Wed Aug  5 21:42:35 2015
From: holger at merlinux.eu (holger krekel)
Date: Wed, 5 Aug 2015 19:42:35 +0000
Subject: [pytest-dev] Cheeseshop (PyPI) access
In-Reply-To: <20150805174359.GA26339@laurie.devork.be>
References: <20150805174359.GA26339@laurie.devork.be>
Message-ID: <20150805194235.GZ27948@merlinux.eu>

On Wed, Aug 05, 2015 at 18:43 +0100, Floris Bruynooghe wrote:
> Hi all,
> 
> As discussed at EuroPython I was looking at giving everyone in the
> pytest-dev groups on bitbucket and github access on the cheeseshop
> (pypi) to be able to do releases.  Currently I only know the following
> cheeseshop usernames however:
> 
> hpk
> ronny
> flub
> nicoddemus
> anatoly
> 
> So could other people in pytest-dev on either bitbucket or github
> please let me know their usernames?  Preferably gpg signed and/or
> encrypted if possible [0][1], but don't worry too much if not.
> 
> Additionally I only have the permissions to do this on the following
> packages:
> 
> pytest
> pytest-xdist
> pytest-timeout (not yet in pytest-dev but it really should be ;-))
>
> In particular I'm missing access to py :-)

Just double checked -- you are now owner (previously maintainer) of py.
I wonder if there are some scripts out there to manipulate pypi roles.

holger

> Could owners of other repos enable other people as well if they agree?
> Or if you can't be bothered to do this currently very manual task for
> everyone just give me permissions and tell me to add the full list of
> people and I'll patiently go through the list.
> 
> Regards,
> Floris
> 
> [0] My key is 4CCB3FFC, as signed
> 
> [1] I also have keybase.io invites if you'd like some form of
>     verification.  Keybase provides an easy way to "prove" a
>     particular private key can control a particular github account,
>     which has it's use [2].
> 
> [2] Not that this couldn't be done manually, but everyone is bad with
>     manually doing things as proven by after having met Holger a few
>     times in real life we still haven't verified our keys despite
>     using them sometimes in email.  Ah, gpg.



> _______________________________________________
> 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  Wed Aug  5 22:04:29 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Wed, 5 Aug 2015 22:04:29 +0200
Subject: [pytest-dev] Cheeseshop (PyPI) access
In-Reply-To: <20150805174359.GA26339@laurie.devork.be>
References: <20150805174359.GA26339@laurie.devork.be>
Message-ID: <20150805200429.GF18503@tonks>

* Floris Bruynooghe <flub at devork.be> [2015-08-05 18:43:59 +0100]:
> So could other people in pytest-dev on either bitbucket or github
> please let me know their usernames?  Preferably gpg signed and/or
> encrypted if possible [0][1], but don't worry too much if not.

I'm The_Compiler and this mail is signed.

> [2] Not that this couldn't be done manually, but everyone is bad with
>     manually doing things as proven by after having met Holger a few
>     times in real life we still haven't verified our keys despite
>     using them sometimes in email.  Ah, gpg.

Gah. I wanted to sign your (collective-you) keys at EP exactly for
situations like this but totally forgot...

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/20150805/dc2321a3/attachment.sig>

From bubenkoff at gmail.com  Sun Aug  9 02:54:20 2015
From: bubenkoff at gmail.com (Anatoly Bubenkov)
Date: Sun, 09 Aug 2015 00:54:20 +0000
Subject: [pytest-dev] Flaky tests
Message-ID: <CACTnz+E-yn-vAYw2Gacb2ojxr=L7d9HCdv99Fzm+BLuNwDDfqg@mail.gmail.com>

Hi all,
flaky tests are often really hard to make not flaky, so I've got the idea
to just retry failed tests several times automatically and only then report
the failure.
I was not the only one of course: there's nice initiative in face of
https://github.com/box/flaky
The big downside of that plugin's approach, is that only 'call' phase is
retried, while 'setup' is not re-executed and so all function-scoped
fixtures stay as is from previous try.
This is not acceptable if you use fixtures intensively of course.
I created an issue where I have a snippet how it could work
https://github.com/box/flaky/issues/53
But then realized that it doesn't work properly still: when it's the only
test collected which we're going to retry, all fixtures, including
session-scoped are being resetup as well!
Then looked more and couldn't find any good solutions to actually very
simple question: how do i rerun the test in the same test run?
Any help is appreciated. I think making that plugin work or even making it
available in the core would be a great improvement.
Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150809/a8ae15fc/attachment.html>

From schettino72 at gmail.com  Sun Aug  9 08:14:09 2015
From: schettino72 at gmail.com (Eduardo Schettino)
Date: Sun, 9 Aug 2015 14:14:09 +0800
Subject: [pytest-dev] Flaky tests
In-Reply-To: <CACTnz+E-yn-vAYw2Gacb2ojxr=L7d9HCdv99Fzm+BLuNwDDfqg@mail.gmail.com>
References: <CACTnz+E-yn-vAYw2Gacb2ojxr=L7d9HCdv99Fzm+BLuNwDDfqg@mail.gmail.com>
Message-ID: <CAHSrCY0=KrpGzmRvbhArH-hcxEKNaV7k310WVqBGkaECYDADZg@mail.gmail.com>

Hi,

I will just throw out another idea that I had about handling flaky tests.

I think it would be nice to mark a test as "flaky" and than treat it
differently if it fails.

For example, once a test is marked as flaky you could choose to ignore
flaky test failures and maybe report them
as an "expect failure" or some other custom status. Or still consider it as
failure if run on a "strict mode".

regards,
  Eduardo

On Sun, Aug 9, 2015 at 8:54 AM, Anatoly Bubenkov <bubenkoff at gmail.com>
wrote:

> Hi all,
> flaky tests are often really hard to make not flaky, so I've got the idea
> to just retry failed tests several times automatically and only then report
> the failure.
> I was not the only one of course: there's nice initiative in face of
> https://github.com/box/flaky
> The big downside of that plugin's approach, is that only 'call' phase is
> retried, while 'setup' is not re-executed and so all function-scoped
> fixtures stay as is from previous try.
> This is not acceptable if you use fixtures intensively of course.
> I created an issue where I have a snippet how it could work
> https://github.com/box/flaky/issues/53
> But then realized that it doesn't work properly still: when it's the only
> test collected which we're going to retry, all fixtures, including
> session-scoped are being resetup as well!
> Then looked more and couldn't find any good solutions to actually very
> simple question: how do i rerun the test in the same test run?
> Any help is appreciated. I think making that plugin work or even making it
> available in the core would be a great improvement.
> Thanks!
>
> _______________________________________________
> 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/20150809/d5a076b7/attachment.html>

From me at the-compiler.org  Sun Aug  9 10:56:26 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Sun, 9 Aug 2015 10:56:26 +0200
Subject: [pytest-dev] Flaky tests
In-Reply-To: <CACTnz+E-yn-vAYw2Gacb2ojxr=L7d9HCdv99Fzm+BLuNwDDfqg@mail.gmail.com>
References: <CACTnz+E-yn-vAYw2Gacb2ojxr=L7d9HCdv99Fzm+BLuNwDDfqg@mail.gmail.com>
Message-ID: <20150809085626.GF27668@tonks>

* Anatoly Bubenkov <bubenkoff at gmail.com> [2015-08-09 00:54:20 +0000]:
> The big downside of that plugin's approach, is that only 'call' phase is
> retried, while 'setup' is not re-executed and so all function-scoped
> fixtures stay as is from previous try.
> This is not acceptable if you use fixtures intensively of course.
> I created an issue where I have a snippet how it could work
> https://github.com/box/flaky/issues/53
> But then realized that it doesn't work properly still: when it's the only
> test collected which we're going to retry, all fixtures, including
> session-scoped are being resetup as well!
> Then looked more and couldn't find any good solutions to actually very
> simple question: how do i rerun the test in the same test run?
> Any help is appreciated. I think making that plugin work or even making it
> available in the core would be a great improvement.
> Thanks!

This sounds like another possible usecase for this issue:

https://github.com/pytest-dev/pytest/issues/916

Mind adding a comment there explaining your usecase?

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/20150809/056d0ea8/attachment.sig>

From me at the-compiler.org  Sun Aug  9 10:57:40 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Sun, 9 Aug 2015 10:57:40 +0200
Subject: [pytest-dev] Flaky tests
In-Reply-To: <CAHSrCY0=KrpGzmRvbhArH-hcxEKNaV7k310WVqBGkaECYDADZg@mail.gmail.com>
References: <CACTnz+E-yn-vAYw2Gacb2ojxr=L7d9HCdv99Fzm+BLuNwDDfqg@mail.gmail.com>
 <CAHSrCY0=KrpGzmRvbhArH-hcxEKNaV7k310WVqBGkaECYDADZg@mail.gmail.com>
Message-ID: <20150809085740.GG27668@tonks>

* Eduardo Schettino <schettino72 at gmail.com> [2015-08-09 14:14:09 +0800]:
> I will just throw out another idea that I had about handling flaky tests.
> 
> I think it would be nice to mark a test as "flaky" and than treat it
> differently if it fails.
> 
> For example, once a test is marked as flaky you could choose to ignore
> flaky test failures and maybe report them
> as an "expect failure" or some other custom status. Or still consider it as
> failure if run on a "strict mode".

Also see this issue which proposes a separate marker for flaky tests:

https://github.com/pytest-dev/pytest/issues/814

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/20150809/5c50ad98/attachment.sig>

From flub at devork.be  Sun Aug  9 23:40:23 2015
From: flub at devork.be (Floris Bruynooghe)
Date: Sun, 9 Aug 2015 22:40:23 +0100
Subject: [pytest-dev] Cheeseshop (PyPI) access
In-Reply-To: <20150805174359.GA26339@laurie.devork.be>
References: <20150805174359.GA26339@laurie.devork.be>
Message-ID: <CAAWk_Dw7cWuVJnzabFNh87_BJZD7e_W_e=exBb9+oNZgzEcm-Q@mail.gmail.com>

Hi All,

I've now added most of core pytest-dev team (i.e. owners of pytest-dev
on github/bitbucket) to the following districutions on the cheeseshop:

py
pytest
pytest-cpp
pytest-faulthandler
pytest-mock
pytest-qt
pytest-timeout
pytest-xdist

It seems most of the plugin authors/contributors haven't joined this
yet.  So if you're a pytest-dev member on github/bitbucket and would
like to be able to release any of the above packages (or just want to
increase their bus-factor even if you don't mind being able to release
them) just let me know your pypi username.

Likewise if you're a plugin maintainer and would like to increase the
pypi bus-factor of your plugin give me permissions and ping me and
I'll add all pytest-dev members to your package.  No need to worry,
unless there's something important and you're not responding for a few
months no one will do a release without your consent.

Regards,
Floris



On 5 August 2015 at 18:43, Floris Bruynooghe <flub at devork.be> wrote:
> Hi all,
>
> As discussed at EuroPython I was looking at giving everyone in the
> pytest-dev groups on bitbucket and github access on the cheeseshop
> (pypi) to be able to do releases.  Currently I only know the following
> cheeseshop usernames however:
>
> hpk
> ronny
> flub
> nicoddemus
> anatoly
>
> So could other people in pytest-dev on either bitbucket or github
> please let me know their usernames?  Preferably gpg signed and/or
> encrypted if possible [0][1], but don't worry too much if not.
>
> Additionally I only have the permissions to do this on the following
> packages:
>
> pytest
> pytest-xdist
> pytest-timeout (not yet in pytest-dev but it really should be ;-))
>
> In particular I'm missing access to py :-)
>
> Could owners of other repos enable other people as well if they agree?
> Or if you can't be bothered to do this currently very manual task for
> everyone just give me permissions and tell me to add the full list of
> people and I'll patiently go through the list.
>
> Regards,
> Floris
>
> [0] My key is 4CCB3FFC, as signed
>
> [1] I also have keybase.io invites if you'd like some form of
>     verification.  Keybase provides an easy way to "prove" a
>     particular private key can control a particular github account,
>     which has it's use [2].
>
> [2] Not that this couldn't be done manually, but everyone is bad with
>     manually doing things as proven by after having met Holger a few
>     times in real life we still haven't verified our keys despite
>     using them sometimes in email.  Ah, gpg.

From me at the-compiler.org  Sun Aug  9 23:55:09 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Sun, 9 Aug 2015 23:55:09 +0200
Subject: [pytest-dev] Releases
Message-ID: <20150809215509.GA14835@tonks>

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/
-------------- 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/20150809/7f2ff687/attachment.sig>

From nicoddemus at gmail.com  Mon Aug 10 00:45:52 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Sun, 09 Aug 2015 22:45:52 +0000
Subject: [pytest-dev] Releases
In-Reply-To: <20150809215509.GA14835@tonks>
References: <20150809215509.GA14835@tonks>
Message-ID: <CA+RQFfczRoZp14A6Z4Asg2LQj5UX=enK014x3j=8dLcoQwvEvg@mail.gmail.com>

Hi,

I also think we should release 2.8 directly.

There are a couple of issues/PRs that should go into 2.8, IMO:

- Merge pytest-cache into core (
https://github.com/pytest-dev/pytest/pull/828); I think Ronny is working on
this;
- Release pytest-xdist 1.13, so we can merge "non-zero exit code if no
tests are collected" (https://github.com/pytest-dev/pytest/pull/817); I
think Ronny is about to release 1.13;

Actually, merge all PRs that are pending would be a good target, as they
all seem like good additions to a new major release.

I think Holger also said before that he would like to vendor pluggy into
pytest before releasing 2.8 thought. Is there anything here that we can do
to help?

How should we proceed? Perhaps it would be good to set a ballpark date for
2.8, say two/three weeks from now? This will be probably enough time to dig
into the issue tracker for critical bugs and to round up the remaining PRs.

Cheers,
Bruno.



On Sun, Aug 9, 2015 at 6:55 PM Florian Bruhin <me at the-compiler.org> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150809/4ae7cd32/attachment.html>

From schettino72 at gmail.com  Tue Aug 11 06:48:13 2015
From: schettino72 at gmail.com (Eduardo Schettino)
Date: Tue, 11 Aug 2015 12:48:13 +0800
Subject: [pytest-dev] [ANN] pytest-ignore-flaky plugin 0.1.0
Message-ID: <CAHSrCY0Hn73q1k_CAzBcyzj9oG97YLhdbP0ZNJY1wKqucoQpGg@mail.gmail.com>

Hi,

I just published a new plugin to hadle flaky tests:

https://pypi.python.org/pypi/pytest-ignore-flaky
https://github.com/schettino72/pytest-ignore-flaky

feedback welcome

cheers,
  Eduardo


pytest-ignore-flaky
====================

ignore failures from flaky tests (pytest plugin)

A "flaky" test is a test that usually pass but sometimes it fails.
You should always avoid flaky tests but not always possible.

This plugin can be used to optionally ignore failures from flaky tests.

First "mark" your tests with the `flaky` marker::

  import random
  import pytest

  @pytest.mark.flaky
  def test_mf():
      assert 0 == random.randint(0, 1)

By default this mark is just ignored, unless the plugin is activated from
the
command line (or `py.test` config file)::

  py.test --ignore-flaky

If a flaky test pass it will be reported normally as test succeed.
If the test fails, instead of being reported as failure it will be reported
as
a `xfail`.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150811/07a96f8f/attachment.html>

From kai at gronr.com  Thu Aug 13 23:47:32 2015
From: kai at gronr.com (Kai Groner)
Date: Thu, 13 Aug 2015 17:47:32 -0400
Subject: [pytest-dev] Working with other dependency injection systems
In-Reply-To: <20150507112107.GA28354@merlinux.eu>
References: <CALiRux=JiSht3dEENkEWaP5Ob9gzGADFJAS74Pu5qq-9sP2gEQ@mail.gmail.com>
 <20150507112107.GA28354@merlinux.eu>
Message-ID: <CALiRuxmcQmrM4X8fPaFBCajZMOEjcL4DenK2hksHe1YABSXRNw@mail.gmail.com>

Hi holger,

Thanks for your response.  Sorry I haven't followed up sooner.

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.

> 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.


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

From wosc at wosc.de  Fri Aug 14 17:49:25 2015
From: wosc at wosc.de (Wolfgang Schnerring)
Date: Fri, 14 Aug 2015 17:49:25 +0200
Subject: [pytest-dev] Can we get a pytest-timeout release?
Message-ID: <20150814154925.GA2957@anthrakas.wosc.de>

Hi,

the PR https://bitbucket.org/flub/pytest-timeout/pull-requests/3 has
been merged on 2014-09-23, is there chance someone could make a
release of this? I'm eagerly awaiting it, and cursing each time the
timeout kills my hard-earned pdb session...

Thanks,
Wolfgang
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 173 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150814/1039d07b/attachment.sig>

From flub at devork.be  Sat Aug 15 01:20:49 2015
From: flub at devork.be (Floris Bruynooghe)
Date: Sat, 15 Aug 2015 00:20:49 +0100
Subject: [pytest-dev] Can we get a pytest-timeout release?
In-Reply-To: <20150814154925.GA2957@anthrakas.wosc.de>
References: <20150814154925.GA2957@anthrakas.wosc.de>
Message-ID: <CAAWk_DwUMEu8SwJQAu7R=7vF-gn8_zAV5P5+0TYxMJCxZu0+UA@mail.gmail.com>

Hi,

Just checking this but I believe the PR you refer too is already
released as part of the 0.4 release on
https://pypi.python.org/pypi/pytest-timeout/0.4  Am I mistaken
somehow?  I don't think there's currently any commits that are not
released AFAIK, but I could be terribly wrong.

Regards,
Floris


On 14 August 2015 at 16:49, Wolfgang Schnerring <wosc at wosc.de> wrote:
> Hi,
>
> the PR https://bitbucket.org/flub/pytest-timeout/pull-requests/3 has
> been merged on 2014-09-23, is there chance someone could make a
> release of this? I'm eagerly awaiting it, and cursing each time the
> timeout kills my hard-earned pdb session...
>
> Thanks,
> Wolfgang
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>

From flub at devork.be  Sat Aug 15 01:48:29 2015
From: flub at devork.be (Floris Bruynooghe)
Date: Sat, 15 Aug 2015 00:48:29 +0100
Subject: [pytest-dev] Can we get a pytest-timeout release?
In-Reply-To: <CAAWk_DwUMEu8SwJQAu7R=7vF-gn8_zAV5P5+0TYxMJCxZu0+UA@mail.gmail.com>
References: <20150814154925.GA2957@anthrakas.wosc.de>
 <CAAWk_DwUMEu8SwJQAu7R=7vF-gn8_zAV5P5+0TYxMJCxZu0+UA@mail.gmail.com>
Message-ID: <CAAWk_DxGtgsUjU_+k+o_OwtwswzFkgyEur6LeHkrfGU-vZJKWg@mail.gmail.com>

Hi Wolfgang,

Apologies, so apparently I was mistaken and somehow the changelog got
a little confused.  I think I've now rectified this and have just
released a 0.5 version.  Please let me know if I've still messed this
up somehow.

I've also taken the opportunity to finally move it to the pytest-dev
team as well.  :-)

Regards,
Floris

On 15 August 2015 at 00:20, Floris Bruynooghe <flub at devork.be> wrote:
> Hi,
>
> Just checking this but I believe the PR you refer too is already
> released as part of the 0.4 release on
> https://pypi.python.org/pypi/pytest-timeout/0.4  Am I mistaken
> somehow?  I don't think there's currently any commits that are not
> released AFAIK, but I could be terribly wrong.
>
> Regards,
> Floris
>
>
> On 14 August 2015 at 16:49, Wolfgang Schnerring <wosc at wosc.de> wrote:
>> Hi,
>>
>> the PR https://bitbucket.org/flub/pytest-timeout/pull-requests/3 has
>> been merged on 2014-09-23, is there chance someone could make a
>> release of this? I'm eagerly awaiting it, and cursing each time the
>> timeout kills my hard-earned pdb session...
>>
>> Thanks,
>> Wolfgang
>>
>> _______________________________________________
>> pytest-dev mailing list
>> pytest-dev at python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>

From wosc at wosc.de  Sat Aug 15 09:14:55 2015
From: wosc at wosc.de (Wolfgang Schnerring)
Date: Sat, 15 Aug 2015 09:14:55 +0200
Subject: [pytest-dev] Can we get a pytest-timeout release?
In-Reply-To: <CAAWk_DxGtgsUjU_+k+o_OwtwswzFkgyEur6LeHkrfGU-vZJKWg@mail.gmail.com>
References: <20150814154925.GA2957@anthrakas.wosc.de>
 <CAAWk_DwUMEu8SwJQAu7R=7vF-gn8_zAV5P5+0TYxMJCxZu0+UA@mail.gmail.com>
 <CAAWk_DxGtgsUjU_+k+o_OwtwswzFkgyEur6LeHkrfGU-vZJKWg@mail.gmail.com>
Message-ID: <20150815071455.GA3010@anthrakas.wosc.de>

Hey Floris,

* Floris Bruynooghe <flub at devork.be> [2015-08-15 00:48]:
> Apologies, so apparently I was mistaken and somehow the changelog got
> a little confused.  I think I've now rectified this and have just
> released a 0.5 version.  Please let me know if I've still messed this
> up somehow.

Thanks a lot, this now works like a charm!

Wolfgang
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 173 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150815/0abcd0f4/attachment.sig>

From opensource at ronnypfannschmidt.de  Tue Aug 18 08:53:14 2015
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Tue, 18 Aug 2015 08:53:14 +0200
Subject: [pytest-dev] pytest-xdist 1.13 release
Message-ID: <55D2D65A.10408@ronnypfannschmidt.de>

Hello,

i'm pleased to announce the release of pytest-xdist 1.13

changes to 1.2 are:

- extended the tox matrix with the supported py.test versions

- split up the plugin into 3 plugin's
  to prepare the departure of boxed and looponfail.

  looponfail will be a part of core
  and forked boxed will be replaced
  with a more reliable primitive based on xdist

- conforming with new pytest-2.8 behavior of returning non-zero when all
  tests were skipped or deselected.

- new "--max-slave-restart" option that can be used to control maximum
  number of times pytest-xdist can restart slaves due to crashes. Thanks to
  Anatoly Bubenkov for the report and Bruno Oliveira for the PR.
 
- release as wheel

- "-n" option now can be set to "auto" for automatic detection of number
  of cpus in the host system. Thanks Suloev Dmitry for the PR.


-- Ronny

From flub at devork.be  Tue Aug 25 10:45:31 2015
From: flub at devork.be (Floris Bruynooghe)
Date: Tue, 25 Aug 2015 09:45:31 +0100
Subject: [pytest-dev] Releases
In-Reply-To: <CA+RQFfczRoZp14A6Z4Asg2LQj5UX=enK014x3j=8dLcoQwvEvg@mail.gmail.com>
References: <20150809215509.GA14835@tonks>
 <CA+RQFfczRoZp14A6Z4Asg2LQj5UX=enK014x3j=8dLcoQwvEvg@mail.gmail.com>
Message-ID: <CAAWk_DxkAF76s9c1nMsk-DP7shUxBRY97=68_BWZPu6U-+SJZw@mail.gmail.com>

Hello,

On 9 August 2015 at 23:45, Bruno Oliveira <nicoddemus at gmail.com> wrote:
> Hi,
>
> I also think we should release 2.8 directly.

Yes, a release which supports python 3.5 would be nice.  AFAIK we
could just release 2.7.3 without any work so if someone wants to
release that I think you should just do it.


> There are a couple of issues/PRs that should go into 2.8, IMO:
>
> - Merge pytest-cache into core
> (https://github.com/pytest-dev/pytest/pull/828); I think Ronny is working on
> this;
> - Release pytest-xdist 1.13, so we can merge "non-zero exit code if no tests
> are collected" (https://github.com/pytest-dev/pytest/pull/817); I think
> Ronny is about to release 1.13;
>
> Actually, merge all PRs that are pending would be a good target, as they all
> seem like good additions to a new major release.

These are nice to have, but not strictly needed.

> I think Holger also said before that he would like to vendor pluggy into
> pytest before releasing 2.8 thought. Is there anything here that we can do
> to help?

This on the other hand is more of a blocker.  I think what we need is
some code in setup.py which automatically fetches the required pluggy
version from pypi and vendors it when  making sdists and wheels.  At
least while pluggy versions are < 1.0.  Once that's done we should be
able to release 2.8 without any problems.

> How should we proceed? Perhaps it would be good to set a ballpark date for
> 2.8, say two/three weeks from now? This will be probably enough time to dig
> into the issue tracker for critical bugs and to round up the remaining PRs.

I'd say, anyone who'd like to see a release should just make it happen
- everyone has the required permissions now.  I'd love to see a
release myself too but realistically am kept rather busy currently so
it's not the highest on my todo list (and admittedly, git is still
slowing me down for now so everything takes me longer currently :-/
I'll catch up eventually I'm sure).

Regards,
Floris

From me at the-compiler.org  Tue Aug 25 12:10:00 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Tue, 25 Aug 2015 12:10:00 +0200
Subject: [pytest-dev] Releases
In-Reply-To: <CAAWk_DxkAF76s9c1nMsk-DP7shUxBRY97=68_BWZPu6U-+SJZw@mail.gmail.com>
References: <20150809215509.GA14835@tonks>
 <CA+RQFfczRoZp14A6Z4Asg2LQj5UX=enK014x3j=8dLcoQwvEvg@mail.gmail.com>
 <CAAWk_DxkAF76s9c1nMsk-DP7shUxBRY97=68_BWZPu6U-+SJZw@mail.gmail.com>
Message-ID: <20150825101000.GK509@tonks>

* Floris Bruynooghe <flub at devork.be> [2015-08-25 09:45:31 +0100]:
> Hello,
> 
> On 9 August 2015 at 23:45, Bruno Oliveira <nicoddemus at gmail.com> wrote:
> > Hi,
> >
> > I also think we should release 2.8 directly.
> 
> Yes, a release which supports python 3.5 would be nice.  AFAIK we
> could just release 2.7.3 without any work so if someone wants to
> release that I think you should just do it.

The Python 3.5 PR[1] was merged to master - it'd need to be backported
to the pytest-2.7 branch first, right?

[1] https://github.com/pytest-dev/pytest/pull/801

> > There are a couple of issues/PRs that should go into 2.8, IMO:
> >
> > - Merge pytest-cache into core
> > (https://github.com/pytest-dev/pytest/pull/828); I think Ronny is working on
> > this;
> > - Release pytest-xdist 1.13, so we can merge "non-zero exit code if no tests
> > are collected" (https://github.com/pytest-dev/pytest/pull/817); I think
> > Ronny is about to release 1.13;
> >
> > Actually, merge all PRs that are pending would be a good target, as they all
> > seem like good additions to a new major release.
> 
> These are nice to have, but not strictly needed.

Most of them are merged in the meantime:
https://github.com/pytest-dev/pytest/pulls

There are only 4 open:

- https://github.com/pytest-dev/pytest/pull/908 by Elizaveta239
  Apply indirect=True on particular argnames

  It seems work is going on to get it merged.

- https://github.com/pytest-dev/pytest/pull/878 by ronny
  reencode non-ascii python2 assertion reprs

  Apparently that's actually a bug in pylib - should this still be
  merged to have a workaround until the real bug is fixed, or should
  this be abandoned?

- https://github.com/pytest-dev/pytest/pull/831 by ronny
  stop running yield test setupstate at collection time

  I'm not sure what the state of this is - seems like it's waiting for
  review?

- https://github.com/pytest-dev/pytest/pull/828 by ronny
  merge the pytest-cache plugin into core

  I think ronny wanted to finish this somewhen soon.


> > I think Holger also said before that he would like to vendor pluggy into
> > pytest before releasing 2.8 thought. Is there anything here that we can do
> > to help?
> 
> This on the other hand is more of a blocker.  I think what we need is
> some code in setup.py which automatically fetches the required pluggy
> version from pypi and vendors it when  making sdists and wheels.  At
> least while pluggy versions are < 1.0.  Once that's done we should be
> able to release 2.8 without any problems.

What's the motivation to vendor pluggy rather than depending on it and
letting packages distribute it?

I also opened an issue for that recently:

https://github.com/pytest-dev/pytest/issues/944

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/20150825/1d81b720/attachment.sig>

From nicoddemus at gmail.com  Tue Aug 25 13:58:08 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 25 Aug 2015 11:58:08 +0000
Subject: [pytest-dev] Releases
In-Reply-To: <20150825101000.GK509@tonks>
References: <20150809215509.GA14835@tonks>
 <CA+RQFfczRoZp14A6Z4Asg2LQj5UX=enK014x3j=8dLcoQwvEvg@mail.gmail.com>
 <CAAWk_DxkAF76s9c1nMsk-DP7shUxBRY97=68_BWZPu6U-+SJZw@mail.gmail.com>
 <20150825101000.GK509@tonks>
Message-ID: <CA+RQFff1rjrNfPonGFiYZi--LFiDPRgKu9=DAQ-ENjp5usPjfw@mail.gmail.com>

> * Floris Bruynooghe <flub at devork.be> [2015-08-25 09:45:31 +0100]:
> This on the other hand is more of a blocker.  I think what we need is
> some code in setup.py which automatically fetches the required pluggy
> version from pypi and vendors it when  making sdists and wheels.

Any reason to pinpoint that at release time only? I think it is desirable
to be able to pinpoint this during development as well.

As I understand it, vendoring means that we will have a copy of pluggy's
code into pytest under a different package name (say,
"_pytest.vendor.pluggy").

How about:

* Create a script which fetches the latest pluggy version, and installs it
into `_pytest.vendor.pluggy`;
* Add `_pytest.vendor.pluggy` to version control
* Update all references in pytest from `pluggy` to `_pytest.vendor.pluggy`;
* Remove the dependency from `setup.py`;

This way, we have total control on which version of pluggy we are using,
even during development, so it won't bring any surprises when merging PRs,
or differences between boxes. Also, upgrading to a new pluggy version is
just a matter of running the script and opening up a PR. :)

If you guys agree with this, I can work on it no problem.

> Florian Bruhin <me at the-compiler.org> wrote:
> What's the motivation to vendor pluggy rather than depending on it and letting
packages distribute it?

(I somehow missed the issue, I'm posting my comment below in there as well)

I think the reason is that it is very immature at this point: pluggy is at
0.3.0 now, but 0.4.0 might be backwards incompatible and would break all
pytest installations out there, and it isn't desirable to generate a new
pytest release just to comply with the changes in the new pluggy version.
One might pinpoint pluggy to a specific version in pytest, but I think it
is desirable to be able to create new features (possibly backward
incompatible ones) when working on another project which uses pluggy (devpi
for example), and that would pose a problem for users which use both
projects in the same environment, as both would have to be pinpointed to
incompatible versions.

Cheers,
Bruno.

On Tue, Aug 25, 2015 at 7:10 AM Florian Bruhin <me at the-compiler.org> wrote:

> * Floris Bruynooghe <flub at devork.be> [2015-08-25 09:45:31 +0100]:
> > Hello,
> >
> > On 9 August 2015 at 23:45, Bruno Oliveira <nicoddemus at gmail.com> wrote:
> > > Hi,
> > >
> > > I also think we should release 2.8 directly.
> >
> > Yes, a release which supports python 3.5 would be nice.  AFAIK we
> > could just release 2.7.3 without any work so if someone wants to
> > release that I think you should just do it.
>
> The Python 3.5 PR[1] was merged to master - it'd need to be backported
> to the pytest-2.7 branch first, right?
>
> [1] https://github.com/pytest-dev/pytest/pull/801
>
> > > There are a couple of issues/PRs that should go into 2.8, IMO:
> > >
> > > - Merge pytest-cache into core
> > > (https://github.com/pytest-dev/pytest/pull/828); I think Ronny is
> working on
> > > this;
> > > - Release pytest-xdist 1.13, so we can merge "non-zero exit code if no
> tests
> > > are collected" (https://github.com/pytest-dev/pytest/pull/817); I
> think
> > > Ronny is about to release 1.13;
> > >
> > > Actually, merge all PRs that are pending would be a good target, as
> they all
> > > seem like good additions to a new major release.
> >
> > These are nice to have, but not strictly needed.
>
> Most of them are merged in the meantime:
> https://github.com/pytest-dev/pytest/pulls
>
> There are only 4 open:
>
> - https://github.com/pytest-dev/pytest/pull/908 by Elizaveta239
>   Apply indirect=True on particular argnames
>
>   It seems work is going on to get it merged.
>
> - https://github.com/pytest-dev/pytest/pull/878 by ronny
>   reencode non-ascii python2 assertion reprs
>
>   Apparently that's actually a bug in pylib - should this still be
>   merged to have a workaround until the real bug is fixed, or should
>   this be abandoned?
>
> - https://github.com/pytest-dev/pytest/pull/831 by ronny
>   stop running yield test setupstate at collection time
>
>   I'm not sure what the state of this is - seems like it's waiting for
>   review?
>
> - https://github.com/pytest-dev/pytest/pull/828 by ronny
>   merge the pytest-cache plugin into core
>
>   I think ronny wanted to finish this somewhen soon.
>
>
> > > I think Holger also said before that he would like to vendor pluggy
> into
> > > pytest before releasing 2.8 thought. Is there anything here that we
> can do
> > > to help?
> >
> > This on the other hand is more of a blocker.  I think what we need is
> > some code in setup.py which automatically fetches the required pluggy
> > version from pypi and vendors it when  making sdists and wheels.  At
> > least while pluggy versions are < 1.0.  Once that's done we should be
> > able to release 2.8 without any problems.
>
> What's the motivation to vendor pluggy rather than depending on it and
> letting packages distribute it?
>
> I also opened an issue for that recently:
>
> https://github.com/pytest-dev/pytest/issues/944
>
> 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/20150825/a337f089/attachment.html>

From me at the-compiler.org  Tue Aug 25 14:26:39 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Tue, 25 Aug 2015 14:26:39 +0200
Subject: [pytest-dev] Releases
In-Reply-To: <CA+RQFff1rjrNfPonGFiYZi--LFiDPRgKu9=DAQ-ENjp5usPjfw@mail.gmail.com>
References: <20150809215509.GA14835@tonks>
 <CA+RQFfczRoZp14A6Z4Asg2LQj5UX=enK014x3j=8dLcoQwvEvg@mail.gmail.com>
 <CAAWk_DxkAF76s9c1nMsk-DP7shUxBRY97=68_BWZPu6U-+SJZw@mail.gmail.com>
 <20150825101000.GK509@tonks>
 <CA+RQFff1rjrNfPonGFiYZi--LFiDPRgKu9=DAQ-ENjp5usPjfw@mail.gmail.com>
Message-ID: <20150825122639.GN509@tonks>

* Bruno Oliveira <nicoddemus at gmail.com> [2015-08-25 11:58:08 +0000]:
> > * Floris Bruynooghe <flub at devork.be> [2015-08-25 09:45:31 +0100]:
> > This on the other hand is more of a blocker.  I think what we need is
> > some code in setup.py which automatically fetches the required pluggy
> > version from pypi and vendors it when  making sdists and wheels.
> 
> Any reason to pinpoint that at release time only? I think it is desirable
> to be able to pinpoint this during development as well.
> 
> As I understand it, vendoring means that we will have a copy of pluggy's
> code into pytest under a different package name (say,
> "_pytest.vendor.pluggy").
> 
> How about:
> 
> * Create a script which fetches the latest pluggy version, and installs it
> into `_pytest.vendor.pluggy`;
> * Add `_pytest.vendor.pluggy` to version control
> * Update all references in pytest from `pluggy` to `_pytest.vendor.pluggy`;
> * Remove the dependency from `setup.py`;
> 
> This way, we have total control on which version of pluggy we are using,
> even during development, so it won't bring any surprises when merging PRs,
> or differences between boxes. Also, upgrading to a new pluggy version is
> just a matter of running the script and opening up a PR. :)
> 
> If you guys agree with this, I can work on it no problem.

That's how I handled something similar in my project, and it did work
fine (I later then got rid of that 3rdparty requirement).

> > Florian Bruhin <me at the-compiler.org> wrote:
> > What's the motivation to vendor pluggy rather than depending on it and letting
> packages distribute it?
> 
> (I somehow missed the issue, I'm posting my comment below in there as well)
> 
> I think the reason is that it is very immature at this point: pluggy is at
> 0.3.0 now, but 0.4.0 might be backwards incompatible and would break all
> pytest installations out there, and it isn't desirable to generate a new
> pytest release just to comply with the changes in the new pluggy version.
> One might pinpoint pluggy to a specific version in pytest, but I think it
> is desirable to be able to create new features (possibly backward
> incompatible ones) when working on another project which uses pluggy (devpi
> for example), and that would pose a problem for users which use both
> projects in the same environment, as both would have to be pinpointed to
> incompatible versions.

I answered on the issue:

https://github.com/pytest-dev/pytest/issues/944#issuecomment-134568839

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/20150825/ca550282/attachment-0001.sig>

From flub at devork.be  Tue Aug 25 14:56:11 2015
From: flub at devork.be (Floris Bruynooghe)
Date: Tue, 25 Aug 2015 13:56:11 +0100
Subject: [pytest-dev] Releases
In-Reply-To: <20150825101000.GK509@tonks>
References: <20150809215509.GA14835@tonks>
 <CA+RQFfczRoZp14A6Z4Asg2LQj5UX=enK014x3j=8dLcoQwvEvg@mail.gmail.com>
 <CAAWk_DxkAF76s9c1nMsk-DP7shUxBRY97=68_BWZPu6U-+SJZw@mail.gmail.com>
 <20150825101000.GK509@tonks>
Message-ID: <CAAWk_Dx+AC5kCoTOkUCZUAWPL=q4RuYsRo0-jsxuNBhn_=R9mA@mail.gmail.com>

On 25 August 2015 at 11:10, Florian Bruhin <me at the-compiler.org> wrote:
> * Floris Bruynooghe <flub at devork.be> [2015-08-25 09:45:31 +0100]:
>> Hello,
>>
>> On 9 August 2015 at 23:45, Bruno Oliveira <nicoddemus at gmail.com> wrote:
>> > Hi,
>> >
>> > I also think we should release 2.8 directly.
>>
>> Yes, a release which supports python 3.5 would be nice.  AFAIK we
>> could just release 2.7.3 without any work so if someone wants to
>> release that I think you should just do it.
>
> The Python 3.5 PR[1] was merged to master - it'd need to be backported
> to the pytest-2.7 branch first, right?

Bruno backported it to the pytest-2.7 branch.


> Most of them are merged in the meantime:
> https://github.com/pytest-dev/pytest/pulls
>
> There are only 4 open:

And two of those I'm supposed to be looking into :-(  sorry.

From flub at devork.be  Tue Aug 25 15:10:34 2015
From: flub at devork.be (Floris Bruynooghe)
Date: Tue, 25 Aug 2015 14:10:34 +0100
Subject: [pytest-dev] Releases
In-Reply-To: <CA+RQFff1rjrNfPonGFiYZi--LFiDPRgKu9=DAQ-ENjp5usPjfw@mail.gmail.com>
References: <20150809215509.GA14835@tonks>
 <CA+RQFfczRoZp14A6Z4Asg2LQj5UX=enK014x3j=8dLcoQwvEvg@mail.gmail.com>
 <CAAWk_DxkAF76s9c1nMsk-DP7shUxBRY97=68_BWZPu6U-+SJZw@mail.gmail.com>
 <20150825101000.GK509@tonks>
 <CA+RQFff1rjrNfPonGFiYZi--LFiDPRgKu9=DAQ-ENjp5usPjfw@mail.gmail.com>
Message-ID: <CAAWk_Dwz1s6eOQ7t-+M=4mFpsk2HV=YRksJ=tFWnayDvNh79MQ@mail.gmail.com>

On 25 August 2015 at 12:58, Bruno Oliveira <nicoddemus at gmail.com> wrote:
>
>> * Floris Bruynooghe <flub at devork.be> [2015-08-25 09:45:31 +0100]:
>> This on the other hand is more of a blocker.  I think what we need is
>> some code in setup.py which automatically fetches the required pluggy
>> version from pypi and vendors it when  making sdists and wheels.
>
> Any reason to pinpoint that at release time only? I think it is desirable to
> be able to pinpoint this during development as well.

Version numbers are not a problem, pluggy uses semantic versioning so
if it breaks the API the versioned dependency (>=0.3.0,<0.4.0) in
setup.py will do this just fine for us during development.  The reason
to vendor pluggy is so that when another project uses pluggy, it could
depend on say 0.4.X while py.test was still on 0.3.X and then this
other project would not be able to use py.test for it's tests because
the library would conflict.  This is why I suggest the bundeling
should only happen in the sdist/wheel.

> As I understand it, vendoring means that we will have a copy of pluggy's
> code into pytest under a different package name (say,
> "_pytest.vendor.pluggy").

yes

> How about:
>
> * Create a script which fetches the latest pluggy version, and installs it
> into `_pytest.vendor.pluggy`;
> * Add `_pytest.vendor.pluggy` to version control
> * Update all references in pytest from `pluggy` to `_pytest.vendor.pluggy`;
> * Remove the dependency from `setup.py`;

Because of what I mentioned above I don't think pluggy should be
checked into py.test's repo.  Only when creating the sdist or wheel do
we want to download the file, install it into _pytest/pluggy.py (or
wherever) and make sure setuptools packages it.  It's probably best to
keep the vendored pluggy.py in .gitignore as well.  For extra bonus
points having a custom setup.py install option which excludes the
vendored pluggy so distributors like Debian can be kept happy.

This way the vendoring will never be out of date.  Running tests using
tox will use the vendored pluggy, while running test in a dev venv
with `pip install -e .` of py.test will not use the vendored pluggy.

From flub at devork.be  Tue Aug 25 17:34:40 2015
From: flub at devork.be (Floris Bruynooghe)
Date: Tue, 25 Aug 2015 16:34:40 +0100
Subject: [pytest-dev] Releases
In-Reply-To: <CAAWk_Dwz1s6eOQ7t-+M=4mFpsk2HV=YRksJ=tFWnayDvNh79MQ@mail.gmail.com>
References: <20150809215509.GA14835@tonks>
 <CA+RQFfczRoZp14A6Z4Asg2LQj5UX=enK014x3j=8dLcoQwvEvg@mail.gmail.com>
 <CAAWk_DxkAF76s9c1nMsk-DP7shUxBRY97=68_BWZPu6U-+SJZw@mail.gmail.com>
 <20150825101000.GK509@tonks>
 <CA+RQFff1rjrNfPonGFiYZi--LFiDPRgKu9=DAQ-ENjp5usPjfw@mail.gmail.com>
 <CAAWk_Dwz1s6eOQ7t-+M=4mFpsk2HV=YRksJ=tFWnayDvNh79MQ@mail.gmail.com>
Message-ID: <CAAWk_DxD0sNKaNe53bFWxtuVOW1Or_0PrUQW+C-e0A_-s05JWQ@mail.gmail.com>

On 25 August 2015 at 14:10, Floris Bruynooghe <flub at devork.be> wrote:
> On 25 August 2015 at 12:58, Bruno Oliveira <nicoddemus at gmail.com> wrote:

>> How about:
>>
>> * Create a script which fetches the latest pluggy version, and installs it
>> into `_pytest.vendor.pluggy`;
>> * Add `_pytest.vendor.pluggy` to version control
>> * Update all references in pytest from `pluggy` to `_pytest.vendor.pluggy`;
>> * Remove the dependency from `setup.py`;

Actually your proposal is much easier to implement and the only real
downside is that distributions will have a harder time un-bundling it.
Not sure how big a deal that is.  But this approach is fine to me, it
would still allow for an optional bunch of setup.py trickery to skip
installing the vendored pluggy later if needed.


Regards,
Floris

From nicoddemus at gmail.com  Tue Aug 25 17:53:54 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 25 Aug 2015 15:53:54 +0000
Subject: [pytest-dev] Releases
In-Reply-To: <CAAWk_DxD0sNKaNe53bFWxtuVOW1Or_0PrUQW+C-e0A_-s05JWQ@mail.gmail.com>
References: <20150809215509.GA14835@tonks>
 <CA+RQFfczRoZp14A6Z4Asg2LQj5UX=enK014x3j=8dLcoQwvEvg@mail.gmail.com>
 <CAAWk_DxkAF76s9c1nMsk-DP7shUxBRY97=68_BWZPu6U-+SJZw@mail.gmail.com>
 <20150825101000.GK509@tonks>
 <CA+RQFff1rjrNfPonGFiYZi--LFiDPRgKu9=DAQ-ENjp5usPjfw@mail.gmail.com>
 <CAAWk_Dwz1s6eOQ7t-+M=4mFpsk2HV=YRksJ=tFWnayDvNh79MQ@mail.gmail.com>
 <CAAWk_DxD0sNKaNe53bFWxtuVOW1Or_0PrUQW+C-e0A_-s05JWQ@mail.gmail.com>
Message-ID: <CA+RQFffcmFtZSh5OhGprLg0h8xSYrqEh=h-DyWieZVrqPTfeBA@mail.gmail.com>

On Tue, Aug 25, 2015 at 12:34 PM Floris Bruynooghe <flub at devork.be> wrote:

> On 25 August 2015 at 14:10, Floris Bruynooghe <flub at devork.be> wrote:
> > On 25 August 2015 at 12:58, Bruno Oliveira <nicoddemus at gmail.com> wrote:
>
> >> How about:
> >>
> >> * Create a script which fetches the latest pluggy version, and installs
> it
> >> into `_pytest.vendor.pluggy`;
> >> * Add `_pytest.vendor.pluggy` to version control
> >> * Update all references in pytest from `pluggy` to
> `_pytest.vendor.pluggy`;
> >> * Remove the dependency from `setup.py`;
>
> Actually your proposal is much easier to implement and the only real
> downside is that distributions will have a harder time un-bundling it.
> Not sure how big a deal that is.  But this approach is fine to me, it
> would still allow for an optional bunch of setup.py trickery to skip
> installing the vendored pluggy later if needed.
>

I agree. :)

I just realized that `pip install` supports a `--target` parameter, so it
is even simpler. If nobody disagrees, I will work on this then:

* Create `_pytest.vendor`;
* Execute `pip install pluggy --target-dir=_pytest/vendor`;
* Add a README to _pytest.vendor explaining things (or to
vendor.__init__.py);
* Update imports
* Remove pluggy as a dependency.

I think this is simple to implement and will fit our needs nicely.

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

From nicoddemus at gmail.com  Wed Aug 26 01:19:07 2015
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 25 Aug 2015 23:19:07 +0000
Subject: [pytest-dev] Releases
In-Reply-To: <CA+RQFffcmFtZSh5OhGprLg0h8xSYrqEh=h-DyWieZVrqPTfeBA@mail.gmail.com>
References: <20150809215509.GA14835@tonks>
 <CA+RQFfczRoZp14A6Z4Asg2LQj5UX=enK014x3j=8dLcoQwvEvg@mail.gmail.com>
 <CAAWk_DxkAF76s9c1nMsk-DP7shUxBRY97=68_BWZPu6U-+SJZw@mail.gmail.com>
 <20150825101000.GK509@tonks>
 <CA+RQFff1rjrNfPonGFiYZi--LFiDPRgKu9=DAQ-ENjp5usPjfw@mail.gmail.com>
 <CAAWk_Dwz1s6eOQ7t-+M=4mFpsk2HV=YRksJ=tFWnayDvNh79MQ@mail.gmail.com>
 <CAAWk_DxD0sNKaNe53bFWxtuVOW1Or_0PrUQW+C-e0A_-s05JWQ@mail.gmail.com>
 <CA+RQFffcmFtZSh5OhGprLg0h8xSYrqEh=h-DyWieZVrqPTfeBA@mail.gmail.com>
Message-ID: <CA+RQFffkCtW3LS-vo9jQ4ju+FOewHr1bp6MBpXR1+k2q79uXEQ@mail.gmail.com>

Done: https://github.com/pytest-dev/pytest/pull/959

Comments are welcome!

Cheers,
Bruno.

On Tue, Aug 25, 2015 at 12:53 PM Bruno Oliveira <nicoddemus at gmail.com>
wrote:

> On Tue, Aug 25, 2015 at 12:34 PM Floris Bruynooghe <flub at devork.be> wrote:
>
>> On 25 August 2015 at 14:10, Floris Bruynooghe <flub at devork.be> wrote:
>> > On 25 August 2015 at 12:58, Bruno Oliveira <nicoddemus at gmail.com>
>> wrote:
>>
>> >> How about:
>> >>
>> >> * Create a script which fetches the latest pluggy version, and
>> installs it
>> >> into `_pytest.vendor.pluggy`;
>> >> * Add `_pytest.vendor.pluggy` to version control
>> >> * Update all references in pytest from `pluggy` to
>> `_pytest.vendor.pluggy`;
>> >> * Remove the dependency from `setup.py`;
>>
>> Actually your proposal is much easier to implement and the only real
>> downside is that distributions will have a harder time un-bundling it.
>> Not sure how big a deal that is.  But this approach is fine to me, it
>> would still allow for an optional bunch of setup.py trickery to skip
>> installing the vendored pluggy later if needed.
>>
>
> I agree. :)
>
> I just realized that `pip install` supports a `--target` parameter, so it
> is even simpler. If nobody disagrees, I will work on this then:
>
> * Create `_pytest.vendor`;
> * Execute `pip install pluggy --target-dir=_pytest/vendor`;
> * Add a README to _pytest.vendor explaining things (or to
> vendor.__init__.py);
> * Update imports
> * Remove pluggy as a dependency.
>
> I think this is simple to implement and will fit our needs nicely.
>
> Cheers,
> Bruno.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150825/e1863c42/attachment-0001.html>

From me at the-compiler.org  Wed Aug 26 10:43:40 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Wed, 26 Aug 2015 10:43:40 +0200
Subject: [pytest-dev] Vendoring pluggy with pytest
Message-ID: <20150826084340.GB509@tonks>

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?

Florian

[1] http://www.pytest.org/
[2] https://github.com/hpk42/pluggy

-- 
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/20150826/182a1dbb/attachment.sig>

From wosc at wosc.de  Thu Aug 13 16:47:21 2015
From: wosc at wosc.de (Wolfgang Schnerring)
Date: Thu, 13 Aug 2015 14:47:21 -0000
Subject: [pytest-dev] Could we get a pytest-timeout release?
Message-ID: <loom.20150813T164442-190@post.gmane.org>

Hi,

the PR https://bitbucket.org/flub/pytest-timeout/pull-requests/3
has been merged on 2014-09-23, so... any chance this could be released?
I'm eagerly awaiting this, and curse each time the timeout kills my pdb
session...

Thanks,
Wolfgang