From hansemrbean at googlemail.com Tue Mar 2 15:34:29 2021 From: hansemrbean at googlemail.com (hansemrbean) Date: Tue, 2 Mar 2021 21:34:29 +0100 Subject: [pytest-dev] Transfer of pytest-order to pytest-dev Message-ID: <64db48cc-16a1-d65e-7e11-aa8a019b8926@googlemail.com> pytest-order (https://github.com/mrbean-bremen/pytest-order) is a fork of pytest-ordering (https://github.com/ftobia/pytest-ordering), which is no longer maintained. The plugin allows ordering tests ordinally and relatively to each other. I made the fork to be able to integrate proposed changes, to adapt it to current Python/pytest versions, and to be able to move forward with the project. As discussed in the issues mentioned below, I want to? transfer it to pytest-dev to ensure continued maintenance. The transfer will be handled in https://github.com/pytest-dev/meta/issues/7. For reference see also https://github.com/ftobia/pytest-ordering/issues/32 and https://github.com/mrbean-bremen/pytest-order/issues/4. Thanks -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From daniele at vurt.org Tue Mar 2 04:15:34 2021 From: daniele at vurt.org (Daniele Procida) Date: Tue, 2 Mar 2021 09:15:34 +0000 Subject: [pytest-dev] pytest documentation In-Reply-To: References: <20210227122540.43030039@mail.gandi.net> Message-ID: <20210302091534.884938463@mail.gandi.net> Bruno Oliveira wrote: >I definitely think it would be a good idea, but I'm interested to hear >what the other maintainers think as well. I haven't heard any other replies - I would be glad to know what others think, to be sure that this will be a good way forward and of benefit to pytest (or not!). Thanks, Daniele From brianna.laugher at gmail.com Tue Mar 2 17:42:51 2021 From: brianna.laugher at gmail.com (Brianna Laugher) Date: Wed, 3 Mar 2021 09:42:51 +1100 Subject: [pytest-dev] pytest documentation In-Reply-To: <20210302091534.884938463@mail.gandi.net> References: <20210227122540.43030039@mail.gandi.net> <20210302091534.884938463@mail.gandi.net> Message-ID: I'm still in favour, and it sounds like a smart way to avoid the problems of a long-lived branch. On Wed, 3 Mar 2021 at 07:57, Daniele Procida wrote: > Bruno Oliveira wrote: > > >I definitely think it would be a good idea, but I'm interested to hear > >what the other maintainers think as well. > > I haven't heard any other replies - I would be glad to know what others > think, to be sure that this will be a good way forward and of benefit to > pytest (or not!). > > Thanks, > > Daniele > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -- They've just been waiting in a mountain for the right moment: http://modernthings.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Tue Mar 2 19:06:05 2021 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Tue, 2 Mar 2021 21:06:05 -0300 Subject: [pytest-dev] Transfer of pytest-order to pytest-dev In-Reply-To: <64db48cc-16a1-d65e-7e11-aa8a019b8926@googlemail.com> References: <64db48cc-16a1-d65e-7e11-aa8a019b8926@googlemail.com> Message-ID: Hi Hansemrbean, As I wrote in the issues themselves, +1 from me. Thanks for stepping up! Cheers, Bruno. On Tue, Mar 2, 2021 at 5:51 PM hansemrbean via pytest-dev < pytest-dev at python.org> wrote: > pytest-order (https://github.com/mrbean-bremen/pytest-order) is a fork > of pytest-ordering (https://github.com/ftobia/pytest-ordering), which is > no longer maintained. The plugin allows ordering tests ordinally and > relatively to each other. > > I made the fork to be able to integrate proposed changes, to adapt it to > current Python/pytest versions, and to be able to move forward with the > project. As discussed in the issues mentioned below, I want to transfer > it to pytest-dev to ensure continued maintenance. The transfer will be > handled in https://github.com/pytest-dev/meta/issues/7. > > For reference see also > https://github.com/ftobia/pytest-ordering/issues/32 and > https://github.com/mrbean-bremen/pytest-order/issues/4. > > Thanks > > > -- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > _______________________________________________ > 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 h.goebel at crazy-compilers.com Wed Mar 3 03:01:08 2021 From: h.goebel at crazy-compilers.com (Hartmut Goebel) Date: Wed, 3 Mar 2021 09:01:08 +0100 Subject: [pytest-dev] pytest documentation In-Reply-To: <20210302091534.884938463@mail.gandi.net> References: <20210227122540.43030039@mail.gandi.net> <20210302091534.884938463@mail.gandi.net> Message-ID: <8ce474d9-2949-18c3-902e-3c3a7a7249eb@crazy-compilers.com> Am 02.03.21 um 10:15 schrieb Daniele Procida: > I haven't heard any other replies - I would be glad to know what others think, to be sure that this will be a good way forward and of benefit to pytest (or not!). IMHO this is a good idea. Anyhow, in the next weeks I will not have to to review your changes -- Regards Hartmut Goebel | Hartmut Goebel | h.goebel at crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | From ran at unusedvar.com Wed Mar 3 07:27:54 2021 From: ran at unusedvar.com (Ran Benita) Date: Wed, 03 Mar 2021 14:27:54 +0200 Subject: [pytest-dev] pytest documentation In-Reply-To: <20210227122540.43030039@mail.gandi.net> References: <20210227122540.43030039@mail.gandi.net> Message-ID: <1bb6c6ef-921c-43a8-96e5-a5b3f23c94b4@www.fastmail.com> On Sat, Feb 27, 2021, at 14:25, Daniele Procida wrote: > Would you be interested in my tackling this again? I believe that this > approach will be successful in a way that it wasn't last time. Thanks for the heads up. Evolution over revolution sounds good. For my part, I cannot guarantee prompt reviews, but I'll certainly review when I can. You can maybe start with a few PRs and see how it goes. Ran From nicoddemus at gmail.com Thu Mar 4 11:03:40 2021 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Thu, 4 Mar 2021 13:03:40 -0300 Subject: [pytest-dev] Transfer of pytest-order to pytest-dev In-Reply-To: References: <64db48cc-16a1-d65e-7e11-aa8a019b8926@googlemail.com> Message-ID: Folks, Anybody opposes this? We need two +1 from core maintainers to move this forward. Cheers, Bruno On Tue, Mar 2, 2021 at 9:06 PM Bruno Oliveira wrote: > Hi Hansemrbean, > > As I wrote in the issues themselves, +1 from me. > > Thanks for stepping up! > > Cheers, > Bruno. > > On Tue, Mar 2, 2021 at 5:51 PM hansemrbean via pytest-dev < > pytest-dev at python.org> wrote: > >> pytest-order (https://github.com/mrbean-bremen/pytest-order) is a fork >> of pytest-ordering (https://github.com/ftobia/pytest-ordering), which is >> no longer maintained. The plugin allows ordering tests ordinally and >> relatively to each other. >> >> I made the fork to be able to integrate proposed changes, to adapt it to >> current Python/pytest versions, and to be able to move forward with the >> project. As discussed in the issues mentioned below, I want to transfer >> it to pytest-dev to ensure continued maintenance. The transfer will be >> handled in https://github.com/pytest-dev/meta/issues/7. >> >> For reference see also >> https://github.com/ftobia/pytest-ordering/issues/32 and >> https://github.com/mrbean-bremen/pytest-order/issues/4. >> >> Thanks >> >> >> -- >> This email has been checked for viruses by Avast antivirus software. >> https://www.avast.com/antivirus >> >> _______________________________________________ >> 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 Thu Mar 4 11:12:17 2021 From: tagrain at gmail.com (Thomas Grainger) Date: Thu, 4 Mar 2021 16:12:17 +0000 Subject: [pytest-dev] Transfer of pytest-order to pytest-dev In-Reply-To: References: <64db48cc-16a1-d65e-7e11-aa8a019b8926@googlemail.com>

Message-ID: +1 from me On Thu, 4 Mar 2021, 16:03 Bruno Oliveira, wrote: > Folks, > > Anybody opposes this? We need two +1 from core maintainers to move this > forward. > > Cheers, > Bruno > > On Tue, Mar 2, 2021 at 9:06 PM Bruno Oliveira > wrote: > >> Hi Hansemrbean, >> >> As I wrote in the issues themselves, +1 from me. >> >> Thanks for stepping up! >> >> Cheers, >> Bruno. >> >> On Tue, Mar 2, 2021 at 5:51 PM hansemrbean via pytest-dev < >> pytest-dev at python.org> wrote: >> >>> pytest-order (https://github.com/mrbean-bremen/pytest-order) is a fork >>> of pytest-ordering (https://github.com/ftobia/pytest-ordering), which >>> is >>> no longer maintained. The plugin allows ordering tests ordinally and >>> relatively to each other. >>> >>> I made the fork to be able to integrate proposed changes, to adapt it to >>> current Python/pytest versions, and to be able to move forward with the >>> project. As discussed in the issues mentioned below, I want to transfer >>> it to pytest-dev to ensure continued maintenance. The transfer will be >>> handled in https://github.com/pytest-dev/meta/issues/7. >>> >>> For reference see also >>> https://github.com/ftobia/pytest-ordering/issues/32 and >>> https://github.com/mrbean-bremen/pytest-order/issues/4. >>> >>> Thanks >>> >>> >>> -- >>> This email has been checked for viruses by Avast antivirus software. >>> https://www.avast.com/antivirus >>> >>> _______________________________________________ >>> 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 hansemrbean at googlemail.com Fri Mar 5 13:59:43 2021 From: hansemrbean at googlemail.com (mrbean-bremen) Date: Fri, 5 Mar 2021 19:59:43 +0100 Subject: [pytest-dev] Transfer of pyfakefs to pytest-dev? Message-ID: After the successful transfer of pytest-order (thank you for that smooth experience!), I have been thinking about the transfer of another library - pyfakefs - where I am a contributor. I have been discussing this with the package maintainer, John McGehee, who is also in favor for this, and decided to first ask here if that is feasible. pyfakefs (https://github.com/jmcgeheeiv/pyfakefs) is a library that mocks the file system. It has originally been developed by Mike Bland at Google, later transferred to GitHub (after the shutdown of Google Code in 2011), where John McGehee has forked it, added direct support for unittest and doctest, and has maintained it since then (with my help since a few years ago). Later a contributor added support for pytest via the fs fixture, with more support for pytest following eventually. Today the fs fixture is probably the main means to access pyfakefs, judging by the issues and the dependent repositories. So, while pyfakefs is not a pure pytest plugin, and it doesn't follow the naming convention pytest-xx, we thought that it would be a good idea to transfer it to pytest-dev, with the following goals: - ensure continued maintenance - increase compatibility with pytest and pytest-plugins - improve visibility of the package, especially for pytest developers - ideally, benefit from the larger community to get more code reviews and issue reports For reference see also https://github.com/jmcgeheeiv/pyfakefs/issues/590 What do you think? Thanks! -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From opensource at ronnypfannschmidt.de Sat Mar 6 17:01:10 2021 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Sat, 6 Mar 2021 23:01:10 +0100 Subject: [pytest-dev] Transfer of pyfakefs to pytest-dev? In-Reply-To: References: Message-ID: <496678a0-e8a5-6123-2d0e-c4af5cca0fb1@ronnypfannschmidt.de> Hi, i'm not sure if this should go under pytest-dev, if i had found the time to make https://github.com/cogs-of-testing be actually practical/known yet, i'd sugest it for there. -- Ronny Am 05.03.21 um 19:59 schrieb mrbean-bremen via pytest-dev: > After the successful transfer of pytest-order (thank you for that > smooth experience!), I have been thinking about the transfer of > another library - pyfakefs - where I am a contributor. I have been > discussing this with the package maintainer, John McGehee, who is also > in favor for this, and decided to first ask here if that is feasible. > > pyfakefs (https://github.com/jmcgeheeiv/pyfakefs) is a library that > mocks the file system. It has originally been developed by Mike Bland > at Google, later transferred to GitHub (after the shutdown of Google > Code in 2011), where John McGehee has forked it, added direct support > for unittest and doctest, and has maintained it since then (with my > help since a few years ago). Later a contributor added support for > pytest via the fs fixture, with more support for pytest following > eventually. Today the fs fixture is probably the main means to access > pyfakefs, judging by the issues and the dependent repositories. > > So, while pyfakefs is not a pure pytest plugin, and it doesn't follow > the naming convention pytest-xx, we thought that it would be a good > idea to transfer it to pytest-dev, with the following goals: > > - ensure continued maintenance > > - increase compatibility with pytest and pytest-plugins > > - improve visibility of the package, especially for pytest developers > > - ideally, benefit from the larger community to get more code reviews > and issue reports > > For reference see also https://github.com/jmcgeheeiv/pyfakefs/issues/590 > > What do you think? Thanks! > > > From hansemrbean at googlemail.com Sun Mar 7 02:11:39 2021 From: hansemrbean at googlemail.com (hansemrbean) Date: Sun, 7 Mar 2021 08:11:39 +0100 Subject: [pytest-dev] Transfer of pyfakefs to pytest-dev? In-Reply-To: <496678a0-e8a5-6123-2d0e-c4af5cca0fb1@ronnypfannschmidt.de> References: <496678a0-e8a5-6123-2d0e-c4af5cca0fb1@ronnypfannschmidt.de> Message-ID: <11861c11-ebb3-d2e8-7e93-387b6603c4b7@googlemail.com> Hi, Thank you - I agree that pyfakefs is not a 100% fit, thus this mail instead of a formal request for transfer. I asked Bruno Oliviera (who helped with the pytest-order transfer) if he sees this as a possibility before writing this mail. I also had been searching for an organization related to general Python testing, but obviously didn't find one. Cogs of testing sounds interesting - was this meant for Python testing, or general testing? Are there other libraries that you would see there? Maybe there is a related thread or post you can refer me to... If the Cogs of testing organization can be brought to live, this may be an alternative, I just don't know how realistic this is. The main goal of the proposed transfer is indeed continued maintenance, and decreasing the bus factor.? Still undecided myself... Cheers Am 06.03.2021 um 23:01 schrieb Ronny Pfannschmidt: > Hi, > > i'm not sure if this should go under pytest-dev, > if i had found the time to make https://github.com/cogs-of-testing be > actually practical/known yet, i'd sugest it for there. > > -- Ronny > > > Am 05.03.21 um 19:59 schrieb mrbean-bremen via pytest-dev: >> After the successful transfer of pytest-order (thank you for that >> smooth experience!), I have been thinking about the transfer of >> another library - pyfakefs - where I am a contributor. I have been >> discussing this with the package maintainer, John McGehee, who is >> also in favor for this, and decided to first ask here if that is >> feasible. >> >> pyfakefs (https://github.com/jmcgeheeiv/pyfakefs) is a library that >> mocks the file system. It has originally been developed by Mike Bland >> at Google, later transferred to GitHub (after the shutdown of Google >> Code in 2011), where John McGehee has forked it, added direct support >> for unittest and doctest, and has maintained it since then (with my >> help since a few years ago). Later a contributor added support for >> pytest via the fs fixture, with more support for pytest following >> eventually. Today the fs fixture is probably the main means to access >> pyfakefs, judging by the issues and the dependent repositories. >> >> So, while pyfakefs is not a pure pytest plugin, and it doesn't follow >> the naming convention pytest-xx, we thought that it would be a good >> idea to transfer it to pytest-dev, with the following goals: >> >> - ensure continued maintenance >> >> - increase compatibility with pytest and pytest-plugins >> >> - improve visibility of the package, especially for pytest developers >> >> - ideally, benefit from the larger community to get more code reviews >> and issue reports >> >> For reference see also https://github.com/jmcgeheeiv/pyfakefs/issues/590 >> >> What do you think? Thanks! >> >> >> -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From ssbarnea at redhat.com Sun Mar 7 03:10:59 2021 From: ssbarnea at redhat.com (Sorin Sbarnea) Date: Sun, 7 Mar 2021 08:10:59 +0000 Subject: [pytest-dev] Transfer of pyfakefs to pytest-dev? In-Reply-To: <11861c11-ebb3-d2e8-7e93-387b6603c4b7@googlemail.com> References: <496678a0-e8a5-6123-2d0e-c4af5cca0fb1@ronnypfannschmidt.de> <11861c11-ebb3-d2e8-7e93-387b6603c4b7@googlemail.com> Message-ID: Why not reusing existing https://github.com/PyCQA for that? I am personally concerned about having too many orgs. One or two years ago we moved the doc8 tool from under opendev/openstack in order to make it easier to maintain. Its main goal seems to fit the repo quite well. On Sun, 7 Mar 2021 at 07:11, hansemrbean via pytest-dev < pytest-dev at python.org> wrote: > Hi, > > Thank you - I agree that pyfakefs is not a 100% fit, thus this mail > instead of a formal request for transfer. I asked Bruno Oliviera (who > helped with the pytest-order transfer) if he sees this as a possibility > before writing this mail. I also had been searching for an organization > related to general Python testing, but obviously didn't find one. > > Cogs of testing sounds interesting - was this meant for Python testing, > or general testing? Are there other libraries that you would see there? > Maybe there is a related thread or post you can refer me to... > > If the Cogs of testing organization can be brought to live, this may be > an alternative, I just don't know how realistic this is. The main goal > of the proposed transfer is indeed continued maintenance, and decreasing > the bus factor. Still undecided myself... > > Cheers > > Am 06.03.2021 um 23:01 schrieb Ronny Pfannschmidt: > > > Hi, > > > > i'm not sure if this should go under pytest-dev, > > if i had found the time to make https://github.com/cogs-of-testing be > > actually practical/known yet, i'd sugest it for there. > > > > -- Ronny > > > > > > Am 05.03.21 um 19:59 schrieb mrbean-bremen via pytest-dev: > >> After the successful transfer of pytest-order (thank you for that > >> smooth experience!), I have been thinking about the transfer of > >> another library - pyfakefs - where I am a contributor. I have been > >> discussing this with the package maintainer, John McGehee, who is > >> also in favor for this, and decided to first ask here if that is > >> feasible. > >> > >> pyfakefs (https://github.com/jmcgeheeiv/pyfakefs) is a library that > >> mocks the file system. It has originally been developed by Mike Bland > >> at Google, later transferred to GitHub (after the shutdown of Google > >> Code in 2011), where John McGehee has forked it, added direct support > >> for unittest and doctest, and has maintained it since then (with my > >> help since a few years ago). Later a contributor added support for > >> pytest via the fs fixture, with more support for pytest following > >> eventually. Today the fs fixture is probably the main means to access > >> pyfakefs, judging by the issues and the dependent repositories. > >> > >> So, while pyfakefs is not a pure pytest plugin, and it doesn't follow > >> the naming convention pytest-xx, we thought that it would be a good > >> idea to transfer it to pytest-dev, with the following goals: > >> > >> - ensure continued maintenance > >> > >> - increase compatibility with pytest and pytest-plugins > >> > >> - improve visibility of the package, especially for pytest developers > >> > >> - ideally, benefit from the larger community to get more code reviews > >> and issue reports > >> > >> For reference see also > https://github.com/jmcgeheeiv/pyfakefs/issues/590 > >> > >> What do you think? Thanks! > >> > >> > >> > > -- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -- -- /zbr -------------- next part -------------- An HTML attachment was scrubbed... URL: From hansemrbean at googlemail.com Sun Mar 7 03:44:34 2021 From: hansemrbean at googlemail.com (hansemrbean) Date: Sun, 7 Mar 2021 09:44:34 +0100 Subject: [pytest-dev] Transfer of pyfakefs to pytest-dev? In-Reply-To: References: <496678a0-e8a5-6123-2d0e-c4af5cca0fb1@ronnypfannschmidt.de> <11861c11-ebb3-d2e8-7e93-387b6603c4b7@googlemail.com> Message-ID: <39a44dd3-326e-144d-2526-10364854040d@googlemail.com> I don't think that pyfakefs will fit that - PyCQA is about formatting / quality tools, while pyfakefs is a testing tool (both for pytest and unittest). And I agree about having too many orgs - as far as I can see, pytest-dev is currently the only organization concerned with Python testing (there is nose-dev, but it only has nose and nose2). With the current state, I would still say that pyfakefs fits best with pytest-dev. A more general organization concerned with Python testing would only make sense, if there are some relevant repositories that would go into this - I just don't know the goal and the potential repos for Cogs of testing (I like the name, though :). Am 07.03.2021 um 09:10 schrieb Sorin Sbarnea: > Why not reusing existing > https://github.com/PyCQA for that? I am > personally concerned about having too many orgs. One or two years ago > we moved the doc8 tool from under opendev/openstack in order to make > it easier to maintain. > > Its main goal seems to fit the repo quite well. > > On Sun, 7 Mar 2021 at 07:11, hansemrbean via pytest-dev > > wrote: > > Hi, > > Thank you - I agree that pyfakefs is not a 100% fit, thus this mail > instead of a formal request for transfer. I asked Bruno Oliviera (who > helped with the pytest-order transfer) if he sees this as a > possibility > before writing this mail. I also had been searching for an > organization > related to general Python testing, but obviously didn't find one. > > Cogs of testing sounds interesting - was this meant for Python > testing, > or general testing? Are there other libraries that you would see > there? > Maybe there is a related thread or post you can refer me to... > > If the Cogs of testing organization can be brought to live, this > may be > an alternative, I just don't know how realistic this is. The main > goal > of the proposed transfer is indeed continued maintenance, and > decreasing > the bus factor.? Still undecided myself... > > Cheers > > Am 06.03.2021 um 23:01 schrieb Ronny Pfannschmidt: > > > Hi, > > > > i'm not sure if this should go under pytest-dev, > > if i had found the time to make > https://github.com/cogs-of-testing > be > > actually practical/known yet, i'd sugest it for there. > > > > -- Ronny > > > > > > Am 05.03.21 um 19:59 schrieb mrbean-bremen via pytest-dev: > >> After the successful transfer of pytest-order (thank you for that > >> smooth experience!), I have been thinking about the transfer of > >> another library - pyfakefs - where I am a contributor. I have been > >> discussing this with the package maintainer, John McGehee, who is > >> also in favor for this, and decided to first ask here if that is > >> feasible. > >> > >> pyfakefs (https://github.com/jmcgeheeiv/pyfakefs > ) is a library that > >> mocks the file system. It has originally been developed by Mike > Bland > >> at Google, later transferred to GitHub (after the shutdown of > Google > >> Code in 2011), where John McGehee has forked it, added direct > support > >> for unittest and doctest, and has maintained it since then > (with my > >> help since a few years ago). Later a contributor added support for > >> pytest via the fs fixture, with more support for pytest following > >> eventually. Today the fs fixture is probably the main means to > access > >> pyfakefs, judging by the issues and the dependent repositories. > >> > >> So, while pyfakefs is not a pure pytest plugin, and it doesn't > follow > >> the naming convention pytest-xx, we thought that it would be a > good > >> idea to transfer it to pytest-dev, with the following goals: > >> > >> - ensure continued maintenance > >> > >> - increase compatibility with pytest and pytest-plugins > >> > >> - improve visibility of the package, especially for pytest > developers > >> > >> - ideally, benefit from the larger community to get more code > reviews > >> and issue reports > >> > >> For reference see also > https://github.com/jmcgeheeiv/pyfakefs/issues/590 > > >> > >> What do you think? Thanks! > >> > >> > >> > > -- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > > > -- > -- > /zbr -------------- next part -------------- An HTML attachment was scrubbed... URL: From sorin.sbarnea at gmail.com Sun Mar 7 04:34:36 2021 From: sorin.sbarnea at gmail.com (Sorin Sbarnea) Date: Sun, 7 Mar 2021 01:34:36 -0800 Subject: [pytest-dev] Transfer of pyfakefs to pytest-dev? In-Reply-To: <39a44dd3-326e-144d-2526-10364854040d@googlemail.com> References: <496678a0-e8a5-6123-2d0e-c4af5cca0fb1@ronnypfannschmidt.de> <11861c11-ebb3-d2e8-7e93-387b6603c4b7@googlemail.com> <39a44dd3-326e-144d-2526-10364854040d@googlemail.com> Message-ID: While most repos inside pcqa are quality-assurance tools instead of just libraries, my personal view is that there is no reason to distinguish between a library that you use to improve testing ("quality assurance") and a tool that helps you achieve the same. As noted, pytest-dev is not ideal because is tool-oriented, like other similar orgs as tox-dev or sphinx-contrib. Still, I would personally prefer bypassing the rule and avoiding creating yet-another-github-org (nope yagho is taken). The only danger I see with move to pytest-dev is for pyfakefs itself because I am aware of a group of people that are strongly opposed pytest due to the fact it makes too easy for projects to endup having test suites that run only with pytest (they value the freedom of test runner more than the benefits). The way I see pycqa, is as being tool agnostic, with enough members that can step in to help a project reaches an in-limbo state. Over the last years I transitioned or supported transition of python libraries to any of the mentioned organization, and I am happy with any of them. I trust them to be able to provide assistance when a project is in need, they improve visibility of the project and makes easier to foster connections with other people with similar experience and mind-focus, like quality control. My main concern, with very small organizations, is that I did not want to end-up with one that is controlled by one or two that have a monetizing interest in it (as in pushing to promote themselves or their companies directly). Bigger orgs with people that are there only because they love open-source and value the community, are ideal. -- Cheers, Sorin On 7 Mar 2021 at 08:44:34, hansemrbean via pytest-dev wrote: > I don't think that pyfakefs will fit that - PyCQA is about formatting / > quality tools, while pyfakefs is a testing tool (both for pytest and > unittest). > > And I agree about having too many orgs - as far as I can see, pytest-dev > is currently the only organization concerned with Python testing (there is > nose-dev, but it only has nose and nose2). With the current state, I would > still say that pyfakefs fits best with pytest-dev. A more general > organization concerned with Python testing would only make sense, if there > are some relevant repositories that would go into this - I just don't know > the goal and the potential repos for Cogs of testing (I like the name, > though :). > > Am 07.03.2021 um 09:10 schrieb Sorin Sbarnea: > > Why not reusing existing > https://github.com/PyCQA for that? I am personally concerned about having > too many orgs. One or two years ago we moved the doc8 tool from under > opendev/openstack in order to make it easier to maintain. > > Its main goal seems to fit the repo quite well. > > On Sun, 7 Mar 2021 at 07:11, hansemrbean via pytest-dev < > pytest-dev at python.org> wrote: > >> Hi, >> >> Thank you - I agree that pyfakefs is not a 100% fit, thus this mail >> instead of a formal request for transfer. I asked Bruno Oliviera (who >> helped with the pytest-order transfer) if he sees this as a possibility >> before writing this mail. I also had been searching for an organization >> related to general Python testing, but obviously didn't find one. >> >> Cogs of testing sounds interesting - was this meant for Python testing, >> or general testing? Are there other libraries that you would see there? >> Maybe there is a related thread or post you can refer me to... >> >> If the Cogs of testing organization can be brought to live, this may be >> an alternative, I just don't know how realistic this is. The main goal >> of the proposed transfer is indeed continued maintenance, and decreasing >> the bus factor. Still undecided myself... >> >> Cheers >> >> Am 06.03.2021 um 23:01 schrieb Ronny Pfannschmidt: >> >> > Hi, >> > >> > i'm not sure if this should go under pytest-dev, >> > if i had found the time to make https://github.com/cogs-of-testing be >> > actually practical/known yet, i'd sugest it for there. >> > >> > -- Ronny >> > >> > >> > Am 05.03.21 um 19:59 schrieb mrbean-bremen via pytest-dev: >> >> After the successful transfer of pytest-order (thank you for that >> >> smooth experience!), I have been thinking about the transfer of >> >> another library - pyfakefs - where I am a contributor. I have been >> >> discussing this with the package maintainer, John McGehee, who is >> >> also in favor for this, and decided to first ask here if that is >> >> feasible. >> >> >> >> pyfakefs (https://github.com/jmcgeheeiv/pyfakefs) is a library that >> >> mocks the file system. It has originally been developed by Mike Bland >> >> at Google, later transferred to GitHub (after the shutdown of Google >> >> Code in 2011), where John McGehee has forked it, added direct support >> >> for unittest and doctest, and has maintained it since then (with my >> >> help since a few years ago). Later a contributor added support for >> >> pytest via the fs fixture, with more support for pytest following >> >> eventually. Today the fs fixture is probably the main means to access >> >> pyfakefs, judging by the issues and the dependent repositories. >> >> >> >> So, while pyfakefs is not a pure pytest plugin, and it doesn't follow >> >> the naming convention pytest-xx, we thought that it would be a good >> >> idea to transfer it to pytest-dev, with the following goals: >> >> >> >> - ensure continued maintenance >> >> >> >> - increase compatibility with pytest and pytest-plugins >> >> >> >> - improve visibility of the package, especially for pytest developers >> >> >> >> - ideally, benefit from the larger community to get more code reviews >> >> and issue reports >> >> >> >> For reference see also >> https://github.com/jmcgeheeiv/pyfakefs/issues/590 >> >> >> >> What do you think? Thanks! >> >> >> >> >> >> >> >> -- >> This email has been checked for viruses by Avast antivirus software. >> https://www.avast.com/antivirus >> >> _______________________________________________ >> pytest-dev mailing list >> pytest-dev at python.org >> https://mail.python.org/mailman/listinfo/pytest-dev >> > -- > -- > /zbr > > > > Virus-free. > www.avast.com > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > _______________________________________________ > 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 Mar 7 07:35:19 2021 From: hansemrbean at googlemail.com (hansemrbean) Date: Sun, 7 Mar 2021 13:35:19 +0100 Subject: [pytest-dev] Transfer of pyfakefs to pytest-dev? In-Reply-To: References: <496678a0-e8a5-6123-2d0e-c4af5cca0fb1@ronnypfannschmidt.de> <11861c11-ebb3-d2e8-7e93-387b6603c4b7@googlemail.com> <39a44dd3-326e-144d-2526-10364854040d@googlemail.com> Message-ID: I agree that QA is also about testing, but PyCQA? seems to be more specific: > The PyCQA is a loose organization of people who maintain projects in roughly the same domain: automatic style and quality reporting. Almost all of these projects are widely used by the larger Python community (and by each other) to enforce style guidelines and maintain some modicum of consistency within a code base. pyfakefs as a library is more comparable to pytest-mock then to flake8, IMHO. In a sense, it is a bit like pytest-mock: it provides a wrapper around a mock for pytest, with the difference that the mock itself is also part of pyfakefs. I had briefly considered if it makes sense to make a separate pytest-fs package, that would provide the fs plugin based on pyfakefs (there has been a user complaining about the fact that pyfakefs registers a pytest plugin on installation, without explicitely being told so), but that would imply documentation duplication, and missing upwards compatibility. It would have been an option at the time of adding pytest support, but we missed that. Making pyfakefs a part of pytest-dev would not mean that it wouldn't support unittest anymore - it would just be a commitment for better pytest support, as I see it. If someone doesn't want to use it because of that, so be it, if you ask me... but I think most users will prefer technical reasoning. And as I said, I agree about small organizations. It needs a certain community size to be immune against the mentioned problems. Anyway, if it turns out that pyfakefs does not fit into pytest-dev, we will just wait. I'm still interested in that Cogs of test thing - if there are some other matching repositories (e.g. if there is a chance that it would be of sufficient size), it would sense to get that going instead. Cheers Am 07.03.2021 um 10:34 schrieb Sorin Sbarnea: > While most repos inside pcqa are quality-assurance tools instead of > just libraries, my personal view is that there is no reason to > distinguish between a library that you use to improve testing > ("quality assurance") and a tool that helps you achieve the same. > > As noted, pytest-dev is not ideal because is tool-oriented, like other > similar orgs as tox-dev or?sphinx-contrib. Still, I would personally > prefer bypassing the rule and avoiding creating yet-another-github-org > (nope yagho is taken). The only danger I see with move to pytest-dev > is for pyfakefs itself because I am aware of a group of people that > are strongly opposed pytest due to the fact it makes too easy for > projects to endup having test suites that run only with pytest (they > value the freedom of test runner more than the benefits). > > The way I see pycqa, is as being tool agnostic, with enough members > that can step in to help a project reaches an in-limbo state. > > Over the last years I transitioned or supported transition of python > libraries to any of the mentioned organization, and I am happy with > any of them. I trust them to be able to provide assistance when a > project is in need, they improve visibility of the project and makes > easier to foster connections with other people with similar experience > and mind-focus, like quality control. > > My main concern, with very small organizations, is that I did not want > to end-up with one that is controlled by one or two that have a > monetizing interest in it (as in pushing to promote themselves or > their companies directly). Bigger orgs with people that are there only > because they love open-source and value the community, are ideal. > > -- > Cheers, > Sorin > > > On 7 Mar 2021 at 08:44:34, hansemrbean via pytest-dev > > wrote: > > I don't think that pyfakefs will fit that - PyCQA is about > formatting / quality tools, while pyfakefs is a testing tool (both > for pytest and unittest). > > And I agree about having too many orgs - as far as I can see, > pytest-dev is currently the only organization concerned with > Python testing (there is nose-dev, but it only has nose and > nose2). With the current state, I would still say that pyfakefs > fits best with pytest-dev. A more general organization concerned > with Python testing would only make sense, if there are some > relevant repositories that would go into this - I just don't know > the goal and the potential repos for Cogs of testing (I like the > name, though :). > > Am 07.03.2021 um 09:10 schrieb Sorin Sbarnea: > >> Why not reusing existing >> https://github.com/PyCQA for that? I >> am personally concerned about having too many orgs. One or two >> years ago we moved the doc8 tool from under opendev/openstack in >> order to make it easier to maintain. >> >> Its main goal seems to fit the repo quite well. >> >> On Sun, 7 Mar 2021 at 07:11, hansemrbean via pytest-dev >> > wrote: >> >> Hi, >> >> Thank you - I agree that pyfakefs is not a 100% fit, thus >> this mail >> instead of a formal request for transfer. I asked Bruno >> Oliviera (who >> helped with the pytest-order transfer) if he sees this as a >> possibility >> before writing this mail. I also had been searching for an >> organization >> related to general Python testing, but obviously didn't find one. >> >> Cogs of testing sounds interesting - was this meant for >> Python testing, >> or general testing? Are there other libraries that you would >> see there? >> Maybe there is a related thread or post you can refer me to... >> >> If the Cogs of testing organization can be brought to live, >> this may be >> an alternative, I just don't know how realistic this is. The >> main goal >> of the proposed transfer is indeed continued maintenance, and >> decreasing >> the bus factor.? Still undecided myself... >> >> Cheers >> >> Am 06.03.2021 um 23:01 schrieb Ronny Pfannschmidt: >> >> > Hi, >> > >> > i'm not sure if this should go under pytest-dev, >> > if i had found the time to make >> https://github.com/cogs-of-testing >> be >> > actually practical/known yet, i'd sugest it for there. >> > >> > -- Ronny >> > >> > >> > Am 05.03.21 um 19:59 schrieb mrbean-bremen via pytest-dev: >> >> After the successful transfer of pytest-order (thank you >> for that >> >> smooth experience!), I have been thinking about the >> transfer of >> >> another library - pyfakefs - where I am a contributor. I >> have been >> >> discussing this with the package maintainer, John McGehee, >> who is >> >> also in favor for this, and decided to first ask here if >> that is >> >> feasible. >> >> >> >> pyfakefs (https://github.com/jmcgeheeiv/pyfakefs >> ) is a library that >> >> mocks the file system. It has originally been developed by >> Mike Bland >> >> at Google, later transferred to GitHub (after the shutdown >> of Google >> >> Code in 2011), where John McGehee has forked it, added >> direct support >> >> for unittest and doctest, and has maintained it since then >> (with my >> >> help since a few years ago). Later a contributor added >> support for >> >> pytest via the fs fixture, with more support for pytest >> following >> >> eventually. Today the fs fixture is probably the main >> means to access >> >> pyfakefs, judging by the issues and the dependent >> repositories. >> >> >> >> So, while pyfakefs is not a pure pytest plugin, and it >> doesn't follow >> >> the naming convention pytest-xx, we thought that it would >> be a good >> >> idea to transfer it to pytest-dev, with the following goals: >> >> >> >> - ensure continued maintenance >> >> >> >> - increase compatibility with pytest and pytest-plugins >> >> >> >> - improve visibility of the package, especially for pytest >> developers >> >> >> >> - ideally, benefit from the larger community to get more >> code reviews >> >> and issue reports >> >> >> >> For reference see also >> https://github.com/jmcgeheeiv/pyfakefs/issues/590 >> >> >> >> >> What do you think? Thanks! >> >> >> >> >> >> >> >> -- >> This email has been checked for viruses by Avast antivirus >> software. >> https://www.avast.com/antivirus >> >> _______________________________________________ >> pytest-dev mailing list >> pytest-dev at python.org >> https://mail.python.org/mailman/listinfo/pytest-dev >> >> >> -- >> -- >> /zbr > > > Virus-free. www.avast.com > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > _______________________________________________ > 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. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From hansemrbean at googlemail.com Tue Mar 9 11:48:37 2021 From: hansemrbean at googlemail.com (hansemrbean) Date: Tue, 9 Mar 2021 17:48:37 +0100 Subject: [pytest-dev] Transfer of pyfakefs to pytest-dev? In-Reply-To: References: <496678a0-e8a5-6123-2d0e-c4af5cca0fb1@ronnypfannschmidt.de> <11861c11-ebb3-d2e8-7e93-387b6603c4b7@googlemail.com> <39a44dd3-326e-144d-2526-10364854040d@googlemail.com>

Message-ID: Ok, thank you all - if there are no more opinions, I think I can take that as a no - pyfakefs does not fit pytest-dev, and rest the case. Thanks! Am 07.03.2021 um 13:35 schrieb hansemrbean: > I agree that QA is also about testing, but PyCQA? seems to be more > specific: > > > The PyCQA is a loose organization of people who maintain projects in > roughly the same domain: automatic style and quality reporting. Almost > all of these projects are widely used by the larger Python community > (and by each other) to enforce style guidelines and maintain some > modicum of consistency within a code base. > > pyfakefs as a library is more comparable to pytest-mock then to > flake8, IMHO. In a sense, it is a bit like pytest-mock: it provides a > wrapper around a mock for pytest, with the difference that the mock > itself is also part of pyfakefs. I had briefly considered if it makes > sense to make a separate pytest-fs package, that would provide the fs > plugin based on pyfakefs (there has been a user complaining about the > fact that pyfakefs registers a pytest plugin on installation, without > explicitely being told so), but that would imply documentation > duplication, and missing upwards compatibility. It would have been an > option at the time of adding pytest support, but we missed that. > > Making pyfakefs a part of pytest-dev would not mean that it wouldn't > support unittest anymore - it would just be a commitment for better > pytest support, as I see it. If someone doesn't want to use it because > of that, so be it, if you ask me... but I think most users will prefer > technical reasoning. > > And as I said, I agree about small organizations. It needs a certain > community size to be immune against the mentioned problems. > > Anyway, if it turns out that pyfakefs does not fit into pytest-dev, we > will just wait. I'm still interested in that Cogs of test thing - if > there are some other matching repositories (e.g. if there is a chance > that it would be of sufficient size), it would sense to get that going > instead. > > Cheers > > Am 07.03.2021 um 10:34 schrieb Sorin Sbarnea: >> While most repos inside pcqa are quality-assurance tools instead of >> just libraries, my personal view is that there is no reason to >> distinguish between a library that you use to improve testing >> ("quality assurance") and a tool that helps you achieve the same. >> >> As noted, pytest-dev is not ideal because is tool-oriented, like >> other similar orgs as tox-dev or?sphinx-contrib. Still, I would >> personally prefer bypassing the rule and avoiding creating >> yet-another-github-org (nope yagho is taken). The only danger I see >> with move to pytest-dev is for pyfakefs itself because I am aware of >> a group of people that are strongly opposed pytest due to the fact it >> makes too easy for projects to endup having test suites that run only >> with pytest (they value the freedom of test runner more than the >> benefits). >> >> The way I see pycqa, is as being tool agnostic, with enough members >> that can step in to help a project reaches an in-limbo state. >> >> Over the last years I transitioned or supported transition of python >> libraries to any of the mentioned organization, and I am happy with >> any of them. I trust them to be able to provide assistance when a >> project is in need, they improve visibility of the project and makes >> easier to foster connections with other people with similar >> experience and mind-focus, like quality control. >> >> My main concern, with very small organizations, is that I did not >> want to end-up with one that is controlled by one or two that have a >> monetizing interest in it (as in pushing to promote themselves or >> their companies directly). Bigger orgs with people that are there >> only because they love open-source and value the community, are ideal. >> >> -- >> Cheers, >> Sorin >> >> >> On 7 Mar 2021 at 08:44:34, hansemrbean via pytest-dev >> > wrote: >> >> I don't think that pyfakefs will fit that - PyCQA is about >> formatting / quality tools, while pyfakefs is a testing tool >> (both for pytest and unittest). >> >> And I agree about having too many orgs - as far as I can see, >> pytest-dev is currently the only organization concerned with >> Python testing (there is nose-dev, but it only has nose and >> nose2). With the current state, I would still say that pyfakefs >> fits best with pytest-dev. A more general organization concerned >> with Python testing would only make sense, if there are some >> relevant repositories that would go into this - I just don't know >> the goal and the potential repos for Cogs of testing (I like the >> name, though :). >> >> Am 07.03.2021 um 09:10 schrieb Sorin Sbarnea: >> >>> Why not reusing existing >>> https://github.com/PyCQA for that? I >>> am personally concerned about having too many orgs. One or two >>> years ago we moved the doc8 tool from under opendev/openstack in >>> order to make it easier to maintain. >>> >>> Its main goal seems to fit the repo quite well. >>> >>> On Sun, 7 Mar 2021 at 07:11, hansemrbean via pytest-dev >>> > wrote: >>> >>> Hi, >>> >>> Thank you - I agree that pyfakefs is not a 100% fit, thus >>> this mail >>> instead of a formal request for transfer. I asked Bruno >>> Oliviera (who >>> helped with the pytest-order transfer) if he sees this as a >>> possibility >>> before writing this mail. I also had been searching for an >>> organization >>> related to general Python testing, but obviously didn't find >>> one. >>> >>> Cogs of testing sounds interesting - was this meant for >>> Python testing, >>> or general testing? Are there other libraries that you would >>> see there? >>> Maybe there is a related thread or post you can refer me to... >>> >>> If the Cogs of testing organization can be brought to live, >>> this may be >>> an alternative, I just don't know how realistic this is. The >>> main goal >>> of the proposed transfer is indeed continued maintenance, >>> and decreasing >>> the bus factor.? Still undecided myself... >>> >>> Cheers >>> >>> Am 06.03.2021 um 23:01 schrieb Ronny Pfannschmidt: >>> >>> > Hi, >>> > >>> > i'm not sure if this should go under pytest-dev, >>> > if i had found the time to make >>> https://github.com/cogs-of-testing >>> be >>> > actually practical/known yet, i'd sugest it for there. >>> > >>> > -- Ronny >>> > >>> > >>> > Am 05.03.21 um 19:59 schrieb mrbean-bremen via pytest-dev: >>> >> After the successful transfer of pytest-order (thank you >>> for that >>> >> smooth experience!), I have been thinking about the >>> transfer of >>> >> another library - pyfakefs - where I am a contributor. I >>> have been >>> >> discussing this with the package maintainer, John >>> McGehee, who is >>> >> also in favor for this, and decided to first ask here if >>> that is >>> >> feasible. >>> >> >>> >> pyfakefs (https://github.com/jmcgeheeiv/pyfakefs >>> ) is a library that >>> >> mocks the file system. It has originally been developed >>> by Mike Bland >>> >> at Google, later transferred to GitHub (after the >>> shutdown of Google >>> >> Code in 2011), where John McGehee has forked it, added >>> direct support >>> >> for unittest and doctest, and has maintained it since >>> then (with my >>> >> help since a few years ago). Later a contributor added >>> support for >>> >> pytest via the fs fixture, with more support for pytest >>> following >>> >> eventually. Today the fs fixture is probably the main >>> means to access >>> >> pyfakefs, judging by the issues and the dependent >>> repositories. >>> >> >>> >> So, while pyfakefs is not a pure pytest plugin, and it >>> doesn't follow >>> >> the naming convention pytest-xx, we thought that it would >>> be a good >>> >> idea to transfer it to pytest-dev, with the following goals: >>> >> >>> >> - ensure continued maintenance >>> >> >>> >> - increase compatibility with pytest and pytest-plugins >>> >> >>> >> - improve visibility of the package, especially for >>> pytest developers >>> >> >>> >> - ideally, benefit from the larger community to get more >>> code reviews >>> >> and issue reports >>> >> >>> >> For reference see also >>> https://github.com/jmcgeheeiv/pyfakefs/issues/590 >>> >>> >> >>> >> What do you think? Thanks! >>> >> >>> >> >>> >> >>> >>> -- >>> This email has been checked for viruses by Avast antivirus >>> software. >>> https://www.avast.com/antivirus >>> >>> >>> _______________________________________________ >>> pytest-dev mailing list >>> pytest-dev at python.org >>> https://mail.python.org/mailman/listinfo/pytest-dev >>> >>> >>> -- >>> -- >>> /zbr >> >> >> Virus-free. www.avast.com >> >> >> >> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> _______________________________________________ >> 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. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniele at vurt.org Sat Mar 13 18:27:18 2021 From: daniele at vurt.org (Daniele Procida) Date: Sat, 13 Mar 2021 23:27:18 +0000 Subject: [pytest-dev] pytest documentation Message-ID: <20210313232718.1507593987@mail.gandi.net> [I actually sent this on Wednesday, but only just realised that I sent it to myself because of the reply-to - so it's a bit late] I've started now: . A few questions: would you like me to add something to the _changelog_towncrier_draft.rst or changelog.rst, even for these little changes? I don't want to pollute it with excessive noise. Secondly, would you like me to create an issue just to refer to this conversation, and for the commits to refer to? Finally, is there a way to run linting on the documentation only? Thanks, Daniele Daniele Procida wrote: >Bruno Oliveira wrote: > >>I definitely think it would be a good idea, but I'm interested to hear >>what the other maintainers think as well. > >I haven't heard any other replies - I would be glad to know what others >think, to be sure that this will be a good way forward and of benefit to >pytest (or not!). > >Thanks, > >Daniele > >_______________________________________________ >pytest-dev mailing list >pytest-dev at python.org >https://mail.python.org/mailman/listinfo/pytest-dev From daniele at vurt.org Sat Mar 13 18:27:49 2021 From: daniele at vurt.org (Daniele Procida) Date: Sat, 13 Mar 2021 23:27:49 +0000 Subject: [pytest-dev] pytest documentation Message-ID: <20210313232749.1538048271@mail.gandi.net> Hello pytest team, now that I have been at this a few days, I wanted to check in to see how you feel how it's going. Does the burden of doing things this way seem excessive? Is there anything you would you like me to do differently, or are you happy for me continue like this? Thanks for merging all the PRs so swiftly. Daniele From ran at unusedvar.com Sun Mar 14 03:53:49 2021 From: ran at unusedvar.com (Ran Benita) Date: Sun, 14 Mar 2021 09:53:49 +0200 Subject: [pytest-dev] pytest documentation In-Reply-To: <20210313232749.1538048271@mail.gandi.net> References: <20210313232749.1538048271@mail.gandi.net> Message-ID: <01dedfa0-4666-4c70-b00d-4e320c9cd046@www.fastmail.com> On Sun, Mar 14, 2021, at 01:27, Daniele Procida wrote: > Hello pytest team, now that I have been at this a few days, I wanted to > check in to see how you feel how it's going. I feel the improvements thus far have been great. > Does the burden of doing things this way seem excessive? Is there > anything you would you like me to do differently, or are you happy for > me continue like this? I'm happy :) > Thanks for merging all the PRs so swiftly. Thanks for working on this project! Ran From ran at unusedvar.com Sun Mar 14 04:08:23 2021 From: ran at unusedvar.com (Ran Benita) Date: Sun, 14 Mar 2021 10:08:23 +0200 Subject: [pytest-dev] pytest documentation In-Reply-To: <20210313232718.1507593987@mail.gandi.net> References: <20210313232718.1507593987@mail.gandi.net> Message-ID: <1aed1184-b7d7-4694-a0f6-4341bf4d99bb@www.fastmail.com> > On Sun, Mar 14, 2021, at 01:27, Daniele Procida wrote: > A few questions: would you like me to add something to the > _changelog_towncrier_draft.rst or changelog.rst, even for these little > changes? I don't want to pollute it with excessive noise. I think the best/easiest thing would be to add a single general changelog at the end of the effort (or toward a release). But I think which ever way you prefer is fine. > Secondly, would you like me to create an issue just to refer to this > conversation, and for the commits to refer to? Since the changelog entry format requires an issue number, it makes sense to create one for this purpose. You can make it just a placeholder and refer to the mailing list, or however you prefer. > Finally, is there a way to run linting on the documentation only? There are several things that pass over the docs (I might be missing some): - The "blacken-docs" which formats code in the docs. - Some doctesting which executes tests in the docs. - The "regen" task which adds real-life execution results to the docs. - The sphinx build itself which generates the docs and also issues warnings. There's also a linkcheck which checks broken links but I think we don't actually run that. Do you refer to any one in particular or just one of these? Are you using tox, or is it that tox is too slow and you want to run the commands manually? Ran From opensource at ronnypfannschmidt.de Sun Mar 14 06:18:39 2021 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Sun, 14 Mar 2021 11:18:39 +0100 Subject: [pytest-dev] pytest documentation In-Reply-To: <01dedfa0-4666-4c70-b00d-4e320c9cd046@www.fastmail.com> References: <20210313232749.1538048271@mail.gandi.net> <01dedfa0-4666-4c70-b00d-4e320c9cd046@www.fastmail.com> Message-ID: <9b86bcd4-2bd8-d5d4-0e42-941c84d2d788@ronnypfannschmidt.de> I second Ran, its great to finally see someone someone do this with care. -- Ronny Am 14.03.21 um 08:53 schrieb Ran Benita via pytest-dev: > On Sun, Mar 14, 2021, at 01:27, Daniele Procida wrote: >> Hello pytest team, now that I have been at this a few days, I wanted to >> check in to see how you feel how it's going. > I feel the improvements thus far have been great. > >> Does the burden of doing things this way seem excessive? Is there >> anything you would you like me to do differently, or are you happy for >> me continue like this? > I'm happy :) > >> Thanks for merging all the PRs so swiftly. > Thanks for working on this project! > > Ran > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev From variedthoughts at gmail.com Sun Mar 21 13:41:19 2021 From: variedthoughts at gmail.com (Brian Okken) Date: Sun, 21 Mar 2021 10:41:19 -0700 Subject: [pytest-dev] autospec for monkeypatch Message-ID: <2C30EF6B-DA89-429C-A4B6-7979A33E3885@gmail.com> I think I want to get some extra help on this good question. - Brian - Brian Begin forwarded message: > From: Dimitri Blyumin via Fireside > Date: March 20, 2021 at 7:36:58 PM PDT > To: brian at pythontesting.net > Subject: [Test & Code : Python Testing] Listener Feedback from Dimitri Blyumin > Reply-To: dimitri.blyumin at gmail.com > > ?Name: Dimitri Blyumin > Email: dimitri.blyumin at gmail.com > Twitter: > Website: > > Hi Brian, > I'm going through your excellent "Python Testing with pytest" book, and came across this potential scenario in monkeypatching: if we use setitem and misspell the key - it will create a new key:value and will leave the original one as is, no KeyError or warning. > Looking at the docs - there is no option to only accept existing keys. > I think this can be dangerous in some cases when the user expects a value to be patched, and it is not, e.g. change environment in the config dict from PRD to DEV. > Did you encounter this and is there a way to ensure that only existing keys are used in patching? > > > -- > Fireside Labs, LLC (http://fireside.fm/) -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Sun Mar 21 16:06:35 2021 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Sun, 21 Mar 2021 17:06:35 -0300 Subject: [pytest-dev] autospec for monkeypatch In-Reply-To: <2C30EF6B-DA89-429C-A4B6-7979A33E3885@gmail.com> References: <2C30EF6B-DA89-429C-A4B6-7979A33E3885@gmail.com> Message-ID: > there is no option to only accept existing keys. I'm not sure what they mean... there's a `raising` keyword argument, which defaults to True. [] Bruno On Sun, Mar 21, 2021 at 2:41 PM Brian Okken wrote: > I think I want to get some extra help on this good question. > - Brian > > - Brian > > Begin forwarded message: > > *From:* Dimitri Blyumin via Fireside > *Date:* March 20, 2021 at 7:36:58 PM PDT > *To:* brian at pythontesting.net > *Subject:* *[Test & Code : Python Testing] Listener Feedback from > Dimitri Blyumin* > *Reply-To:* dimitri.blyumin at gmail.com > > ?Name: Dimitri Blyumin > Email: dimitri.blyumin at gmail.com > Twitter: > Website: > > Hi Brian, > I'm going through your excellent "Python Testing with pytest" book, and > came across this potential scenario in monkeypatching: if we use setitem > and misspell the key - it will create a new key:value and will leave the > original one as is, no KeyError or warning. > Looking at the docs - there is no option to only accept existing keys. > I think this can be dangerous in some cases when the user expects a value > to be patched, and it is not, e.g. change environment in the config dict > from PRD to DEV. > Did you encounter this and is there a way to ensure that only existing > keys are used in patching? > > > -- > Fireside Labs, LLC (http://fireside.fm/) > > _______________________________________________ > 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 variedthoughts at gmail.com Sun Mar 21 18:46:08 2021 From: variedthoughts at gmail.com (Brian Okken) Date: Sun, 21 Mar 2021 15:46:08 -0700 Subject: [pytest-dev] autospec for monkeypatch In-Reply-To: References: Message-ID: Yep. I think that?s it. I totally forgot about raising. I?ll try it out. - Brian > On Mar 21, 2021, at 1:06 PM, Bruno Oliveira wrote: > > ? > > there is no option to only accept existing keys. > > I'm not sure what they mean... there's a `raising` keyword argument, which defaults to True. > > [] > Bruno > >> On Sun, Mar 21, 2021 at 2:41 PM Brian Okken wrote: >> I think I want to get some extra help on this good question. >> - Brian >> >> - Brian >> >> Begin forwarded message: >> >>> From: Dimitri Blyumin via Fireside >>> Date: March 20, 2021 at 7:36:58 PM PDT >>> To: brian at pythontesting.net >>> Subject: [Test & Code : Python Testing] Listener Feedback from Dimitri Blyumin >>> Reply-To: dimitri.blyumin at gmail.com >>> >>> ?Name: Dimitri Blyumin >>> Email: dimitri.blyumin at gmail.com >>> Twitter: >>> Website: >>> >>> Hi Brian, >>> I'm going through your excellent "Python Testing with pytest" book, and came across this potential scenario in monkeypatching: if we use setitem and misspell the key - it will create a new key:value and will leave the original one as is, no KeyError or warning. >>> Looking at the docs - there is no option to only accept existing keys. >>> I think this can be dangerous in some cases when the user expects a value to be patched, and it is not, e.g. change environment in the config dict from PRD to DEV. >>> Did you encounter this and is there a way to ensure that only existing keys are used in patching? >>> >>> >>> -- >>> Fireside Labs, LLC (http://fireside.fm/) >> _______________________________________________ >> 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 mail at florian-schulze.net Mon Mar 22 04:44:41 2021 From: mail at florian-schulze.net (Florian Schulze) Date: Mon, 22 Mar 2021 09:44:41 +0100 Subject: [pytest-dev] autospec for monkeypatch In-Reply-To: References:

Message-ID: <88645825-2ED3-4795-BEF5-261232CC25A5@florian-schulze.net> There is a difference between setattr and setitem. The setattr variant actually has the raising option, the setitem variant does not. I think it might be useful to add it for setitem as well. For backward compatibility it would need to default to False. Maybe there is a better API to achieve the same. Regards, Florian Schulze On 21 Mar 2021, at 23:46, Brian Okken wrote: > Yep. I think that?s it. I totally forgot about raising. I?ll try > it out. > > - Brian > >> On Mar 21, 2021, at 1:06 PM, Bruno Oliveira >> wrote: >> >> ? >>> there is no option to only accept existing keys. >> >> I'm not sure what they mean... there's a `raising` keyword argument, >> which defaults to True. >> >> [] >> Bruno >> >>> On Sun, Mar 21, 2021 at 2:41 PM Brian Okken >>> wrote: >>> I think I want to get some extra help on this good question. >>> - Brian >>> >>> - Brian >>> >>> Begin forwarded message: >>> >>>> From: Dimitri Blyumin via Fireside >>>> Date: March 20, 2021 at 7:36:58 PM PDT >>>> To: brian at pythontesting.net >>>> Subject: [Test & Code : Python Testing] Listener Feedback from >>>> Dimitri Blyumin >>>> Reply-To: dimitri.blyumin at gmail.com >>>> >>>> ?Name: Dimitri Blyumin >>>> Email: dimitri.blyumin at gmail.com >>>> Twitter: >>>> Website: >>>> >>>> Hi Brian, >>>> I'm going through your excellent "Python Testing with pytest" book, >>>> and came across this potential scenario in monkeypatching: if we >>>> use setitem and misspell the key - it will create a new key:value >>>> and will leave the original one as is, no KeyError or warning. >>>> Looking at the docs - there is no option to only accept existing >>>> keys. >>>> I think this can be dangerous in some cases when the user expects a >>>> value to be patched, and it is not, e.g. change environment in the >>>> config dict from PRD to DEV. >>>> Did you encounter this and is there a way to ensure that only >>>> existing keys are used in patching? >>>> >>>> >>>> -- >>>> Fireside Labs, LLC (http://fireside.fm/) >>> _______________________________________________ >>> 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: