From hansemrbean at googlemail.com Sat Oct 1 03:04:25 2022 From: hansemrbean at googlemail.com (hansemrbean) Date: Sat, 1 Oct 2022 09:04:25 +0200 Subject: [pytest-dev] Transfer of pyfakefs to pytest-dev - second try Message-ID: This is a followup to an earlier thread ( https://www.mail-archive.com/pytest-dev at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sorin.sbarnea at gmail.com Sat Oct 1 04:07:34 2022 From: sorin.sbarnea at gmail.com (Sorin Sbarnea) Date: Sat, 1 Oct 2022 09:07:34 +0100 Subject: [pytest-dev] Transfer of pyfakefs to pytest-dev - second try In-Reply-To: References: Message-ID: +1 from me. I think we should show that pytest-dev is an open minded organisation. I remeber when I lead the move of testinfra into it, where we faced a similar dilemma, the fact that it was a little bit more than a pytest plugin. Still, it did work, well I say. To be honest, I reached a point where I do my best to avoid starting to use any new library, if that is not hosted under a non personal account ? just because it is not cool to depend on a single point of failure, one that ages too. Cheers! Sorin Sbarnea On Sat, 1 Oct 2022 at 08:04, hansemrbean via pytest-dev < pytest-dev at python.org> wrote: > This is a followup to an earlier thread ( > https://www.mail-archive.com/pytest-dev at 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 > > > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -- -- Cheers, Sorin -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Sat Oct 1 14:15:15 2022 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Sat, 1 Oct 2022 15:15:15 -0300 Subject: [pytest-dev] Transfer of pyfakefs to pytest-dev - second try In-Reply-To: References: Message-ID: +1 for me too btw. Cheers, On Sat, Oct 1, 2022 at 5:08 AM Sorin Sbarnea wrote: > +1 from me. I think we should show that pytest-dev is an open minded > organisation. I remeber when I lead the move of testinfra into it, where we > faced a similar dilemma, the fact that it was a little bit more than a > pytest plugin. Still, it did work, well I say. > > To be honest, I reached a point where I do my best to avoid starting to > use any new library, if that is not hosted under a non personal account ? > just because it is not cool to depend on a single point of failure, one > that ages too. > > Cheers! > Sorin Sbarnea > > On Sat, 1 Oct 2022 at 08:04, hansemrbean via pytest-dev < > pytest-dev at python.org> wrote: > >> This is a followup to an earlier thread ( >> https://www.mail-archive.com/pytest-dev at 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 >> >> >> >> _______________________________________________ >> pytest-dev mailing list >> pytest-dev at python.org >> https://mail.python.org/mailman/listinfo/pytest-dev >> > -- > -- > Cheers, > Sorin > _______________________________________________ > 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 hansemrbean at googlemail.com Sun Oct 2 03:24:23 2022 From: hansemrbean at googlemail.com (hansemrbean) Date: Sun, 2 Oct 2022 09:24:23 +0200 Subject: [pytest-dev] Transfer of pyfakefs to pytest-dev - second try In-Reply-To: References: Message-ID: <2a34dff3-73a7-f9d8-b46e-f5428af90a43@googlemail.com> Thank you Sorin and Bruno! The documentation (https://docs.pytest.org/en/7.1.x/contributing.html#submitting-plugins-to-pytest-dev) states that the repository can be transferred "if no contributor strongly objects and two agree". We got two votes, so I will wait a bit more for objections, and in the case none come will go ahead with the transfer. How long shall we wait, and who shall the repo be transferred to if nobody objects? Thanks, Andreas Am 01.10.2022 um 20:15 schrieb Bruno Oliveira: > +1 for me too btw. > > Cheers, > > On Sat, Oct 1, 2022 at 5:08 AM Sorin Sbarnea > wrote: > > +1 from me. I think we should show that pytest-dev is an open > minded organisation. I remeber when I lead the move of testinfra > into it, where we faced a similar dilemma, the fact that it was a > little bit more than a pytest plugin. Still, it did work, well I say. > > To be honest, I reached a point where I do my best to avoid > starting to use any new library, if that is not hosted under a non > personal account ? just because it is not cool to depend on a > single point of failure, one that ages too. > > Cheers! > Sorin Sbarnea > > On Sat, 1 Oct 2022 at 08:04, hansemrbean via pytest-dev > wrote: > > This is a followup to an earlier thread > (https://www.mail-archive.com/pytest-dev at 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 > > > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > > -- > -- > Cheers, > Sorin > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -- This email has been checked for viruses by Avast antivirus software. www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at ronnypfannschmidt.de Sun Oct 2 04:04:09 2022 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Sun, 2 Oct 2022 08:04:09 +0000 (UTC) Subject: [pytest-dev] On ensuring sustainable maintenance of pytest-dev projects Message-ID: 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 From opensource at ronnypfannschmidt.de Sun Oct 2 06:30:02 2022 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Sun, 2 Oct 2022 12:30:02 +0200 Subject: [pytest-dev] assessing hatch/hatching for python package management Message-ID: <420d57e9-20a9-2bd4-e540-cd51c8b76de2@ronnypfannschmidt.de> 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 From opensource at ronnypfannschmidt.de Sun Oct 2 12:49:45 2022 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Sun, 2 Oct 2022 18:49:45 +0200 Subject: [pytest-dev] introducing collection boundaries to support expanding fixtures to non-python and testsuites as python packages Message-ID: 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 From nicoddemus at gmail.com Wed Oct 5 13:36:24 2022 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Wed, 5 Oct 2022 14:36:24 -0300 Subject: [pytest-dev] Transfer of pyfakefs to pytest-dev - second try In-Reply-To: <2a34dff3-73a7-f9d8-b46e-f5428af90a43@googlemail.com> References: <2a34dff3-73a7-f9d8-b46e-f5428af90a43@googlemail.com> Message-ID: Since nobody objects, I think we can make the transfer. Feel free to transfer to me Andreas. Cheers On Sun, Oct 2, 2022 at 4:24 AM hansemrbean wrote: > Thank you Sorin and Bruno! > > The documentation ( > https://docs.pytest.org/en/7.1.x/contributing.html#submitting-plugins-to-pytest-dev) > states that the repository can be transferred "if no contributor strongly > objects and two agree". We got two votes, so I will wait a bit more for > objections, and in the case none come will go ahead with the transfer. How > long shall we wait, and who shall the repo be transferred to if nobody > objects? > > Thanks, > > Andreas > > > Am 01.10.2022 um 20:15 schrieb Bruno Oliveira: > > +1 for me too btw. > > Cheers, > > On Sat, Oct 1, 2022 at 5:08 AM Sorin Sbarnea > wrote: > >> +1 from me. I think we should show that pytest-dev is an open minded >> organisation. I remeber when I lead the move of testinfra into it, where we >> faced a similar dilemma, the fact that it was a little bit more than a >> pytest plugin. Still, it did work, well I say. >> >> To be honest, I reached a point where I do my best to avoid starting to >> use any new library, if that is not hosted under a non personal account ? >> just because it is not cool to depend on a single point of failure, one >> that ages too. >> >> Cheers! >> Sorin Sbarnea >> >> On Sat, 1 Oct 2022 at 08:04, hansemrbean via pytest-dev < >> pytest-dev at python.org> wrote: >> >>> This is a followup to an earlier thread ( >>> https://www.mail-archive.com/pytest-dev at 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 >>> >>> >>> >>> _______________________________________________ >>> pytest-dev mailing list >>> pytest-dev at python.org >>> https://mail.python.org/mailman/listinfo/pytest-dev >>> >> -- >> -- >> Cheers, >> Sorin >> _______________________________________________ >> pytest-dev mailing list >> pytest-dev at python.org >> https://mail.python.org/mailman/listinfo/pytest-dev >> > > [image: width=] > > Virus-free.www.avast.com > > <#m_-8727644505780217632_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at ronnypfannschmidt.de Sat Oct 8 03:47:27 2022 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Sat, 8 Oct 2022 09:47:27 +0200 Subject: [pytest-dev] preparing a pytest-dev/core social video meetup and preparing ideas for a online/offline sprint in 2023 Message-ID: <3657d76d-2454-76cf-e413-f730a22086ae@ronnypfannschmidt.de> 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 From nicoddemus at gmail.com Sat Oct 8 08:00:23 2022 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Sat, 8 Oct 2022 09:00:23 -0300 Subject: [pytest-dev] preparing a pytest-dev/core social video meetup and preparing ideas for a online/offline sprint in 2023 In-Reply-To: <3657d76d-2454-76cf-e413-f730a22086ae@ronnypfannschmidt.de> References: <3657d76d-2454-76cf-e413-f730a22086ae@ronnypfannschmidt.de> Message-ID: Ronny, Sounds like a good idea, specially having another Sprint in person. Cheers, Bruno On Sat, Oct 8, 2022 at 4:48 AM Ronny Pfannschmidt < opensource at ronnypfannschmidt.de> wrote: > 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 > > > _______________________________________________ > 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 flub at devork.be Sun Oct 9 14:19:47 2022 From: flub at devork.be (Floris Bruynooghe) Date: Sun, 09 Oct 2022 20:19:47 +0200 Subject: [pytest-dev] preparing a pytest-dev/core social video meetup and preparing ideas for a online/offline sprint in 2023 In-Reply-To: References: <3657d76d-2454-76cf-e413-f730a22086ae@ronnypfannschmidt.de> Message-ID: <87wn98dflo.fsf@powell.devork.be> I totally second this! (despite my total lack of contributing the last years, I still think this would be good for current contributors) I think during warmer summer moths it is entirely possible to create a COVID-responsible sprint. I think the e.g. the Rust conferences have demonstrated it is possible to put responsible conferences on and having a sprint format can be done even better as you can do basically all activities in outdoors and well spaced and ventilated settings. Maybe a good start would be to figure out which location would be most suitable for prospective participants. Bearing in mind there's a reasonable amount of money pytest has by now so travel assistance should not be a big deal. What format do you have in mind for the round-table? I'm not familiar with this term. Cheers, Floris On Sat 08 Oct 2022 at 09:00 -0300, Bruno Oliveira wrote: > Ronny, > > Sounds like a good idea, specially having another Sprint in person. > > Cheers, > Bruno > > On Sat, Oct 8, 2022 at 4:48 AM Ronny Pfannschmidt < > opensource at ronnypfannschmidt.de> wrote: > >> 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 >> >> >> _______________________________________________ >> 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 From opensource at ronnypfannschmidt.de Tue Oct 25 09:10:41 2022 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Tue, 25 Oct 2022 15:10:41 +0200 Subject: [pytest-dev] pytest 7.2.0 released Message-ID: 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