Mailman 3 May 2019 - pytest-dev

enhancing the assertion rewriting experience with custom integration/workflows
by Ronny Pfannschmidt July 29, 2019

July 29, 2019

Hi everyone, at a project at work which integrates pytest we did build a custom workflow around invoking tests and pytest. This in turn triggers a lot of warnings from the assertion rewriter about things that have been already imported. at first glance fixing this seems rather problematic, as the configuration of the assertion rewriting is deeply bound to the pytest configuration and it seems we cant do something simple and crude like letting a pth file fix the issue. i believe opening up the hooking system could be best done by moving it to a package with some sort of singleton control anyway - then pytest would be just a consumer of that api enabling if not enabled and push in its own "import roots". i'd like ot hear other impressions and ideas on this as well. -- Ronny

2 2

[core] Tidelift Funding
by Bruno Oliveira May 23, 2019

May 23, 2019

Hi core maintainers, Half a year ago Keenan Szulik from Tidelift reached me and Holger about the possibility of pytest joining Tidelift for funding. At first our answer was "not right now" for two reasons: we didn't actually knew the platform (for example what expect in terms of obligations) and how to split the funding among maintainers. Some time later Keenan reached us again to see if we had thought about the idea some more. I reached some other OS maintainers which have joined Tidelift and the overall response was positive: they were getting paid and there were no obligations whatsoever after joining the platform other than "maintain the project", which they were already doing anyway. There's no obligation to market the platform in anyway as well (say, being forced to put their logo on the website). Here's a nice discussion of the Pillow maintainers about how to split the funding: https://github.com/python-pillow/Pillow/issues/3469. I decided then to join Tidelift with pytest-mock: it is a small project and I'm the sole maintainer, so it seemed like a good choice to beta test the platform. After two months, the overall experience is positive: I didn't get any demands from Tidelift other than the occasional email (twice a month) about how the project is doing in terms of Tidelift subscribers, and I've been paid twice know without fuss. So I think the overall experience is positive. So my question is: how do the core maintainers feel about pytest joining Tidelift? Here's their license agreement: https://tidelift.com/docs/lifting/agreement If we are to join, there's the question about how to split the funds over the core maintainers. I propose we follow how other projects are handling it: * The amount is split evenly between active maintainers. By "active maintainer" here I mean that has been participating in discussions and/or contributing PRs "lately". I think every core maintainer is reasonable regarding being active or not, so I don't expect misunderstandings here. * If an inactive maintainer becomes active again, they will start to get their share on the next payment (by the end of every month as per Tidelift policy). Same if an active maintainer stops activity. With the above guidelines, I would say the current "active" core maintainers are Daniel, Anthony and myself, with Ronny joining back soon. The amount involved is not much, but it is an extra which is nice to have for (what I can see) work we are already doing anyway. It is also possible to cancel the subscription for any time given 30 days notice. Thoughts? Cheers, Bruno.

6 15

Other plugin breaking usage of pytest-cache
by Elijah DeLee May 17, 2019

May 17, 2019

Reference issue: https://github.com/ansible/pytest-mp/issues/18 tl;dr Using the pytest-mp plugin breaks the collection/recording of failed tests in the lastfailed cache. I'm having trouble knowing where to start looking. Can anyone give me a clue at what point the tests get recorded into the cache? Thanks! Elijah DeLee ------------------ Quality Engineer Red Hat

2 2

Using pytest_assertrepr_compare() for marked tests only?
by Shawn Brown May 16, 2019

May 16, 2019

I'm playing with the idea of returning a custom explanation for tests with a particular marker but returning Pytest's standard explanation for tests without the marker. I was hoping to do something like this... # content of conftest.py def pytest_assertrepr_compare(config, op, left, right): if <current test uses "mymark">: return ['My custom explanation!'] # content of test_mystuff.py import pytest def test_mystuff1(): assert 100 == 105 @pytest.mark.mymark def test_mystuff2(): assert 100 == 105 # Desired Output __________ test_mystuff1 __________ def test_mystuff1(): > assert 100 == 105 E assert 100 == 105 E -100 E +105 test_mystuff.py:4: AssertionError __________ test_mystuff2 __________ @pytest.mark.mymark def test_mystuff2(): > assert 100 == 105 E assert My custom explanation! test_mystuff.py:8: AssertionError I've looked through the plugin API but I don't see a straightforward way of doing this. I was hoping I could get a reference to the current test through the config (even if it was a convoluted reference) but I don't know if this is possible. Digging deeper, I see some undesirable approaches I could probably use to accomplish this (e.g., monkey-patch util._reprcompare or possibly maintain a plugin-level global that points to the current test) but nothing that seems to work with the grain of the plugin API. So I have a few related questions I'm hoping someone can help me with: Q: Is there a way to reference the current test from within pytest_assertrepr_compare()? Q: If not, is there a decent way to implement something like this that isn't too hacky?

3 3

pytest 4.5
by Bruno Oliveira May 12, 2019

May 12, 2019

The pytest team is proud to announce the 4.5.0 release! pytest is a mature Python testing tool with more than a 2000 tests against itself, passing on many different interpreters and platforms. This release contains a number of bugs fixes and improvements, so users are encouraged to take a look at the CHANGELOG: https://docs.pytest.org/en/latest/changelog.html For complete documentation, please visit: https://docs.pytest.org/en/latest/ As usual, you can upgrade from pypi via: pip install -U pytest Thanks to all who contributed to this release, among them: * Anthony Sottile * Bruno Oliveira * Daniel Hahler * Floris Bruynooghe * Pulkit Goyal * Samuel Searles-Bryant * Zac Hatfield-Dodds Happy testing, The Pytest Development Team

1 0

pytest 4.4.2
by Bruno Oliveira May 8, 2019

May 8, 2019

pytest 4.4.2 has just been released to PyPI. This is a bug-fix release, being a drop-in replacement. To upgrade:: pip install --upgrade pytest The full changelog is available at https://docs.pytest.org/en/latest/changelog.html. Thanks to all who contributed to this release, among them: * Allan Lewis * Anthony Sottile * Bruno Oliveira * DamianSkrzypczak * Daniel Hahler * Don Kirkby * Douglas Thor * Hugo * Ilya Konstantinov * Jon Dufresne * Matt Cooper * Nikolay Kondratyev * Ondřej Súkup * Peter Schutt * Romain Chossart * Sitaktif Happy testing, The pytest Development Team

1 0

Keeping failing test ids for git bisect
by Florian Schulze May 4, 2019

May 4, 2019

Hi! Is there a way to run a bunch of tests like with --lf but don't clear the cache when they pass? This would be mighty helpful for git bisect. For now I helped myself by copying the test ids, but that requires editing the list copied from the terminal before being able to paste them to the command line. Regards, Florian Schulze

4 5

Re: [pytest-dev] [core] Tidelift Funding
by Anthony Sottile May 3, 2019

May 3, 2019

> Hi Floris, > > On Thu, May 2, 2019 at 2:25 PM Floris Bruynooghe <flub(a)devork.be> wrote: > > > Why the rules about active? Seems complicated and more open to > > arguing. I liked the Pillow guidelines you linked: > > https://github.com/orgs/pytest-dev/teams/contributors can express > > interest and https://github.com/orgs/pytest-dev/teams/core decides on > > split (which I guess can be anything from 0% to 100%). With the same > > assumption that the core members are reasonable that should end up as > > roughly the same. > > > > Mind you in practice I have no issue with the above proposal of people > > right now, but would also not mind if e.g. hpk or ronny wanted to be > > part right now (I'll pass myself). Likewise there are probably cases > > where I wouldn't mind people not in core being paid for some time. > > > > I wrote those "rules" just to come up with a solid proposal in the e-mail, > but I do like yours better. Letting developers opt-in to a share is fair > and reasonable, certainly. > > I think we should even always split the funding evenly between those opting > to receive it, to further avoid any arguing on that. > > But in general I'm +1, let's make it happen if there's anyone interested > > in getting paid. > > > > Great, let's see what others think. > > Cheers, > Bruno. I think TideLift seems like a good step in the right direction -- also agree on the "active" bit being the most difficult to resolve here -- where possible let's adhere to the simplest-as-possible here -- I like the opt-in approach proposed above :thumbsup: Anthony

1 0

pytest slack reporting plugin proposal
by Arseniy Antonov May 2, 2019

May 2, 2019

Hello, I've developed a plugin for sending pytest results to the slack. I suppose it may be a useful tool for the pytest community, so I want to contribute it to the pytest-dev. Please review: https://github.com/ArseniyAntonov/pytest-slack -- -------------------------- Regards. Arseny Antonov

5 11

Re: [pytest-dev] [core] Tidelift Funding
by nicoddemus＠gmail.com May 2, 2019

May 2, 2019

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > Only thought from my side — please, just make sure there's "way back", in case reality will not match your expectations. Indeed that's a very important aspect, here's the section of the agreement[1] regarding that: - --- 6.2 How and when can this agreement be terminated? Either party may terminate this agreement (i) with 30 or more days notice, for any or no reason; or (ii) immediately, if the other party materially defaults in the performance of any of its obligations hereunder, and such default is not corrected within 10 business days of notice of the default. Material defaults may include non-completion of tasks set out in the Tidelift application, violations of the Lifter Code of Conduct, attempts to manipulate or game systems (including either those created by Tidelift or by host open source projects), or any other conduct that could damage the reputation or business of Tidelift or other Lifters. - --- I don't have much legalese experience, but this seems to be reasonable. [1]: https://tidelift.com/docs/lifting/agreement -----BEGIN PGP SIGNATURE----- Version: FlowCrypt 6.7.7 Gmail Encryption Comment: Seamlessly send and receive encrypted email wsFcBAEBCgAGBQJcytJzAAoJEAcNJkopMu2+GLAP/Rt4SKR9kStlM6v8LWGx BJssTmCT7k/0xqCfHBCjooe6btV+RyXG/1ZZPkKTaK2dEA2XyXRi7bG22utu lqXXtTZg0JHc7b+FXwH0ZySNklkQWwIph8I2nWoa209XJ77LVEqtRvmgW74I 5KeS2Yhr0Jo8CRyKJgdcX4eR5v7g1duyQUB1IYnu0lZXSzJTAWUH043ubjI/ G2XqyHC8S9GJqBvQrFv2ObzT5Y4GPiMDlTOhkbbnpFUQpZi8Zy+UfiHTGoi3 wBXWyuKbi2ABs8prEh9269AGMqoW+eXshto0E/arqC2zSb/btTef1fBjUunM Fu0cqOtsiaz/Q0OwwxLuiep1c5ikaJ4qfnmaizncoQhS/DdVsiqIZ7p6SiMA bSNH4jxPO4LwvE6YvYOjsLJrk/yjnfoC44wydF2Y2Qv6B6GHoyPhRdLOWYnj PtGk6VQEl88d9wXPfZWxjzW1lvCaGwWjrfjRYS7Yhlkdo52B73Gee1bhu6/H a/8sRAwpS386l6lwVpQW6FPrhbpm/XYDR5GqGW/rzATxky4GCzgjsVddKmqh xJHONQJbQxaaT43OurfY1ly8+XFUxarQ4u9kk9htW241dMzZeiiGOuprrBbE 1NsrQPzXie8tfp/X8++LlYOlvSG2u+8xUa7ochrvpvVNnBBa46QYARHX+Vnp 4ZUi =xHKg -----END PGP SIGNATURE-----

1 0