From tagrain at gmail.com Wed Jul 1 06:49:13 2020 From: tagrain at gmail.com (Thomas Grainger) Date: Wed, 1 Jul 2020 11:49:13 +0100 Subject: [pytest-dev] hardcode 4.x mid-2020 EOL Message-ID: By most calculations mid-2020 has now passed, I propose hardcoding mid-2020 to some date in the (very) near future, eg 2020-08-01 Thomas Grainger From nicoddemus at gmail.com Sat Jul 4 09:01:25 2020 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Sat, 4 Jul 2020 10:01:25 -0300 Subject: [pytest-dev] hardcode 4.x mid-2020 EOL In-Reply-To: References: Message-ID: Hi Thomas, Thanks for bringing this up! Hardcoding the date for 4.6 EOL is something we should discuss. So far we have had a few releases since the beginning of the year: January, May and June, with contributions from the community. Given our overhead is relatively small (review merge a PR and make the release), and if a user is going through the trouble of contributing a fix it probably means it blocks/bother them enough to care to make a PR, I personally don't mind extending our commitment of making new 4.6 releases contributions until the end of the year, and stating that officially. I would like to hear what others think about this though. Cheers, On Wed, Jul 1, 2020 at 7:49 AM Thomas Grainger wrote: > By most calculations mid-2020 has now passed, > > I propose hardcoding mid-2020 to some date in the (very) near future, > eg 2020-08-01 > > Thomas Grainger > _______________________________________________ > 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: From opensource at ronnypfannschmidt.de Sat Jul 4 14:23:49 2020 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Sat, 4 Jul 2020 20:23:49 +0200 Subject: [pytest-dev] hardcode 4.x mid-2020 EOL In-Reply-To: References: Message-ID: Hi Bruno, Thomas, given that thanks to the release automation work Bruno and the others did put in, the effort for doing releases after community contributions is very sustainable. I believe its fair to leave it open for until there was about a full year without a new contribution/release. Should the automation eventually change an the cost for doing the releases changes, it seems fair to drop the offer at that point. We should however put it into very clear writing that any backporting/bugfixing is up to the python2+pytest using community, pytest-core will not handle any of that on volunteer time. -- Ronny Am 04.07.20 um 15:01 schrieb Bruno Oliveira: > Hi Thomas, > > Thanks for bringing this up! Hardcoding the date for 4.6 EOL is > something we should discuss. > > So far we have had a few releases since the beginning of the year: > January, May and June, with contributions from the community. > > Given our overhead is relatively small (review merge a PR and make the > release), and if a user is going through the trouble of contributing a > fix it probably means it blocks/bother them enough to care to make a > PR, I personally don't mind extending our commitment of making new 4.6 > releases contributions until the end of the year, and stating that > officially. > > I would like to hear what others think about this though. > > Cheers, > > > > On Wed, Jul 1, 2020 at 7:49 AM Thomas Grainger > wrote: > > By most calculations mid-2020 has now passed, > > I propose hardcoding mid-2020 to some date in the (very) near future, > eg 2020-08-01 > > Thomas Grainger > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.marie at se.com Thu Jul 9 06:33:54 2020 From: sylvain.marie at se.com (Sylvain MARIE) Date: Thu, 9 Jul 2020 10:33:54 +0000 Subject: [pytest-dev] pytest-cases 2.0.0 is out ! Message-ID: Dear pytest-dev members, I am very pleased today to announce that pytest-cases 2.0.0 is finally out ! https://smarie.github.io/python-pytest-cases/ It took me quite some time to work on simplifying the API and improving the internal pytest extension engine (in particular the fixture unions, fixture references, and lazy parameter values), but I think that the result is really worth the wait. I still need to produce some documentation page about the theory of fixture unions and how this modifies parametrization and fixture closures, but the rest of the documentation has been fully updated with readable examples and should be self-sufficient. I hope that the result will look ?pytest-y? to you, at least I made my best so that the user experience is as close as pytest as possible! Do not hesitate to share with me any feedback of suggestion that you would have, on the issues page. Kind regards Sylvain _____________________________________________________________________________________ > Quick discussion about this email ? I'm available for Chat on Skype or Teams, or call me at the number below Sylvain MARIE Research Engineer - Analytics & Cloud Platforms EDISON Senior Group Expert [cid:image001.gif at 01D655ED.32C01EB0] [cid:image002.jpg at 01D655ED.32C01EB0] *Please consider the environment before printing this e-mail [FB] [FB] [FB] [FB] [FB] [FB] [FB] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 1265 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 33304 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 1027 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 1490 bytes Desc: image004.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 1485 bytes Desc: image005.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.png Type: image/png Size: 1530 bytes Desc: image006.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.png Type: image/png Size: 2316 bytes Desc: image007.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image008.png Type: image/png Size: 1713 bytes Desc: image008.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image009.png Type: image/png Size: 1512 bytes Desc: image009.png URL: From nicoddemus at gmail.com Thu Jul 9 20:34:39 2020 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Thu, 9 Jul 2020 21:34:39 -0300 Subject: [pytest-dev] pytest 6.0.0rc1 released Message-ID: pytest 6.0.0rc1 has just been released to PyPI. This is a prerelease to help identify any issues before the final 6.0.0. Please use this version to run your test suite and report any problems! To upgrade: pip install --upgrade --pre 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: * Alfredo Deza * Andreas Maier * Andrew * Anthony Sottile * ArtyomKaltovich * Bruno Oliveira * Claire Cecil * Curt J. Sampson * Daniel * Daniel Hahler * Danny Sepler * David Diaz Barquero * Fabio Zadrozny * Felix Nieuwenhuizen * Florian Bruhin * Florian Dahlitz * Gleb Nikonorov * Hugo van Kemenade * Hunter Richards * Katarzyna Kr?l * Katrin Leinweber * Keri Volans * Lewis Belcher * Lukas Geiger * Martin Michlmayr * Mattwmaster58 * Maximilian Cosmo Sitter * Nikolay Kondratyev * Pavel Karateev * Pawe? Wilczy?ski * Prashant Anand * Ram Rachum * Ran Benita * Ronny Pfannschmidt * Ruaridh Williamson * Simon K * Tim Hoffmann * Tor Colvin * Vlad-Radz * Xinbin Huang * Zac Hatfield-Dodds * earonesty * gaurav dhameeja * gdhameeja * ibriquem * mcsitter * piotrhm * smarie * symonk * xuiqzy Happy testing, The pytest Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From florian.schulze at gmx.net Fri Jul 10 03:28:58 2020 From: florian.schulze at gmx.net (Florian Schulze) Date: Fri, 10 Jul 2020 09:28:58 +0200 Subject: [pytest-dev] pytest 6.0.0rc1 released In-Reply-To: References: Message-ID: <9E74AE05-8354-4F18-B875-E94F754955E4@gmx.net> Hi! I'm happy to report that it seems to work fine with devpi on Travis. Locally I have hanging tests which I'm still investigating. While doing that I noticed that in the stackstrace produced by --full-trace the filepath and linenumber comes after the other info, which threw me off at first. Is that a bug? Also is it possible to get a native stack trace for that? --tb=native has no effect on --full-trace. Regards, Florian Schulze From guillermor at fing.edu.uy Sat Jul 18 21:53:14 2020 From: guillermor at fing.edu.uy (Guillermo Rodriguez) Date: Sat, 18 Jul 2020 22:53:14 -0300 Subject: [pytest-dev] pytest-vnet: new plugin for running mininet tests Message-ID: <44d9ff8f-1e74-1fae-97d3-6e5f2f64aad1@fing.edu.uy> Hello all New to the list!, recently needed to run some python code using mininet to test some python p2p applications: http://mininet.org/ https://github.com/mininet/mininet/blob/master/examples/emptynet.py From the home page: "Mininet creates a realistic virtual network, running real kernel, switch and application code, on a single machine (VM, cloud or native), in seconds". The real need was a way to run my test suite and have the tests that use mininet run in the VM and report the results back to the host pytest session. https://github.com/guilledk/pytest-vnet Right now the tests must be fully self contained (include their imports), as the system works by dynamically creating python scripts inside a docker container, running them and catching exceptions. Moving forward error logging improvements will be prioritized (right now a generic AssertionError with the captured traceback is shown but line numbers are all messed up), also sliming down the base docker image. Any feedback appreciated Guillermo Rodriguez From opensource at ronnypfannschmidt.de Tue Jul 21 17:00:03 2020 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Tue, 21 Jul 2020 23:00:03 +0200 Subject: [pytest-dev] my limited/reduced availability until at least mid-september/october Message-ID: Hi everyone, i just wanted to inform everyone, that due to corona and my specific family situation, we are still in a mitigation situation. This is one of the key factors of my reduced engagement with pytest and the community. By September we will move into into a new flat and get daycare for the toddler again. Once we are settled after that and had some time to relax+reorient i'll pick up more pytest joy again. Regards and stay healthy Ronny From nicoddemus at gmail.com Tue Jul 21 17:11:33 2020 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Tue, 21 Jul 2020 18:11:33 -0300 Subject: [pytest-dev] my limited/reduced availability until at least mid-september/october In-Reply-To: References: Message-ID: Hi Ronny, Thanks for the heads up! Please make sure to take the time you need to care for your family, we are always grateful for all the work you do in pytest + the ecosystem. Cheers, Bruno On Tue, Jul 21, 2020 at 6:07 PM Ronny Pfannschmidt < opensource at ronnypfannschmidt.de> wrote: > Hi everyone, > > i just wanted to inform everyone, that due to corona and my specific > family situation, > we are still in a mitigation situation. > > This is one of the key factors of my reduced engagement with pytest and > the community. > > By September we will move into into a new flat and get daycare for the > toddler again. > Once we are settled after that and had some time to relax+reorient i'll > pick up more pytest joy again. > > Regards and stay healthy > Ronny > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Tue Jul 28 16:11:04 2020 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Tue, 28 Jul 2020 17:11:04 -0300 Subject: [pytest-dev] pytest 6.0.0 released! Message-ID: The pytest team is proud to announce the 6.0.0 release! pytest is a mature Python testing tool with more than 2000 tests against itself, passing on many different interpreters and platforms. This release contains a bunch of new goodies such as typing annotations, pyproject.toml, new hooks, and new command-line flags. CHANGELOG: https://docs.pytest.org/en/stable/changelog.html For complete documentation, please visit: https://docs.pytest.org/en/stable/ As usual, you can upgrade from PyPI via: pip install -U pytest Thanks to all users who have tested the 6.0.0rc1 release, it really helped us out nail down a few problems before the final release. Also many thanks to all contributors, among them: * Alfredo Deza * Andreas Maier * Andrew * Anthony Sottile * ArtyomKaltovich * Arvin Firouzi * Bruno Oliveira * Claire Cecil * Curt J. Sampson * Daniel * Daniel Hahler * Danny Sepler * David Diaz Barquero * Debi Mishra * earonesty * Fabio Zadrozny * Felix Nieuwenhuizen * Florian Bruhin * Florian Dahlitz * Garrett Thomas * gaurav dhameeja * gdhameeja * Gleb Nikonorov * Hugo van Kemenade * Hunter Richards * ibriquem * Katarzyna Kr?l * Katrin Leinweber * Kelton Bassingthwaite * Keri Volans * Kostis Anagnostopoulos * Lewis Belcher * Lewis Cowles * Lukas Geiger * Martin Michlmayr * Mattwmaster58 * Maximilian Cosmo Sitter * mcsitter * Miro Hron?ok * Nikolay Kondratyev * Pavel Karateev * Pawe? Wilczy?ski * piotrhm * Prashant Anand * Ram Rachum * Ran Benita * Ronny Pfannschmidt * Ruaridh Williamson * Simon K * smarie * symonk * Tim Hoffmann * Tor Colvin * Vlad-Radz * Xinbin Huang * xuiqzy * Zac Hatfield-Dodds Happy testing, The pytest Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssbarnea at redhat.com Wed Jul 29 05:43:21 2020 From: ssbarnea at redhat.com (Sorin Sbarnea) Date: Wed, 29 Jul 2020 10:43:21 +0100 Subject: [pytest-dev] maintenance of pytest-html Message-ID: <60F0E974-B679-4FC3-9060-27EF2400F73B@redhat.com> Apparently release 6.0.0 managed to uncover what I was afraid it would do: breaking not actively maintained plugins. It was a small issue, but enough to cause breakages and chain of dependency pinning for the users. There was nothing wrong with pytest release process, there was a pre-release and also enough time to raise bugs... only if someone would try that pre-release before the release was made. Experience told me that less than 1/1000 users will try it. Can someone help me bring pytest-html plugin to actively maintained status? https://github.com/pytest-dev/pytest-html/issues/318 For me actively maintained does means it has CI/CD jobs that run scheduled and that also tests unreleased versions of its main dependencies, in that case this means at least "pytest" (and likely ansi2html too). I used this approach with several projects in order to avoid day-zero outages when one dependency makes a new release. That issue also made me discover that there is a gap between the guidelines from https://github.com/pytest-dev/pytest/blob/master/CONTRIBUTING.rst#submitting-plugins-to-pytest-dev and the reality. An external contributor is not able to @mention a maintenance team (in fact no proofs that it even exists) so PRs may be lingering for a while or ever without knowing who could be able to help moving them. Only practical solution I found so far was to dig the commit history and make guesses who is likely to be a core, dig for his online contacts and hope he receives your call and happens to be available or willing to help. Sadly is a gambling most of us already do all the day and I am not sure how it can be improved. This should not be ignored because most occasional contributors are never going to try to contribute again if their initial work is not reviewed, making maintenance even harder. While I am trying to sort the pytest-html issue right now, I do have few more generic questions: How are users expected to contact those with power of making a change on any project under pytest-dev organization? Is this mailinglist the only option? I personally dislike mailing lists and avoid them. I find them as a communication barrier to occasional contributions. You can only post to them if you subscribe, no way to reply to a thread if you were not subscribed when original message was posted. Why not an online forum, where anyone can do a social login and post a message/reply or watch a specific topic he is interested in, without having to expose his email and subscribe to far more than he may want? Two easy alternatives are either Github discussions (beta opt-in, can provide details) or just using https://discuss.python.org/ -- where we could use a category or tag, which both can allow subscript, in addition to topic subscription. I do have a lot of admiration for pytest ecosystem in general and more than happy to help it grow. Cheers Sorin Sbarnea From jimbrannlund at fastmail.com Wed Jul 29 06:22:50 2020 From: jimbrannlund at fastmail.com (=?utf-8?Q?Jim_Br=C3=A4nnlund?=) Date: Wed, 29 Jul 2020 12:22:50 +0200 Subject: [pytest-dev] maintenance of pytest-html In-Reply-To: <60F0E974-B679-4FC3-9060-27EF2400F73B@redhat.com> References: <60F0E974-B679-4FC3-9060-27EF2400F73B@redhat.com> Message-ID: <37bc4244-6177-481b-ad17-94ac0b39c88b@Spark> I?m not sure Travis supports (or allows it for free tier) scheduled runs. But I do agree it would be the best way to at least mitigate the risk of zero-day bugs. On 29 Jul 2020, 11:44 +0200, Sorin Sbarnea , wrote: > Apparently release 6.0.0 managed to uncover what I was afraid it would do: breaking not actively maintained plugins. It was a small issue, but enough to cause breakages and chain of dependency pinning for the users. > > There was nothing wrong with pytest release process, there was a pre-release and also enough time to raise bugs... only if someone would try that pre-release before the release was made. Experience told me that less than 1/1000 users will try it. > > Can someone help me bring pytest-html plugin to actively maintained status? > https://github.com/pytest-dev/pytest-html/issues/318 > > > For me actively maintained does means it has CI/CD jobs that run scheduled and that also tests unreleased versions of its main dependencies, in that case this means at least "pytest" (and likely ansi2html too). I used this approach with several projects in order to avoid day-zero outages when one dependency makes a new release. > > That issue also made me discover that there is a gap between the guidelines from https://github.com/pytest-dev/pytest/blob/master/CONTRIBUTING.rst#submitting-plugins-to-pytest-dev and the reality. > > An external contributor is not able to @mention a maintenance team (in fact no proofs that it even exists) so PRs may be lingering for a while or ever without knowing who could be able to help moving them. Only practical solution I found so far was to dig the commit history and make guesses who is likely to be a core, dig for his online contacts and hope he receives your call and happens to be available or willing to help. > > Sadly is a gambling most of us already do all the day and I am not sure how it can be improved. This should not be ignored because most occasional contributors are never going to try to contribute again if their initial work is not reviewed, making maintenance even harder. > > > While I am trying to sort the pytest-html issue right now, I do have few more generic questions: > > How are users expected to contact those with power of making a change on any project under pytest-dev organization? > > Is this mailinglist the only option? > > I personally dislike mailing lists and avoid them. I find them as a communication barrier to occasional contributions. You can only post to them if you subscribe, no way to reply to a thread if you were not subscribed when original message was posted. > > Why not an online forum, where anyone can do a social login and post a message/reply or watch a specific topic he is interested in, without having to expose his email and subscribe to far more than he may want? Two easy alternatives are either Github discussions (beta opt-in, can provide details) or just using https://discuss.python.org/ -- where we could use a category or tag, which both can allow subscript, in addition to topic subscription. > > > I do have a lot of admiration for pytest ecosystem in general and more than happy to help it grow. > > Cheers > Sorin Sbarnea > > > > _______________________________________________ > 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: From tagrain at gmail.com Wed Jul 29 08:16:06 2020 From: tagrain at gmail.com (Thomas Grainger) Date: Wed, 29 Jul 2020 13:16:06 +0100 Subject: [pytest-dev] maintenance of pytest-html In-Reply-To: <37bc4244-6177-481b-ad17-94ac0b39c88b@Spark> References: <60F0E974-B679-4FC3-9060-27EF2400F73B@redhat.com> <37bc4244-6177-481b-ad17-94ac0b39c88b@Spark> Message-ID: We could add a script in each repo that takes the latest pytest version and updates the relevant config, then use asottile all-repos to run those scripts with any new versions On Wed, Jul 29, 2020, 11:23 Jim Br?nnlund wrote: > I?m not sure Travis supports (or allows it for free tier) scheduled runs. > > But I do agree it would be the best way to at least mitigate the risk of > zero-day bugs. > On 29 Jul 2020, 11:44 +0200, Sorin Sbarnea , wrote: > > Apparently release 6.0.0 managed to uncover what I was afraid it would do: > breaking not actively maintained plugins. It was a small issue, but enough > to cause breakages and chain of dependency pinning for the users. > > There was nothing wrong with pytest release process, there was a > pre-release and also enough time to raise bugs... only if someone would try > that pre-release before the release was made. Experience told me that less > than 1/1000 users will try it. > > Can someone help me bring pytest-html plugin to actively maintained status? > https://github.com/pytest-dev/pytest-html/issues/318 > > > For me actively maintained does means it has CI/CD jobs that run scheduled > and that also tests unreleased versions of its main dependencies, in that > case this means at least "pytest" (and likely ansi2html too). I used this > approach with several projects in order to avoid day-zero outages when one > dependency makes a new release. > > That issue also made me discover that there is a gap between the > guidelines from > https://github.com/pytest-dev/pytest/blob/master/CONTRIBUTING.rst#submitting-plugins-to-pytest-dev > and the reality. > > An external contributor is not able to @mention a maintenance team (in > fact no proofs that it even exists) so PRs may be lingering for a while or > ever without knowing who could be able to help moving them. Only practical > solution I found so far was to dig the commit history and make guesses who > is likely to be a core, dig for his online contacts and hope he receives > your call and happens to be available or willing to help. > > Sadly is a gambling most of us already do all the day and I am not sure > how it can be improved. This should not be ignored because most occasional > contributors are never going to try to contribute again if their initial > work is not reviewed, making maintenance even harder. > > > While I am trying to sort the pytest-html issue right now, I do have few > more generic questions: > > How are users expected to contact those with power of making a change on > any project under pytest-dev organization? > > Is this mailinglist the only option? > > I personally dislike mailing lists and avoid them. I find them as a > communication barrier to occasional contributions. You can only post to > them if you subscribe, no way to reply to a thread if you were not > subscribed when original message was posted. > > Why not an online forum, where anyone can do a social login and post a > message/reply or watch a specific topic he is interested in, without having > to expose his email and subscribe to far more than he may want? Two easy > alternatives are either Github discussions (beta opt-in, can provide > details) or just using https://discuss.python.org/ -- where we could use > a category or tag, which both can allow subscript, in addition to topic > subscription. > > > I do have a lot of admiration for pytest ecosystem in general and more > than happy to help it grow. > > Cheers > Sorin Sbarnea > > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Wed Jul 29 09:21:54 2020 From: me at the-compiler.org (Florian Bruhin) Date: Wed, 29 Jul 2020 15:21:54 +0200 Subject: [pytest-dev] maintenance of pytest-html In-Reply-To: <60F0E974-B679-4FC3-9060-27EF2400F73B@redhat.com> <37bc4244-6177-481b-ad17-94ac0b39c88b@Spark> Message-ID: <20200729132154.tu4kketyptjq3vr7@hooch.localdomain> Hey everyone, There are various things in this thread I want to answer to, so I'll just answer to three mails in one :) On Wed, Jul 29, 2020 at 10:43:21AM +0100, Sorin Sbarnea wrote: > There was nothing wrong with pytest release process, there was a pre-release > and also enough time to raise bugs... only if someone would try that > pre-release before the release was made. Experience told me that less than > 1/1000 users will try it. FWIW things aren't nearly as bad as you claim them to be. Just because not *all* issues were caught during the pre-release, that doesn't mean *none* were. Notably, Miro Hron?ok tested the RC against all Fedora packages using their infrastructure, but various other users also caught regressions, both in pytest itself and plugins. See e.g. https://github.com/pytest-dev/pytest/issues/7532 This allowed various regressions to be fixed before the release, as well as updated releases for various plugins (pytest-xdist, pytest-forked, ...) before shipping the release. Clearly, that was a success. Was it less than 1/1000 of all users? Probably, given that pytest probably has hundreds of thousands of users. Was it "nobody" like you claim? Definitely not. > An external contributor is not able to @mention a maintenance team (in fact > no proofs that it even exists) so PRs may be lingering for a while or ever > without knowing who could be able to help moving them. Only practical > solution I found so far was to dig the commit history and make guesses who is > likely to be a core, dig for his online contacts and hope he receives your > call and happens to be available or willing to help. Clearly the (former?) maintainer of that plugin did see your message: https://github.com/pytest-dev/pytest-html/issues/318 > How are users expected to contact those with power of making a change on any > project under pytest-dev organization? I'd say by opening an issue in the respective repository. > Is this mailinglist the only option? If the people maintaining that plugin don't respond, then I'd say this mailinglist is the right place. > Why not an online forum, where anyone can do a social login and post a > message/reply or watch a specific topic he is interested in, without having > to expose his email and subscribe to far more than he may want? Two easy > alternatives are either Github discussions (beta opt-in, can provide details) > or just using https://discuss.python.org/ -- where we could use a category or > tag, which both can allow subscript, in addition to topic subscription. -1 on further fragmenting people by having even more communication channels. That'll lead to the exact opposite of what you probably want, as you'll reach *less* core maintainers than via an already established and widely used channel. If you want to get in touch with people responsible for a given plugin, use the repository. If that doesn't work and you want more pytest maintainers to be aware of the problem (and perhaps find someone to jump in with maintaining it), then you *do* want to reach out to more people than just the ones who'd be subscribed to a given plugin, no? On Wed, Jul 29, 2020 at 12:22:50PM +0200, Jim Br?nnlund wrote: > I?m not sure Travis supports (or allows it for free tier) scheduled runs. It does (and so does GitHub Actions, FWIW). On Wed, Jul 29, 2020 at 01:16:06PM +0100, Thomas Grainger wrote: > We could add a script in each repo that takes the latest pytest version and > updates the relevant config, then use asottile all-repos to run those > scripts with any new versions Why? Something like a tox environment running against the latest pytest prerelease (or pytest master even) plus a scheduled build job should totally suffice, no? Florian -- me at the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org https://bruhin.software/ | https://github.com/sponsors/The-Compiler/ GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ssbarnea at redhat.com Wed Jul 29 09:56:02 2020 From: ssbarnea at redhat.com (Sorin Sbarnea) Date: Wed, 29 Jul 2020 14:56:02 +0100 Subject: [pytest-dev] maintenance of pytest-html In-Reply-To: <20200729132154.tu4kketyptjq3vr7@hooch.localdomain> References: <20200729132154.tu4kketyptjq3vr7@hooch.localdomain> Message-ID: Yes, I would call 6.0.0 a blazing success. I was expecting far more problems. > On 29 Jul 2020, at 14:21, Florian Bruhin wrote: > > FWIW things aren't nearly as bad as you claim them to be. Just because not > *all* issues were caught during the pre-release, that doesn't mean *none* were. I put users in two categories: consumers and contributors (power users, people raising bugs, PRs or plugin creators). It is almost guaranteed that those in first category fail to find time/interest to test pre-releases, most of them prefer to complain about that new release broke their jobs. Yep, I seen/hear it, tried to educate them (nothing specific to pytest). In the end if they failed to put a ceiling on pytest version is their fault. Still, it goes bit more complex when it comes to pytest plugins, which IMHO they must have CI/CD jobs testing pytest so they avoid conflicts. If they do not plan to support new versions they can do the ceiling pytest version (which I do not recommend). > -1 on further fragmenting people by having even more communication channels. > That'll lead to the exact opposite of what you probably want, as you'll reach > *less* core maintainers than via an already established and widely used > channel. I agree that fragmentation is bad. I hope that questioning if a classic mailing list is the best medium was not seen as something bad, especially as the newer mediums do not prevent mailing list mode usage. I already seen how much damage chat platform fragmentations can do, with projects where communities scattered across a dozen of platforms and never knowing which one is active. > On Wed, Jul 29, 2020 at 01:16:06PM +0100, Thomas Grainger wrote: > > Why? Something like a tox environment running against the latest pytest > prerelease (or pytest master even) plus a scheduled build job should totally > suffice, no? > Yes, it is very easy to schedule jobs and get emails when things get broken with almost any CI/CD system, including Travis. Testing pre-releases is also very easy to implement, here is an example that implement the "devel" testing idiom for pytest-html: https://github.com/pytest-dev/pytest-html/pull/320 I used this for very long time with projects that were notorious on breaking on new releases. It helped me prevent bugs in upstream and also gave me time to refactor the code in such way that it would not break with the new release. Cheers, Sorin From tagrain at gmail.com Wed Jul 29 09:59:24 2020 From: tagrain at gmail.com (Thomas Grainger) Date: Wed, 29 Jul 2020 14:59:24 +0100 Subject: [pytest-dev] maintenance of pytest-html In-Reply-To: References: <20200729132154.tu4kketyptjq3vr7@hooch.localdomain> Message-ID: > Why? Something like a tox environment running against the latest pytest > prerelease (or pytest master even) plus a scheduled build job should totally > suffice, no? -1 on depending on unpined deps in CI this causes the default branch to fail and blocks all contributions until it is resolved Creating a pr (in pyup.io) gives one point of discussion if a release fails and does not block any other prs Thomas Grainger On Wed, 29 Jul 2020 at 14:56, Sorin Sbarnea wrote: > > Yes, I would call 6.0.0 a blazing success. I was expecting far more problems. > > > On 29 Jul 2020, at 14:21, Florian Bruhin wrote: > > > > FWIW things aren't nearly as bad as you claim them to be. Just because not > > *all* issues were caught during the pre-release, that doesn't mean *none* were. > > I put users in two categories: consumers and contributors (power users, people > raising bugs, PRs or plugin creators). It is almost guaranteed that those in first > category fail to find time/interest to test pre-releases, most of them prefer to > complain about that new release broke their jobs. Yep, I seen/hear it, tried > to educate them (nothing specific to pytest). > > In the end if they failed to put a ceiling on pytest version is their fault. > > Still, it goes bit more complex when it comes to pytest plugins, which IMHO > they must have CI/CD jobs testing pytest so they avoid conflicts. If they do not > plan to support new versions they can do the ceiling pytest version (which I do not > recommend). > > > -1 on further fragmenting people by having even more communication channels. > > That'll lead to the exact opposite of what you probably want, as you'll reach > > *less* core maintainers than via an already established and widely used > > channel. > I agree that fragmentation is bad. I hope that questioning if a classic > mailing list is the best medium was not seen as something bad, especially as > the newer mediums do not prevent mailing list mode usage. > > I already seen how much damage chat platform fragmentations can do, with > projects where communities scattered across a dozen of platforms and never > knowing which one is active. > > > On Wed, Jul 29, 2020 at 01:16:06PM +0100, Thomas Grainger wrote: > > > > Why? Something like a tox environment running against the latest pytest > > prerelease (or pytest master even) plus a scheduled build job should totally > > suffice, no? > > > > Yes, it is very easy to schedule jobs and get emails when things get broken > with almost any CI/CD system, including Travis. > > Testing pre-releases is also very easy to implement, here is an example > that implement the "devel" testing idiom for pytest-html: > > https://github.com/pytest-dev/pytest-html/pull/320 > > I used this for very long time with projects that were notorious on breaking > on new releases. It helped me prevent bugs in upstream and also gave me > time to refactor the code in such way that it would not break with the new release. > > Cheers, > Sorin > From ssbarnea at redhat.com Wed Jul 29 10:04:52 2020 From: ssbarnea at redhat.com (Sorin Sbarnea) Date: Wed, 29 Jul 2020 15:04:52 +0100 Subject: [pytest-dev] maintenance of pytest-html In-Reply-To: References: <20200729132154.tu4kketyptjq3vr7@hooch.localdomain>

Message-ID: > On 29 Jul 2020, at 14:59, Thomas Grainger wrote: > >> Why? Something like a tox environment running against the latest pytest >> prerelease (or pytest master even) plus a scheduled build job should totally >> suffice, no? > > -1 on depending on unpined deps in CI this causes the default branch > to fail and blocks all contributions until it is resolved > Creating a pr (in pyup.io) gives one point of discussion if a release > fails and does not block any other prs > Thomas Grainger > We are talking about libraries here (pytest plugin) and we have different views. If you care to keep your "CI/CD" green at all cost, you pin everything and hide the fact that a newer version of a dependency does not work with your master code. If you care more about finding bugs with your CI/CD, you are likely wanting to test unpinned deps too. There is no perfect approach, each one has pros and cons. I personally prefer the 2nd, with the note that if the external incompatibility lingers unresolved for long, I switch the CI/CD job to non-voting (still running but not preventing merges). /sorin From me at the-compiler.org Wed Jul 29 10:11:40 2020 From: me at the-compiler.org (Florian Bruhin) Date: Wed, 29 Jul 2020 16:11:40 +0200 Subject: [pytest-dev] maintenance of pytest-html In-Reply-To: References: <20200729132154.tu4kketyptjq3vr7@hooch.localdomain>

Message-ID: <20200729141140.hepnkrdn43gmkhgc@hooch.localdomain> On Wed, Jul 29, 2020 at 02:59:24PM +0100, Thomas Grainger wrote: > > Why? Something like a tox environment running against the latest pytest > > prerelease (or pytest master even) plus a scheduled build job should totally > > suffice, no? > > -1 on depending on unpined deps in CI this causes the default branch > to fail and blocks all contributions until it is resolved > Creating a pr (in pyup.io) gives one point of discussion if a release > fails and does not block any other prs Agreed! Just because the environment exists, it doesn't mean it has to run for PRs. Similarly, it doesn't make sense to run e.g. linters periodically. In other words, run environments with pinned versions for PRs/branches, run an environment with unpinned (and prerelease/VCS) dependencies periodically. Florian -- me at the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org https://bruhin.software/ | https://github.com/sponsors/The-Compiler/ GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ssbarnea at redhat.com Wed Jul 29 10:32:16 2020 From: ssbarnea at redhat.com (Sorin Sbarnea) Date: Wed, 29 Jul 2020 15:32:16 +0100 Subject: [pytest-dev] maintenance of pytest-html In-Reply-To: <20200729141140.hepnkrdn43gmkhgc@hooch.localdomain> References: <20200729132154.tu4kketyptjq3vr7@hooch.localdomain>

<20200729141140.hepnkrdn43gmkhgc@hooch.localdomain> Message-ID: <813ECD7F-CBC7-4E71-B11E-4C569393818B@redhat.com> CI/CD is cheap, human work is expensive. If you avoid testing it PR, you will allow introduction of changes that break the master branch. For small projects it does not make sense to avoid testing anything before merge (PR), only for big projects where testing takes many hours and days it makes sense to use promotion pipelines. That is what we do on OpenStack, but for pytest & co, there are no reasons to optimize testing strategy especially as any regression that slips into master is likely to be extra load for the project maintainer (as opposed to the PR OP). It is not uncommon for me to find broken jobs when I propose PR, and also raise one or two other PRs for fixing those, just to get everything green before my patch is ready. By lower PR testing coverage, you loose the opportunity to spread the maintenance burden with occasional contributors. > On 29 Jul 2020, at 15:11, Florian Bruhin wrote: > > On Wed, Jul 29, 2020 at 02:59:24PM +0100, Thomas Grainger wrote: >>> Why? Something like a tox environment running against the latest pytest >>> prerelease (or pytest master even) plus a scheduled build job should totally >>> suffice, no? >> >> -1 on depending on unpined deps in CI this causes the default branch >> to fail and blocks all contributions until it is resolved >> Creating a pr (in pyup.io) gives one point of discussion if a release >> fails and does not block any other prs > > Agreed! Just because the environment exists, it doesn't mean it has to run for > PRs. Similarly, it doesn't make sense to run e.g. linters periodically. > > In other words, run environments with pinned versions for PRs/branches, run an > environment with unpinned (and prerelease/VCS) dependencies periodically. > > Florian > > -- > me at the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org > https://bruhin.software/ | https://github.com/sponsors/The-Compiler/ > GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc > I love long mails! | https://email.is-not-s.ms/ From me at the-compiler.org Wed Jul 29 10:45:26 2020 From: me at the-compiler.org (Florian Bruhin) Date: Wed, 29 Jul 2020 16:45:26 +0200 Subject: [pytest-dev] maintenance of pytest-html In-Reply-To: <813ECD7F-CBC7-4E71-B11E-4C569393818B@redhat.com> References: <20200729132154.tu4kketyptjq3vr7@hooch.localdomain>

<20200729141140.hepnkrdn43gmkhgc@hooch.localdomain> <813ECD7F-CBC7-4E71-B11E-4C569393818B@redhat.com> Message-ID: <20200729144526.aku4x4ysyyhlzixh@hooch.localdomain> On Wed, Jul 29, 2020 at 03:32:16PM +0100, Sorin Sbarnea wrote: > CI/CD is cheap, human work is expensive. > > If you avoid testing it PR, you will allow introduction of changes that break > the master branch. > > For small projects it does not make sense to avoid testing anything before > merge (PR), only for big projects where testing takes many hours and days it > makes sense to use promotion pipelines. > > That is what we do on OpenStack, but for pytest & co, there are no reasons to > optimize testing strategy especially as any regression that slips into master > is likely to be extra load for the project maintainer (as opposed to the PR > OP). It is not uncommon for me to find broken jobs when I propose PR, and > also raise one or two other PRs for fixing those, just to get everything > green before my patch is ready. > > By lower PR testing coverage, you loose the opportunity to spread the > maintenance burden with occasional contributors. I never said you should not test PRs at all. I only said a periodic check against the pytest master probably shouldn't be part of the checks run against PRs. Quoting myself: > Agreed! Just because the environment exists, it doesn't mean it has to run for > PRs. Similarly, it doesn't make sense to run e.g. linters periodically. > > In other words, run environments with pinned versions for PRs/branches, run an > environment with unpinned (and prerelease/VCS) dependencies periodically. Florian -- me at the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org https://bruhin.software/ | https://github.com/sponsors/The-Compiler/ GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nicoddemus at gmail.com Thu Jul 30 08:50:35 2020 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Thu, 30 Jul 2020 09:50:35 -0300 Subject: [pytest-dev] pytest 6.0.1 Message-ID: pytest 6.0.1 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: * Bruno Oliveira * Mattreex * Ran Benita * hp310780 Happy testing, The pytest Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From tagrain at gmail.com Thu Jul 30 10:19:55 2020 From: tagrain at gmail.com (Thomas Grainger) Date: Thu, 30 Jul 2020 15:19:55 +0100 Subject: [pytest-dev] pytest 6.0.1 In-Reply-To: References: Message-ID: I can't see a 6.0.1 changelog at that link On Thu, Jul 30, 2020, 13:50 Bruno Oliveira wrote: > pytest 6.0.1 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: > > * Bruno Oliveira > * Mattreex > * Ran Benita > * hp310780 > > > Happy testing, > The pytest Development Team > _______________________________________________ > 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: From nicoddemus at gmail.com Thu Jul 30 11:03:00 2020 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Thu, 30 Jul 2020 12:03:00 -0300 Subject: [pytest-dev] pytest 6.0.1 In-Reply-To: References:

Message-ID: Ahh sorry, the correct link is: https://docs.pytest.org/en/stable/changelog.html This has been fixed in master, but not ported to the 6.0.x branch yet. Will fix it. Thanks, Bruno On Thu, Jul 30, 2020 at 11:20 AM Thomas Grainger wrote: > I can't see a 6.0.1 changelog at that link > > On Thu, Jul 30, 2020, 13:50 Bruno Oliveira wrote: > >> pytest 6.0.1 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: >> >> * Bruno Oliveira >> * Mattreex >> * Ran Benita >> * hp310780 >> >> >> Happy testing, >> The pytest Development Team >> _______________________________________________ >> 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: