Mailman 3 October 2022 - pytest-dev

preparing a pytest-dev/core social video meetup and preparing ideas for a online/offline sprint in 2023
by Ronny Pfannschmidt Nov. 25, 2022

Nov. 25, 2022

Hi everyone, with the pandemic ensuring lack of safe conferences/sprints since a while now, i think its very helpful to create some type of semi-regular interaction to get the team closer and to foster progress. The last pytest sprint is already an awful long while ago, and with the lack of safe to visit conferences in the last few years, we haven't had many chances to foster social interaction. In order to change that i want to create a regular round-table whose primary focus is getting to know each other and fostering joy in interaction, which in turn should be a good help in fostering progress for pytest as a whole. Additionally i would like to see trough with some preparations for a pytest summer sprint in 2023 in order to create opportunities to work in person on some of the pain points that we where not able to touch/move in the years since the last sprint. -- Ronny

5 4

pytest 7.2.0 released
by Ronny Pfannschmidt Oct. 25, 2022

Oct. 25, 2022

pytest-7.2.0 ============== The pytest team is proud to announce the 7.2.0 release! This release contains new features, improvements, and bug fixes, the full list of changes is available in the 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 of the contributors to this release: * Aaron Berdy * Adam Turner * Albert Villanova del Moral * Alice Purcell * Anthony Sottile * Anton Yakutovich * Babak Keyvani * Brandon Chinn * Bruno Oliveira * Chanvin Xiao * Cheuk Ting Ho * Chris Wheeler * EmptyRabbit * Ezio Melotti * Florian Best * Florian Bruhin * Fredrik Berndtsson * Gabriel Landau * Gergely Kalmár * Hugo van Kemenade * James Gerity * John Litborn * Jon Parise * Kevin C * Kian Eliasi * MatthewFlamm * Miro Hrončok * Nate Meyvis * Neil Girdhar * Nhieuvu1802 * Nipunn Koorapati * Ofek Lev * Paul Müller * Paul Reece * Pax * Pete Baughman * Peyman Salehi * Philipp A * Ran Benita * Robert O'Shea * Ronny Pfannschmidt * Rowin * Ruth Comer * Samuel Colvin * Samuel Gaist * Sandro Tosi * Shantanu * Simon K * Stephen Rosen * Sviatoslav Sydorenko * Tatiana Ovary * Thierry Moisan * Thomas Grainger * Tim Hoffmann * Tobias Diez * Tony Narlock * Vivaan Verma * Wolfremium * Zac Hatfield-Dodds * Zach OBrien * aizpurua23a * gresm * holesch * itxasos23 * johnkangw * skhomuti * sommersoft * wodny * zx.qiu Happy testing, The pytest Development Team

1 0

Transfer of pyfakefs to pytest-dev - second try
by hansemrbean Oct. 5, 2022

Oct. 5, 2022

This is a followup to an earlier thread ( https://www.mail-archive.com/pytest-dev@python.org/msg02835.html) a year and a half ago, where I asked if it would be possible to transfer pyfakefs ( https://github.com/jmcgeheeiv/pyfakefs) to pytest-dev. This was eventually declined, mostly because pyfakefs is not a pure pytest plugin, but also supports unittest and other test environments. The maintainer of pyfakefs, John McGehee, has contacted me, and asked me to take over, as he will not be able to maintain the package anymore. While discussing this, we again came to the conclusion that moving the repository to pytest-dev would make much sense. I asked Bruno Oliviera (who helped with with the transfer of pytest-order) in a private discussion, and he encouraged me to try again, so here I am... I want to reiterate the reasons for the transfer I gave last time, and maybe elaborate a bit more. - ensure continued maintenance: I will be the only maintainer now, and the move to an organization would make it possible to add other owners, and will probably make it more likely to find another maintainer (given the visibility and size of pytest-dev). There is also the bus factor, which I cannot discard given that I'm not young. - increase compatibility with pytest and pytest plugins, - improve visibility of the package, especially for pytest developers: pyfakefs was originally developed inside Google with the possibility to mock some filesystem modules and later released on GitHub; John McGehee added specific support for unittest in 2014, and another contributor added pytest support in the form of the fs fixture a bit later (2015). Since then the usage of pyfakefs has steadily drifted from unittest to pytest, as can be seen by the usage in other repositories (I did some usage statistics for dependent repos in GitHub) and by new issues, and the support for pytest has been improved. I personally like pytest and see it as the superior testing framework, so I'm also interested in improving the compatiblity of pyfakefs with other pytest plugins - which will be easier if it is clearly visible as part of the pytest environment. - ideally, benefit from the larger community to get more code reviews and issue reports: if think this is obvious. Last time it had also been proposed to move to https://github.com/PyCQA instead, but I really don't see a match here. https://github.com/cogs-of-testing had also been mentioned, and while it sounds like a good match, it has yet to be brought to life. Let me know if there is anything I can do to make pyfakefs better compatible with pytest-dev, or if you need more information. Thanks in advance, Andreas

3 4

introducing collection boundaries to support expanding fixtures to non-python and testsuites as python packages
by Ronny Pfannschmidt Oct. 2, 2022

Oct. 2, 2022

Hi everyone, i would like to break open a number of limitations we have in the collection system. 1. parametrize is tied painfully into Python Items I want to finish my experiment for function definitions and generalize them This would mean that instead of multiple python collectors invoking parametrize internally to functions, we would collect function definitions. This would be represented in the collection tree instead of just being a implementation detail of the python generate_tests hook the generate_tests hook would generalize so that it would apply to any "definition" not just a Python Function Definition. (im torn between keeping item or intoducing a Parameterization Node, aining insights on that will have to wait until definition is part of the collection tree) 2. pytests unawareness of tests in packages that may/must install vs tests in local test folders create painful breakages with doctests/tests inside of packages that must install/reinstall for testruns i'd like to enable a basic awareness of installed tests vs local tests vs editable tests (and fail pytest if installed tests differ from the local files) this also includes better awareness of paths/meta paths and pep420 3. testsuites for reuse or purposes like system testing cannot natively be shipped as python packages, collecting them creates painful effects wrt local vs remote filenames as well as collection paths vs import paths it should be possible to have testsuites that ship as pytohn packages and to parametrize/configure them. for that i would like to propose a system building on top of the packaging awareness of pytest, and extending it with mechanisms to either call defined testsuites and/or referring to external testuites and including configured versions of those in current testruns exact mechanisms for configuration/nesting/"testsuite cycles" and more are yet to be determined but examples i'd like to support are stuff like having tools and frameworks provide basic tests for stuff like "base behaviors of well behaved plugins of a framework", "sanity tests for features of of framework plugins" i'd love to get inputs/considerations and concerns as i'll focus on those topics in order in the next few months. -- Ronny

1 0

assessing hatch/hatching for python package management
by Ronny Pfannschmidt Oct. 2, 2022

Oct. 2, 2022

Hi everyone, in https://github.com/pytest-dev/pluggy/pull/362 i prepared to move pluggy to hatch. I hope to eventually move most if not all of pytest-dev over to it. Hatch is a new and modern tool for python package creation. it follows the relevant peps, and has a superset of tox features as well. I already adopted it to a number of my personal and at work projects, and even dropped eventually creating a own packaging tool for it. I believe its a bit win for the python ecosystem to get away from the legacy of setuptools/distutils, and to me hatch is the best of its kind as potential replacement. I'd love to get some more impressions on this before merging. -- Ronny

1 0

On ensuring sustainable maintenance of pytest-dev projects
by Ronny Pfannschmidt Oct. 2, 2022

Oct. 2, 2022

Hi everyone, Please read with the caveat that this stems from a gut feeling that's not yet quantitative verified. As pytest-dev is growing, so is the number of projects that suffer bus-factor and/or non-maintenance. I believe a more active approach to ensuring maintenance /maintainer influx is needed. Else projects like pytest-asyncio, pytest-xdist, execnet, apipkg and more are just going to face bitrot and pain. The ratio between people with maintainer bit vs people that can and will do the work seems to be at a alarmingly low ratio. I don't have a good idea for changing that yet, but my impression is that we gotta start doing the work to ensure pytest-dev won't turn into a graveyard with a few pained grave keepers. -- Ronny

1 0