From craig.ds at gmail.com Sat Nov 3 03:54:44 2018 From: craig.ds at gmail.com (Craig de Stigter) Date: Sat, 3 Nov 2018 20:54:44 +1300 Subject: [pytest-dev] Advice for writing a failure bisection plugin Message-ID: Hi there I'm really enjoying using pytest (and currently porting a large OSS project to it). The project I'm porting has a large number of tests that depend on other tests. In particular, combining certain tests in the same run as other tests appears to cause segfaults sometimes, or double-free errors at process exit (particularly annoying since it's very hard to pinpoint what caused it) My current workflow for finding these dependencies involves: * run all the tests, note a failure. * run half the tests, see if it still fails. If not, run the other half * run half of *those *tests, etc. This is pretty similar to the `git bisect` workflow when debugging when a bug was introduced in a codebase. I'd like to find or write a similar plugin for pytest, that would repeatedly run teh tests with smaller and smaller subsets of tests until the dependent tests are identified. Since sometimes the failure mode I'm tracking is a crash at the end of the process (after all tests have succeeded), I will need to run tests as a subprocess of the main process (so I can restart it when it fails.) The simplest implementation I can think of is a plugin that completely takes over the parent pytest process, runs pytest itself repeatedly in a `subprocess.check_call()`, then calls `sys.exit(0)` when done. This sounds pretty wrong but it could be a good starting point? However, I note the excellent pytest-xdist plugin is good at spawning worker subprocesses and sending tests to them, and rather than re-invent the wheel I wondered if I could make my plugin depend on xdist, and *control* the xdist workers (e.g. run one worker with all the tests; if it crashes, run a new worker with half the tests, etc). Could someone knowledgeable in this area give me some pointers on whether this is a good idea; what exactly is possible; and where to look for code to re-use? Particularly if you know of any plugins that might do similar things that I could take inspiration from. Thanks for reading :) Craig de Stigter -------------- next part -------------- An HTML attachment was scrubbed... URL: From genml+pytest-dev at thequod.de Sat Nov 3 21:47:04 2018 From: genml+pytest-dev at thequod.de (Daniel Hahler) Date: Sun, 4 Nov 2018 02:47:04 +0100 Subject: [pytest-dev] Advice for writing a failure bisection plugin In-Reply-To: References: Message-ID: <8ca59956-38a3-003c-df02-3d66855805c9@thequod.de> On 03.11.18 08:54, Craig de Stigter wrote: > However, I note the excellent pytest-xdist plugin is good at spawning worker subprocesses and sending tests to them, and rather than re-invent the wheel I wondered if I could make my plugin depend on xdist, and /control/ the xdist workers (e.g. run one worker with all the tests; if it crashes, run a new worker with half the tests, etc). I do not think xdist is a good fit here, since you do not want to run the tests distributed (like you correctly said). I think the order tests is important here, so you might want to look into pytest-randomly (https://github.com/pytest-dev/pytest-randomly). A new plugin could make sense here, where you would record if the test run failed completely in the end, or due to some specific test(s), while running them with pytest-randomly on CI as normal (where builds then get restarted, but the information should be recorded). Then you could build some tree(s) based on this information. I think using pytest-randomly from the start is good to not get into a situation where you appear to be now already.. ;) For debugging this locally `pytest -x` with pytest-randomly might be good already - start looking at fast failures. btw: it reminded me of https://github.com/sixty-north/cosmic-ray (Mutation testing for Python), where you can use celery workers to run mutations of your tests. Maybe this could be useful to just run mutations of the test order? (just my quick 2 cents, not having looked at the PR or the project, but am a user of gdal, so that's great to have covered by pytest soon.. :)) Cheers, Daniel. From flub at devork.be Sun Nov 4 06:10:19 2018 From: flub at devork.be (Floris Bruynooghe) Date: Sun, 04 Nov 2018 13:10:19 +0200 Subject: [pytest-dev] Advice for writing a failure bisection plugin In-Reply-To: <8ca59956-38a3-003c-df02-3d66855805c9@thequod.de> References: <8ca59956-38a3-003c-df02-3d66855805c9@thequod.de> Message-ID: <87in1djdyc.fsf@powell.devork.be> On Sun 04 Nov 2018 at 02:47 +0100, Daniel Hahler wrote: > On 03.11.18 08:54, Craig de Stigter wrote: > > However, I note the excellent pytest-xdist plugin is good at > > spawning worker subprocesses and sending tests to them, and rather > > than re-invent the wheel I wondered if I could make my plugin depend > > on xdist, and /control/ the xdist workers (e.g. run one worker with > > all the tests; if it crashes, run a new worker with half the tests, > > etc). > > I do not think xdist is a good fit here, since you do not want to run > the tests distributed (like you correctly said). xdist might not be such a bad fit. It has several ways of distributing the tests to processes: all tests to each process, distributed etc. It also already re-starts processes. So you might be able to write an xdist hook to chunk the tests in the way you like, re-running failed tests etc. I'm saying this all with last time having worked on xdist O(years) ago though, so hey. Cheers, Floris From nicoddemus at gmail.com Sun Nov 4 10:29:10 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Sun, 4 Nov 2018 13:29:10 -0200 Subject: [pytest-dev] pytest 3.10 Message-ID: The pytest team is proud to announce the 3.10.0 release! pytest is a mature Python testing tool with more than a 2000 tests against itself, passing on many different interpreters and platforms. This release contains a number of bugs fixes and improvements, so users are encouraged to take a look at the CHANGELOG: https://docs.pytest.org/en/latest/changelog.html For complete documentation, please visit: https://docs.pytest.org/en/latest/ As usual, you can upgrade from pypi via: pip install -U pytest Thanks to all who contributed to this release, among them: * Anders Hovm?ller * Andreu Vallbona Plazas * Ankit Goel * Anthony Sottile * Bernardo Gomes * Brianna Laugher * Bruno Oliveira * Daniel Hahler * David Szotten * Mick Koch * Niclas Olofsson * Palash Chatterjee * Ronny Pfannschmidt * Sven-Hendrik Haase * Ville Skytt? * William Jamir Silva Happy testing, The Pytest Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.marie at se.com Mon Nov 5 16:25:36 2018 From: sylvain.marie at se.com (Sylvain MARIE) Date: Mon, 5 Nov 2018 21:25:36 +0000 Subject: [pytest-dev] parameters and fixtures, storage and benchmarks: feedback appreciated Message-ID: Dear pytest development team In our data science team we develop a lot of machine learning/statistics components and a recurrent need is benchmarking codes against many reference datasets. By benchmarking we often mean "applicative" benchmarking (such as algorithm accuracy), even if execution time may also be looked at as a secondary target. For this reason https://github.com/ionelmc/pytest-benchmark does not seem to suit our needs. I developed several versions of a benchmarking toolkit in the past years for this purpose but I managed to port it entirely to pytest, so as to leverage all the great built-in mechanisms (namely, parameters and fixtures). It is mostly for this reason that I broke down the problem into smaller pieces and open-sourced each piece as a separate mechanism. You already know pytest-cases (to separate the test logic from the test cases/datasets) and pytest-steps (to break down the test logic into pieces while keeping it quite readable), the last piece I completed is about storing test results so as to get a true "benchmark" functionality with synthesis reports at the end. I broke down the mechanisms into two parts and would like to have your opinion: - one part will be a decorator for function-scoped fixtures, so as to say "please store all these fixture's instances" (in a dictionary-like storage object under key=test id) - another part will be a special fixture, decorated with the above, allowing people to easily inject "results bags" into their test functions to save results and retrieve them at the end Do you think that this (in particular the first item to store fixture) is compliant with pytest ? From investigating, I found out that params are currently stored in session but not fixtures (purposedly). It therefore seems natural to propose a way for users to store very specific fixtures on a declarative basis. Concerning the place where to store them (the global storage object), I am currently allowing users either to rely on a global variable or on a fixture. Would there be another preferred way to store information in pytest, across all tests ? Of course compliance with pytest-xdist will be a holy grail in the future, I do not want to shoot at it directly but pick the 'least bad' choices. Thanks in advance for your kind review and advices ! Best regards -- Sylvain From opensource at ronnypfannschmidt.de Wed Nov 7 03:19:19 2018 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Wed, 07 Nov 2018 09:19:19 +0100 Subject: [pytest-dev] breaking releases required - sorting out FunctionDefinition and Compatproperties Message-ID: <4617e54065c65bd5ac16bd08037dc76fdef1e450.camel@ronnypfannschmidt.de> Hi everyone, introducing FunctionDefinition to the collectiontree will trigger indirect api breaches for the compat property setup we have in place to support node.CollectorClass im unwilling to spend a hard to estimate amount of time on a feature that is indeed deprecated since years and will be removed in near future, so i rather want it gone and out of the way now so i can actually work on structral cleanup of things that will stay rather than resurrecting the dead. i propose we prepare an actual breraking release since its about time for that since quite a while. -- Ronny From opensource at ronnypfannschmidt.de Wed Nov 7 04:11:42 2018 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Wed, 07 Nov 2018 10:11:42 +0100 Subject: [pytest-dev] another "i have had it moment" and a stern request ro review our interaction with backward compatibility Message-ID: Hi everyone, a few days i was trying to replicate an issue in the python shell, and quickly realized, that outside of actually doing a complete pytest.main invocation there is simply no practical and sane way to get a config object that is not in a utterly broken unusable state to begin with. Again and again i keep running into things that have deep and nastyly hidden dependencies that are seemingly impossible to resolve. And we get clear resutls from that - again and again certain features simply cant be implemented or fearlessly delivered as the shoddy house of cards falls appart with spooky actions at a distance. Be it marks that smear over class hierachies or fixture definitions that blow up for undiscoverable reasons when trying to introduce the multi scope fixture system. Again and again many of us run into massive impediments when trying to develop features simply for strange actions at distance. This is an accumulative cost in many ways - in particular for a project driven primarily by volunteers - every hour we sacrafice to this altar of technical debt is an hour lost for improving the project and/or working on actual features. >From my perspective this issue directly grows out of driving a large part of pytests development by examples and tests, but precluding stepping back and doing actual design. The history of marks makes a perfect example of such an horror storry. Each iteration adding a new minimal element while adding a huge factor to the structural error as it grew. I really want to hammer down there that "minimal" is very different from "minimal viable" - leaving design uncontested for too long is an ramp up for unsustainable technical debt. Its aslo critical to note that for **me** there is a inherent dishonesty in trying to stay backward compatible and not putting forward a design and development process that deeply supports it - right now we can observe a state of fragility from pytest where it feels like every feature release triggers some regression - while at the same time we keep and keep shipping features that are structurally and fundamentally broken since years (yield tests, config init, ...). This setup, which gives me the impression it is "designed" to make the project fail its user (aka its broken to begin with and now it will break some more), is a massive emotional drain. It painfully twists around the sense of responsibility simply due to the perceived inherent base-level of failure - and **I** want to do and feel better. However with the current flow of releases and with our backward compatibility policies in place i am under a very general impression that i cant really do anything about it, and even if i try it would drag on for years to generate even basic positive results - this impression is a killer to my motivation - as it **feels** like it would take years to even get a initial iteration out to the users - and the process of fixing the issues in general would drag on over not only years - but decades. A timeflow like that would commpletely disconnect me from perceptions of reward or archivement - in turn making it even less likely to succeed or even start. This is a open source project that volunteer driven - fixing deeper issues should connect to feeling an archivement - but with out current setup what seems to be in for **me** is more like dread, fear and depression - a general defeat. Thats not something i want to allow anymore. **I** want to feel good about my work on pytest. **I** want to feel the archivements i have on pytest. and because of that **I** have to make sure the project can support that. So **I** want to invite all of you, Lets make pytest a project again where * we claim suport for backward compatibility and our actions and results show for it * we can enjoy the act of adding new features and enhancing the ecosystem * we can have better and quicker feedback, not just from the fabulous people that work on it - but also the users. **I** strongly beleive that this is doable, but it will require cutting some bad ends. We need to enhance layering, it doesnt have to be perfect but we do have to be able to keep things appart sanely and we need to have objects in valid states per default (invalid states should only be possible deliberately, not accidentially) We need to talk/write about design more - the difference between minimal and viable after all only shows itself in the heat and fruction of different perspectives and oppinions clashing. We need a conversation and interaction with our advanced users, so they dont end up on old and dead pytest versions (like pypy for example). We need a pervasive chain reason to bring trough the period of papercuts where we do shift around layering so the ecosystem can keep up (saving the structural integrity of pytest at the expense of destroying the ecosystem would be a dissaster). of course there is a obligatory white on red "make pytest great again" cap in planning ;P -- Ronny From nicoddemus at gmail.com Wed Nov 7 06:28:30 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Wed, 7 Nov 2018 09:28:30 -0200 Subject: [pytest-dev] breaking releases required - sorting out FunctionDefinition and Compatproperties In-Reply-To: <4617e54065c65bd5ac16bd08037dc76fdef1e450.camel@ronnypfannschmidt.de> References: <4617e54065c65bd5ac16bd08037dc76fdef1e450.camel@ronnypfannschmidt.de> Message-ID: Hi Ronny, On Wed, Nov 7, 2018 at 6:26 AM Ronny Pfannschmidt < opensource at ronnypfannschmidt.de> wrote: > > i propose we prepare an actual breraking release since its about time > for that since quite a while. > Sure, it has been awhile and the features have been deprecated for a long time. I think we can make a 4.0 release right after 3.10.1. Then right after that we can remove that functionality from `features` and you can start working on the FunctionDefinition. Thoughts? Cheers, Bruno > > > -- 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 opensource at ronnypfannschmidt.de Wed Nov 7 07:08:10 2018 From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt) Date: Wed, 7 Nov 2018 13:08:10 +0100 Subject: [pytest-dev] breaking releases required - sorting out FunctionDefinition and Compatproperties In-Reply-To: References: <4617e54065c65bd5ac16bd08037dc76fdef1e450.camel@ronnypfannschmidt.de> Message-ID: <4c41b603-cd12-0613-88b6-8d5f799511a1@ronnypfannschmidt.de> Hi Bruno, that would definitively be a good start, but as i outlined in the other mail i believe there is a bit more work to do as well. regards, Ronny On 07.11.2018 12:28, Bruno Oliveira wrote: > Hi Ronny, > > On Wed, Nov 7, 2018 at 6:26 AM Ronny Pfannschmidt > >? > wrote: > > > i propose we prepare an actual breraking release since its about time > for that since quite a while. > > > Sure, it has been awhile and the features have been deprecated for a > long time. I think we can make a 4.0 release right after 3.10.1. Then > right after that we can remove that functionality from `features` and > you can start working on the FunctionDefinition.? > > Thoughts? > > Cheers, > Bruno > > > > > -- Ronny > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > From nicoddemus at gmail.com Wed Nov 7 14:55:54 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Wed, 7 Nov 2018 17:55:54 -0200 Subject: [pytest-dev] another "i have had it moment" and a stern request ro review our interaction with backward compatibility In-Reply-To: References: Message-ID: Hi Ronny, On Wed, Nov 7, 2018 at 7:12 AM Ronny Pfannschmidt < opensource at ronnypfannschmidt.de> wrote: > > ... > > This is an accumulative cost in many ways - in particular for a project > driven primarily by volunteers - every hour we sacrafice to this altar > of technical debt is an hour lost for improving the project and/or > working on actual features. > I feel your frustration. I agree that the pytest codebase needs some refactorings in order for it to be maintainable and allow us to move forward. >From my perspective this issue directly grows out of driving a large > part of pytests development by examples and tests, but precluding > stepping back and doing actual design. > > The history of marks makes a perfect example of such an horror storry. > Each iteration adding a new minimal element while adding a huge factor > to the structural error as it grew. > What I think often happens is that we can't foresee that a minimal increment might lead to a large technical debt in the future. Once we put something in the open, we try very hard to not change that behavior (even if considered incorrect now), which is the main point of your email. > I really want to hammer down there that "minimal" is very different > from "minimal viable" - leaving design uncontested for too long is an > ramp up for unsustainable technical debt. > > Its aslo critical to note that for **me** there is a inherent > dishonesty in trying to stay backward compatible and not putting > forward a design and development process that deeply supports it - > right now we can observe a state of fragility from pytest where it > feels like every feature release triggers some regression - while at > the same time we keep and keep shipping features that are structurally > and fundamentally broken since years (yield tests, config init, ...). > I agree about the fact that every feature release we end up breaking something unintentionally. Of course that sometimes will happen, but I feel that happens more often in the murky areas of the code which have grown organically over the years. This setup, which gives me the impression it is "designed" to make the > project fail its user (aka its broken to begin with and now it will > break some more), is a massive emotional drain. It painfully twists > around the sense of responsibility simply due to the perceived inherent > base-level of failure - and **I** want to do and feel better. > > However with the current flow of releases and with our backward > compatibility policies in place i am under a very general impression > that i cant really do anything about it, and even if i try it would > drag on for years to generate even basic positive results - this > impression is a killer to my motivation - as it **feels** like it would > take years to even get a initial iteration out to the users - and the > process of fixing the issues in general would drag on over not only > years - but decades. > > A timeflow like that would commpletely disconnect me from perceptions > of reward or archivement - in turn making it even less likely to > succeed or even start. > About our backward compatibility policies, we don't have any minimal time restriction for major releases, we only state that we will issue deprecation warnings for two feature releases before actually changing/removing a feature. Having said that, I see that it is possible for us to have major releases more often (a few per year even). As we have learned already, frequent releases which cause few incompatibilities are preferred over infrequent releases which cause a lot of incompatibilities, as it will affect less users and makes it easy to pin point problems. My gut feeling is that those backward incompatible releases won't be that bad in the end: we only change little used features or porting the code to the new way of doing things is easy to apply to existing code. Of course some friction always happen. Dragging deprecated features over many releases, specially if they get in the way of new implementations, is a certain way to needlessly increase the burden of us maintainers, as you point out. > This is a open source project that volunteer driven - fixing deeper > issues should connect to feeling an archivement - but with out current > setup what seems to be in for **me** is more like dread, fear and > depression - a general defeat. > > Thats not something i want to allow anymore. > > **I** want to feel good about my work on pytest. > **I** want to feel the archivements i have on pytest. > > and because of that > > **I** have to make sure the project can support that. > > So **I** want to invite all of you, > > > Lets make pytest a project again where > > * we claim suport for backward compatibility and our actions and > results show for it > * we can enjoy the act of adding new features and enhancing the > ecosystem > * we can have better and quicker feedback, not just from the fabulous > people that work on it - but also the users. > > > **I** strongly beleive that this is doable, but it will require cutting > some bad ends. > > We need to enhance layering, it doesnt have to be perfect but we do > have to be able to keep things appart sanely and we need to have > objects in valid states per default (invalid states should only be > possible deliberately, not accidentially) > > We need to talk/write about design more - the difference between > minimal and viable after all only shows itself in the heat and fruction > of different perspectives and oppinions clashing. > > We need a conversation and interaction with our advanced users, so they > dont end up on old and dead pytest versions (like pypy for example). > > We need a pervasive chain reason to bring trough the period of > papercuts where we do shift around layering so the ecosystem can keep > up (saving the structural integrity of pytest at the expense of > destroying the ecosystem would be a dissaster). > I agree with the points above Ronny, let's make it happen. :) Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at ronnypfannschmidt.de Wed Nov 7 15:56:24 2018 From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt) Date: Wed, 7 Nov 2018 21:56:24 +0100 Subject: [pytest-dev] Deprecating "calling" Nodes Message-ID: <3e93a3d9-d75b-7706-2c05-edf36bb8419f@ronnypfannschmidt.de> Hi everyone, i'm facing a really harsh dilemma with the the way we initialize Nodes and their subclasses the __init__ methods are just plain "wrong" in terms of doing a lot of logic and "Magically" putting things in place. this makes both structural changes and porting to attrs practically impossible In order to elevate this structural problem i'd like to sort out the way we invoke them and deprecate calling them main reason being that if direct "calling" is no longer valid behavior for clients and down streams, the logic can be moved to more controllable and testable places in order to facilitate this, i'd create a NodeMetaClass? which has support methods for instance creation and allows for custom functions/methods to be called. -- Ronny From oliver at bestwalter.de Wed Nov 7 16:34:09 2018 From: oliver at bestwalter.de (Oliver Bestwalter) Date: Wed, 7 Nov 2018 22:34:09 +0100 Subject: [pytest-dev] another "i have had it moment" and a stern request ro review our interaction with backward compatibility In-Reply-To: References: Message-ID: Hi Ronny, I'd like to add my 2 cents from the perspective of an enthusiastic pytest user, who dabbles in a lot of projects using pytest and who occasionally teaches it: I use pytest since 2010 and can still remember a time when I was able to trigger the dreaded quite regularly and it was often really hard for me to figure out what went wrong, leading to arcane workarounds in my test suites. Since I am a bit involved in the project and pay more attention, I remember * one incident where I triggered an INTERNAL error during normal usage in a fresh release and the problem was easy to spot and fix ( https://github.com/pytest-dev/pytest/issues/2788). * one breaking change that was also easy to fix: the change in the logging behaviour and that was also perfectly o.k. because bottom line is that the logging behaviour overall now is far better because of this * one hard to reproduce race condition due to the introduction of tmp_path (thanks for that btw), which also was fixed faster than I was even able to find some time to have a closer look ( https://github.com/pytest-dev/pytest/issues/4181). All in all pretty painless and easy to work around and usually fixed really quickly. In my experience the subset of functionality/plugins that by far the most test suites use are rock solid, have a good API and hardly ever break. Also: the quality of the "user experience" and the documentation has improved vastly in the last few years. Just today I had the chance to pair program some tests to introduce a colleague to pytest. Seeing the expression of delight in their face, when they realized how easy it is to get started and when they started to comprehend the power of fixtures and parametrization is priceless. Long story short: you folks are amazing and pytest is something to be extremely proud of despite all the pain that is always involved when trying to pay off technical debt without breaking the word. The release automation that is in place now makes more frequent releases easier and from my own experience I agree with Brunos suggestion to make even more frequent releases that contain smaller changesets and also to not shy away from more frequent major releases, if that makes the transition easier. Thanks that you care and thanks for all your work Oliver On Wed, 7 Nov 2018 at 20:56 Bruno Oliveira wrote: > Hi Ronny, > > On Wed, Nov 7, 2018 at 7:12 AM Ronny Pfannschmidt < > opensource at ronnypfannschmidt.de> wrote: > >> >> ... > > >> >> This is an accumulative cost in many ways - in particular for a project >> driven primarily by volunteers - every hour we sacrafice to this altar >> of technical debt is an hour lost for improving the project and/or >> working on actual features. >> > > I feel your frustration. I agree that the pytest codebase needs some > refactorings in order for it to be maintainable and allow us to move > forward. > > From my perspective this issue directly grows out of driving a large >> part of pytests development by examples and tests, but precluding >> stepping back and doing actual design. >> >> The history of marks makes a perfect example of such an horror storry. >> Each iteration adding a new minimal element while adding a huge factor >> to the structural error as it grew. >> > > What I think often happens is that we can't foresee that a minimal > increment might lead to a large technical debt in the future. Once we put > something in the open, we try very hard to not change that behavior (even > if considered incorrect now), which is the main point of your email. > > >> I really want to hammer down there that "minimal" is very different >> from "minimal viable" - leaving design uncontested for too long is an >> ramp up for unsustainable technical debt. >> >> Its aslo critical to note that for **me** there is a inherent >> dishonesty in trying to stay backward compatible and not putting >> forward a design and development process that deeply supports it - >> right now we can observe a state of fragility from pytest where it >> feels like every feature release triggers some regression - while at >> the same time we keep and keep shipping features that are structurally >> and fundamentally broken since years (yield tests, config init, ...). >> > > I agree about the fact that every feature release we end up breaking > something unintentionally. Of course that sometimes will happen, but I feel > that happens more often in the murky areas of the code which have grown > organically over the years. > > This setup, which gives me the impression it is "designed" to make the >> project fail its user (aka its broken to begin with and now it will >> break some more), is a massive emotional drain. It painfully twists >> around the sense of responsibility simply due to the perceived inherent >> base-level of failure - and **I** want to do and feel better. >> >> However with the current flow of releases and with our backward >> compatibility policies in place i am under a very general impression >> that i cant really do anything about it, and even if i try it would >> drag on for years to generate even basic positive results - this >> impression is a killer to my motivation - as it **feels** like it would >> take years to even get a initial iteration out to the users - and the >> process of fixing the issues in general would drag on over not only >> years - but decades. >> >> A timeflow like that would commpletely disconnect me from perceptions >> of reward or archivement - in turn making it even less likely to >> succeed or even start. >> > > About our backward compatibility policies, we don't have any minimal time > restriction for major releases, we only state that we will issue > deprecation warnings for two feature releases before actually > changing/removing a feature. > > Having said that, I see that it is possible for us to have major releases > more often (a few per year even). As we have learned already, frequent > releases which cause few incompatibilities are preferred over infrequent > releases which cause a lot of incompatibilities, as it will affect less > users and makes it easy to pin point problems. > > My gut feeling is that those backward incompatible releases won't be that > bad in the end: we only change little used features or porting the code to > the new way of doing things is easy to apply to existing code. Of course > some friction always happen. > > Dragging deprecated features over many releases, specially if they get in > the way of new implementations, is a certain way to needlessly increase the > burden of us maintainers, as you point out. > > >> This is a open source project that volunteer driven - fixing deeper >> issues should connect to feeling an archivement - but with out current >> setup what seems to be in for **me** is more like dread, fear and >> depression - a general defeat. >> >> Thats not something i want to allow anymore. >> >> **I** want to feel good about my work on pytest. >> **I** want to feel the archivements i have on pytest. >> >> and because of that >> >> **I** have to make sure the project can support that. >> >> So **I** want to invite all of you, >> >> >> Lets make pytest a project again where >> >> * we claim suport for backward compatibility and our actions and >> results show for it >> * we can enjoy the act of adding new features and enhancing the >> ecosystem >> * we can have better and quicker feedback, not just from the fabulous >> people that work on it - but also the users. >> >> >> **I** strongly beleive that this is doable, but it will require cutting >> some bad ends. >> >> We need to enhance layering, it doesnt have to be perfect but we do >> have to be able to keep things appart sanely and we need to have >> objects in valid states per default (invalid states should only be >> possible deliberately, not accidentially) >> >> We need to talk/write about design more - the difference between >> minimal and viable after all only shows itself in the heat and fruction >> of different perspectives and oppinions clashing. >> >> We need a conversation and interaction with our advanced users, so they >> dont end up on old and dead pytest versions (like pypy for example). >> >> We need a pervasive chain reason to bring trough the period of >> papercuts where we do shift around layering so the ecosystem can keep >> up (saving the structural integrity of pytest at the expense of >> destroying the ecosystem would be a dissaster). >> > > I agree with the points above Ronny, let's make it happen. :) > > Cheers, > Bruno. > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Wed Nov 7 16:41:01 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Wed, 7 Nov 2018 19:41:01 -0200 Subject: [pytest-dev] Deprecating "calling" Nodes In-Reply-To: <3e93a3d9-d75b-7706-2c05-edf36bb8419f@ronnypfannschmidt.de> References: <3e93a3d9-d75b-7706-2c05-edf36bb8419f@ronnypfannschmidt.de> Message-ID: Hi Ronny, On Wed, Nov 7, 2018 at 6:56 PM RonnyPfannschmidt < opensource at ronnypfannschmidt.de> wrote: > main reason being that if direct "calling" is no longer valid behavior > for clients and down streams, the logic can be moved to more > controllable and testable places > > > in order to facilitate this, i'd create a NodeMetaClass which has > support methods for instance creation and > allows for custom functions/methods to be called. > Makes sense, I like the general idea. Could you please post a quick example to illustrate what you mean? Doesn't need to be working code. Also you mean to use classmethods for instance creation? Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.marie at se.com Thu Nov 8 03:56:06 2018 From: sylvain.marie at se.com (Sylvain MARIE) Date: Thu, 8 Nov 2018 08:56:06 +0000 Subject: [pytest-dev] another "i have had it moment" and a stern request ro review our interaction with backward compatibility In-Reply-To: References: Message-ID: Hi all I could not agree more with Oliver - I discovered pytest two years ago and it was really a "wow' moment - I quickly moved away from NoseTest :) Parameters and Fixtures are to me THE features that makes it so powerful and easy to use, and that enable anyone to invent new usage patterns that others did not even think about before. The issue for new users especially the ones coming from traditional unit testing (e.g. junit) is that it is quite difficult to understand how powerful they are at first glance. It is however very easy to "pre-bundle" usage patterns with more user-friendly names. That's what I did with pytest-cases and pytest-steps (with the help of the great 'decorator' lib to manipulate the signatures a bit). This de-coupling between a very compact and generic core (with the smallest possible amount of API and functionality to ensure maintainability), and multiple, composable, "usage-oriented" plugins, seems to me the best reasonable long-term choice. Of course that does not prevent doing a bit of cleaning and design improvement in the internals, to improve its compactness. Best; -- Sylvain De?: pytest-dev [mailto:pytest-dev-bounces+sylvain.marie=se.com at python.org] De la part de Oliver Bestwalter Envoy??: mercredi 7 novembre 2018 22:34 ??: Bruno Oliveira Cc?: pytest-dev at python.org Objet?: Re: [pytest-dev] another "i have had it moment" and a stern request ro review our interaction with backward compatibility [External email: Use caution with links and attachments] ________________________________________ ? Hi Ronny, I'd like to add my 2 cents from the perspective of an enthusiastic pytest user, who dabbles in a lot of projects using pytest and who occasionally teaches it: I use pytest since 2010 and can still remember a time when I was able to trigger the dreaded quite regularly and it was often really hard for me to figure out what went wrong, leading to arcane workarounds in my test suites. Since I am a bit involved in the project and pay more attention, I remember * one incident where I triggered an INTERNAL error during normal usage in a fresh release and the problem was easy to spot and fix (https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpytest-dev%2Fpytest%2Fissues%2F2788&data=02%7C01%7Csylvain.marie%40se.com%7C59e7ab289a2a4698bc9208d644f8fa26%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636772233479207352&sdata=%2BuNmxKZxmKNgLJ9eWFPvzL1C2fZpES9MGxYEiDp11ak%3D&reserved=0). * one breaking change that was also easy to fix: the change in the logging behaviour and that was also perfectly o.k. because bottom line is that the logging behaviour overall now is far better because of this * one hard to reproduce race condition due to the introduction of tmp_path (thanks for that btw), which also was fixed faster than I was even able to find some time to have a closer look (https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpytest-dev%2Fpytest%2Fissues%2F4181&data=02%7C01%7Csylvain.marie%40se.com%7C59e7ab289a2a4698bc9208d644f8fa26%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636772233479217361&sdata=9wKOnAy1azrWVCvHxHWOjN4SETPmZD3XGvQk%2BpbOXhs%3D&reserved=0). All in all pretty painless and easy to work around and usually fixed really quickly. In my experience the subset of functionality/plugins that by far the most test suites use are rock solid, have a good API and hardly ever break. Also: the quality of the "user experience" and the documentation has improved vastly in the last few years. Just today I had the chance to pair program some tests to introduce a colleague to pytest. Seeing the expression of delight in their face, when they realized how easy it is to get started and when they started to comprehend the power of fixtures and parametrization is priceless. Long story short: you folks are amazing and pytest is something to be extremely proud of despite all the pain that is always involved when trying to pay off technical debt without breaking the word. The release automation that is in place now makes more frequent releases easier and from my own experience I agree with Brunos suggestion to make even more frequent releases that contain smaller changesets and also to not shy away from more frequent major releases, if that makes the transition easier. Thanks that you care and thanks for all your work Oliver On Wed, 7 Nov 2018 at 20:56 Bruno Oliveira wrote: Hi Ronny, On Wed, Nov 7, 2018 at 7:12 AM Ronny Pfannschmidt wrote: ... This is an accumulative cost in many ways - in particular for a project driven primarily by volunteers - every hour we sacrafice to this altar of technical debt is an hour lost for improving the project and/or working on actual features. I feel your frustration. I agree that the pytest codebase needs some refactorings in order for it to be maintainable and allow us to move forward. From my perspective this issue directly grows out of driving a large part of pytests development by examples and tests, but precluding stepping back and doing actual design. The history of marks makes a perfect example of such an horror storry. Each iteration adding a new minimal element while adding a huge factor to the structural error as it grew. What I think often happens is that we can't foresee that a minimal increment might lead to a large technical debt in the future. Once we put something in the open, we try very hard to not change that behavior (even if considered incorrect now), which is the main point of your email. ? I really want to hammer down there that "minimal" is very different from "minimal viable" - leaving design uncontested for too long is an ramp up for unsustainable technical debt. Its aslo critical to note that for **me** there is a inherent dishonesty in trying to stay backward compatible and not putting forward a design and development process that deeply supports it - right now we can observe a state of fragility from pytest where it feels like every feature release triggers some regression - while at the same time we keep and keep shipping features that are structurally and fundamentally broken since years (yield tests, config init, ...). I agree about the fact that every feature release we end up breaking something unintentionally. Of course that sometimes will happen, but I feel that happens more often in the murky areas of the code which have grown organically over the years.? This setup, which gives me the impression it is "designed" to make the project fail its user (aka its broken to begin with and now it will break some more), is a massive emotional drain. It painfully twists around the sense of responsibility simply due to the perceived inherent base-level of failure - and **I** want to do and feel better. However with the current flow of releases and with our backward compatibility policies in place i am under a very general impression that i cant really do anything about it, and even if i try it would drag on for years to generate even basic positive results - this impression is a killer to my motivation - as it **feels** like it would take years to even get a initial iteration out to the users - and the process of fixing the issues in general would drag on over not only years - but decades. A timeflow like that would commpletely disconnect me from perceptions of reward or archivement? - in turn making it even less likely to succeed or even start. About our backward compatibility policies, we don't have any minimal time restriction for major releases, we only state that we will issue deprecation warnings for two feature releases before actually changing/removing a feature. Having said that, I see that it is possible for us to have major releases more often (a few per year even). As we have learned already, frequent releases which cause few incompatibilities are preferred over infrequent releases which cause a lot of incompatibilities, as it will affect less users and makes it easy to pin point problems. My gut feeling is that those backward incompatible releases won't be that bad in the end: we only change little used features or porting the code to the new way of doing things is easy to apply to existing code. Of course some friction always happen. Dragging deprecated features over many releases, specially if they get in the way of new implementations, is a certain way to needlessly increase the burden of us maintainers, as you point out. ? This is a open source project that volunteer driven - fixing deeper issues should connect to feeling an archivement - but with out current setup what seems to be in for **me** is more like dread, fear and depression - a general defeat. Thats not something i want to allow anymore. **I** want to feel good about my work on pytest. **I** want to feel the archivements i have on pytest. and because of that **I** have to make sure the project can support that. So **I** want to invite all of you, Lets make pytest a project again where * we claim suport for backward compatibility and our actions and results show for it * we can enjoy the act of adding new features and enhancing the ecosystem * we can have better and quicker feedback, not just from the fabulous people that work on it - but also the users. **I** strongly beleive that this is doable, but it will require cutting some bad ends. We need to enhance layering, it doesnt have to be perfect but we do have to be able to keep things appart sanely and we need to have objects in valid states per default (invalid states should only be possible deliberately, not accidentially) We need to talk/write about design more - the difference between minimal and viable after all only shows itself in the heat and fruction of different perspectives and oppinions clashing. We need a conversation and interaction with our advanced users, so they dont end up on old and dead pytest versions (like pypy for example). We need a pervasive chain reason to bring trough the period of papercuts where we do shift around layering so the ecosystem can keep up (saving the structural integrity of pytest at the expense of destroying the ecosystem would be a dissaster). I agree with the points above Ronny, let's make it happen. :) Cheers, Bruno. _______________________________________________ pytest-dev mailing list mailto:pytest-dev at python.org https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpytest-dev&data=02%7C01%7Csylvain.marie%40se.com%7C59e7ab289a2a4698bc9208d644f8fa26%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636772233479217361&sdata=dHBvhBLA60OOzRjx3TI4bHZFtLxmdhwactGyJehyWe0%3D&reserved=0 ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. ______________________________________________________________________ From nicoddemus at gmail.com Sun Nov 11 12:37:08 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Sun, 11 Nov 2018 15:37:08 -0200 Subject: [pytest-dev] pytest 3.10.1 released Message-ID: pytest 3.10.1 has just been released to PyPI. This is a bug-fix release, being a drop-in replacement. To upgrade:: pip install --upgrade pytest The full changelog is available at https://docs.pytest.org/en/latest/changelog.html. Thanks to all who contributed to this release, among them: * Anthony Sottile * Boris Feld * Bruno Oliveira * Daniel Hahler * Fabien ZARIFIAN * Jon Dufresne * Ronny Pfannschmidt Happy testing, The pytest Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilya.kazakevich at jetbrains.com Tue Nov 13 17:19:25 2018 From: ilya.kazakevich at jetbrains.com (Ilya Kazakevich) Date: Wed, 14 Nov 2018 01:19:25 +0300 Subject: [pytest-dev] pyi stubs (PEP 561/ PEP-484) for pytest Message-ID: Hello, My name is Ilya, I develop pytest integration in PyCharm IDE. There is a PEP-484 that covers optional type hinting for Python an PEP-561 that describes how to distribute this information as separate package with .pyi files (also called stubs). Type hinting is huge benefit for any static analysis tool. At this moment it is suported by mypy (http://mypy-lang.org/) and PyCharm. My question is do you have any plans to create pyi stubs for pytest? .pyi will improve code insight / code completion in PyCharm and give users ability to validate their code with mypy. We can create this package by ourselves (physically we create pytest-subs package on pypi, see PEP-561) but at least we need approvement from pytest devs, and any contributions are welcome) Creating pyi files is not hard, and they could be used by any PEP-561 compatible project. Ilya. -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Wed Nov 14 01:01:01 2018 From: me at the-compiler.org (Florian Bruhin) Date: Wed, 14 Nov 2018 07:01:01 +0100 Subject: [pytest-dev] pyi stubs (PEP 561/ PEP-484) for pytest In-Reply-To: References: Message-ID: <20181114060101.z2kdwg5pn3ifrclf@hooch.localdomain> Hey Ilya, On Wed, Nov 14, 2018 at 01:19:25AM +0300, Ilya Kazakevich wrote: > My name is Ilya, I develop pytest integration in PyCharm IDE. Yay, thanks for that! \o/ > There is a PEP-484 that covers optional type hinting for Python an > PEP-561 that describes how to distribute this information as separate > package with .pyi files (also called stubs). > > Type hinting is huge benefit for any static analysis tool. At this moment > it is suported by mypy (http://mypy-lang.org/) and PyCharm. > > My question is do you have any plans to create pyi stubs for pytest? > .pyi will improve code insight / code completion in PyCharm and give > users ability to validate their code with mypy. There's an issue about it with some discussion here: https://github.com/pytest-dev/pytest/issues/3342 > We can create this package by ourselves (physically we create > pytest-subs package on pypi, see PEP-561) but at least we need > approvement from pytest devs, and any contributions are welcome) > > Creating pyi files is not hard, and they could be used by any PEP-561 > compatible project. As usual for volunteer-driven projects, it's hard to find the time to do things if nobody feels like picking it up ;-) I think contributions would definitely be welcome, though it probably needs some coordination with pytest's core, as some classes you'd probably want to use in annotations aren't exposed publicly. Another possibility, if JetBrains is open to that kind of thing, is contracting a pytest core developer to work on type annotations specificially via merlinux: https://merlinux.eu/ FWIW, as for me personally, I'm currently quite busy with study-related work[1], so I'm not doing much pytest-related work at the moment. Florian [1] https://lists.schokokeks.org/pipermail/qutebrowser-announce/2018-September/000051.html -- https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From they4kman at gmail.com Wed Nov 14 02:20:15 2018 From: they4kman at gmail.com (Zach Kanzler) Date: Wed, 14 Nov 2018 02:20:15 -0500 Subject: [pytest-dev] another "i have had it moment" and a stern request ro review our interaction with backward compatibility In-Reply-To: References: Message-ID: Hi, y'all! I share a similar sentiment as Oliver and Sylvain ? pytest has changed my life so much for the better, and I don't have a difficult time showing others how dead simple it is to get started. Like Sylvain said: it's a tad more difficult to show the power of fixtures at first glance, but the mark of a great tool is how it develops alongside one's understanding of it. And also, I've bundled a bunch of great fixtures together in a mixin to make DRF API testing sexy. It's been a breeze. I would hope the ease of using pytest would extend to its own development. I've put in my own fair share of workarounds and hackaroos ? honestly, I loved pytest so much I never stopped to consider whether the internals might be disorganized; I just merrily went on my way. But hearing there may not have been more formal design kinda fits the bill :P I think Sylvain hit a great point: fixtures and parametrization are the killer features to me as well. Though I might be inconvenienced if I have to change a bunch of hacks just so I can upgrade to a new pytest version which fixes a bug I experience, it's as I interpret you say, Ronny: having a clean, minimal, hopefully-globally-consistent API is such a pleasure to work with, and has the side benefit that conversations with it needn't be hours-long. "Hmm, I have to do X. I thiiiiiink that would be *here*. Oh, hell yeah! That's where it was." Not only do you spend less time battling, but ya feel more powerful ? when the limit's of pytest's default features are reached, instead of wondering what testing compromise is reasonable, one can immediately reach for a plugin touching deep internals. On the volunteer contributions point: I don't feel so held back from contributing now, after reading this email chain, but I used to hold back from even considering pull requests, because the code seemed dense and wandering and wavering at times... yet pytest works so wonderfully for me, so I figured there must be a reason to the rhyme. I presumed there was a grander design at play ? one I might hinder by becoming a triage/review burden. The documentation *has* become fantastic. At times I've found examples of flows I'd never even considered trying, which have become routine to me now. The documentation has one advantage over releases: no one's losing hair over publishing documentation. When it's possible to experiment ? when worries over the past don't consume the present, it's strange how things improve. We've all had those friends who seem content to stay their same miserable selves, year after year. Some of us may have even had those friends who have a new "thing" every time you see them. I'll hold off on examples there, 'cause I'm sure to offend someone when it ain't the point :P "Backwards compatibility" is a great ideal, but even Microsoft cut the cord at a point. It can't hinder progress, lest a project stall for all eternity ? not just due to appeasing that ideal, but for your reasons, Ronny: it's demotivating. It seems to me that forward, even breaking movement is the only way to reach eventual consistency... so long as a "fuck you, old fogeys" doesn't cause all nodes to disconnect? er, as long as a sudden breaking change with no recourse causes all users to jump ship. Anyway, I can't undersell how much pytest has changed my philosophy of development. Because of pytest, I'm able to teach newer devs testing not as "writing tests", but as "describing how things work, in Python". So little needs explaining to kindle the spark. I don't want pytest's spark to die out because 80 million use cases must be appeased. The past is just a goodbye. That's my two dollars Zanch "they4kman" Kranzanzler On Thu, Nov 8, 2018 at 3:56 AM Sylvain MARIE wrote: > Hi all > > I could not agree more with Oliver - I discovered pytest two years ago and > it was really a "wow' moment - I quickly moved away from NoseTest :) > > Parameters and Fixtures are to me THE features that makes it so powerful > and easy to use, and that enable anyone to invent new usage patterns that > others did not even think about before. The issue for new users especially > the ones coming from traditional unit testing (e.g. junit) is that it is > quite difficult to understand how powerful they are at first glance. > > It is however very easy to "pre-bundle" usage patterns with more > user-friendly names. That's what I did with pytest-cases and pytest-steps > (with the help of the great 'decorator' lib to manipulate the signatures a > bit). This de-coupling between a very compact and generic core (with the > smallest possible amount of API and functionality to ensure > maintainability), and multiple, composable, "usage-oriented" plugins, seems > to me the best reasonable long-term choice. Of course that does not prevent > doing a bit of cleaning and design improvement in the internals, to improve > its compactness. > > Best; > > -- > Sylvain > > > De : pytest-dev [mailto:pytest-dev-bounces+sylvain.marie=se.com at python.org] > De la part de Oliver Bestwalter > Envoy? : mercredi 7 novembre 2018 22:34 > ? : Bruno Oliveira > Cc : pytest-dev at python.org > Objet : Re: [pytest-dev] another "i have had it moment" and a stern > request ro review our interaction with backward compatibility > > [External email: Use caution with links and attachments] > ________________________________________ > > Hi Ronny, > > I'd like to add my 2 cents from the perspective of an enthusiastic pytest > user, who dabbles in a lot of projects using pytest and who occasionally > teaches it: > > I use pytest since 2010 and can still remember a time when I was able to > trigger the dreaded quite regularly and it was often really > hard for me to figure out what went wrong, leading to arcane workarounds in > my test suites. > > Since I am a bit involved in the project and pay more attention, I > remember > > * one incident where I triggered an INTERNAL error during normal usage in > a fresh release and the problem was easy to spot and fix ( > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpytest-dev%2Fpytest%2Fissues%2F2788&data=02%7C01%7Csylvain.marie%40se.com%7C59e7ab289a2a4698bc9208d644f8fa26%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636772233479207352&sdata=%2BuNmxKZxmKNgLJ9eWFPvzL1C2fZpES9MGxYEiDp11ak%3D&reserved=0 > ). > * one breaking change that was also easy to fix: the change in the logging > behaviour and that was also perfectly o.k. because bottom line is that the > logging behaviour overall now is far better because of this > * one hard to reproduce race condition due to the introduction of tmp_path > (thanks for that btw), which also was fixed faster than I was even able to > find some time to have a closer look ( > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpytest-dev%2Fpytest%2Fissues%2F4181&data=02%7C01%7Csylvain.marie%40se.com%7C59e7ab289a2a4698bc9208d644f8fa26%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636772233479217361&sdata=9wKOnAy1azrWVCvHxHWOjN4SETPmZD3XGvQk%2BpbOXhs%3D&reserved=0 > ). > > All in all pretty painless and easy to work around and usually fixed > really quickly. > > In my experience the subset of functionality/plugins that by far the most > test suites use are rock solid, have a good API and hardly ever break. > Also: the quality of the "user experience" and the documentation has > improved vastly in the last few years. > > Just today I had the chance to pair program some tests to introduce a > colleague to pytest. Seeing the expression of delight in their face, when > they realized how easy it is to get started and when they started to > comprehend the power of fixtures and parametrization is priceless. > > Long story short: you folks are amazing and pytest is something to be > extremely proud of despite all the pain that is always involved when trying > to pay off technical debt without breaking the word. > > The release automation that is in place now makes more frequent releases > easier and from my own experience I agree with Brunos suggestion to make > even more frequent releases that contain smaller changesets and also to not > shy away from more frequent major releases, if that makes the transition > easier. > > Thanks that you care and thanks for all your work > Oliver > > On Wed, 7 Nov 2018 at 20:56 Bruno Oliveira > wrote: > Hi Ronny, > On Wed, Nov 7, 2018 at 7:12 AM Ronny Pfannschmidt opensource at ronnypfannschmidt.de> wrote: > > ... > > > This is an accumulative cost in many ways - in particular for a project > driven primarily by volunteers - every hour we sacrafice to this altar > of technical debt is an hour lost for improving the project and/or > working on actual features. > > I feel your frustration. I agree that the pytest codebase needs some > refactorings in order for it to be maintainable and allow us to move > forward. > > From my perspective this issue directly grows out of driving a large > part of pytests development by examples and tests, but precluding > stepping back and doing actual design. > > The history of marks makes a perfect example of such an horror storry. > Each iteration adding a new minimal element while adding a huge factor > to the structural error as it grew. > > What I think often happens is that we can't foresee that a minimal > increment might lead to a large technical debt in the future. Once we put > something in the open, we try very hard to not change that behavior (even > if considered incorrect now), which is the main point of your email. > > I really want to hammer down there that "minimal" is very different > from "minimal viable" - leaving design uncontested for too long is an > ramp up for unsustainable technical debt. > > Its aslo critical to note that for **me** there is a inherent > dishonesty in trying to stay backward compatible and not putting > forward a design and development process that deeply supports it - > right now we can observe a state of fragility from pytest where it > feels like every feature release triggers some regression - while at > the same time we keep and keep shipping features that are structurally > and fundamentally broken since years (yield tests, config init, ...). > > I agree about the fact that every feature release we end up breaking > something unintentionally. Of course that sometimes will happen, but I feel > that happens more often in the murky areas of the code which have grown > organically over the years. > > This setup, which gives me the impression it is "designed" to make the > project fail its user (aka its broken to begin with and now it will > break some more), is a massive emotional drain. It painfully twists > around the sense of responsibility simply due to the perceived inherent > base-level of failure - and **I** want to do and feel better. > > However with the current flow of releases and with our backward > compatibility policies in place i am under a very general impression > that i cant really do anything about it, and even if i try it would > drag on for years to generate even basic positive results - this > impression is a killer to my motivation - as it **feels** like it would > take years to even get a initial iteration out to the users - and the > process of fixing the issues in general would drag on over not only > years - but decades. > > A timeflow like that would commpletely disconnect me from perceptions > of reward or archivement - in turn making it even less likely to > succeed or even start. > > About our backward compatibility policies, we don't have any minimal time > restriction for major releases, we only state that we will issue > deprecation warnings for two feature releases before actually > changing/removing a feature. > > Having said that, I see that it is possible for us to have major releases > more often (a few per year even). As we have learned already, frequent > releases which cause few incompatibilities are preferred over infrequent > releases which cause a lot of incompatibilities, as it will affect less > users and makes it easy to pin point problems. > > My gut feeling is that those backward incompatible releases won't be that > bad in the end: we only change little used features or porting the code to > the new way of doing things is easy to apply to existing code. Of course > some friction always happen. > > Dragging deprecated features over many releases, specially if they get in > the way of new implementations, is a certain way to needlessly increase the > burden of us maintainers, as you point out. > > This is a open source project that volunteer driven - fixing deeper > issues should connect to feeling an archivement - but with out current > setup what seems to be in for **me** is more like dread, fear and > depression - a general defeat. > > Thats not something i want to allow anymore. > > **I** want to feel good about my work on pytest. > **I** want to feel the archivements i have on pytest. > > and because of that > > **I** have to make sure the project can support that. > > So **I** want to invite all of you, > > > Lets make pytest a project again where > > * we claim suport for backward compatibility and our actions and > results show for it > * we can enjoy the act of adding new features and enhancing the > ecosystem > * we can have better and quicker feedback, not just from the fabulous > people that work on it - but also the users. > > > **I** strongly beleive that this is doable, but it will require cutting > some bad ends. > > We need to enhance layering, it doesnt have to be perfect but we do > have to be able to keep things appart sanely and we need to have > objects in valid states per default (invalid states should only be > possible deliberately, not accidentially) > > We need to talk/write about design more - the difference between > minimal and viable after all only shows itself in the heat and fruction > of different perspectives and oppinions clashing. > > We need a conversation and interaction with our advanced users, so they > dont end up on old and dead pytest versions (like pypy for example). > > We need a pervasive chain reason to bring trough the period of > papercuts where we do shift around layering so the ecosystem can keep > up (saving the structural integrity of pytest at the expense of > destroying the ecosystem would be a dissaster). > > I agree with the points above Ronny, let's make it happen. :) > > Cheers, > Bruno. > _______________________________________________ > pytest-dev mailing list > mailto:pytest-dev at python.org > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpytest-dev&data=02%7C01%7Csylvain.marie%40se.com%7C59e7ab289a2a4698bc9208d644f8fa26%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636772233479217361&sdata=dHBvhBLA60OOzRjx3TI4bHZFtLxmdhwactGyJehyWe0%3D&reserved=0 > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > ______________________________________________________________________ > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Wed Nov 14 05:48:29 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Wed, 14 Nov 2018 08:48:29 -0200 Subject: [pytest-dev] pyi stubs (PEP 561/ PEP-484) for pytest In-Reply-To: References: Message-ID: Hi Ilya, On Tue, Nov 13, 2018 at 8:19 PM Ilya Kazakevich < ilya.kazakevich at jetbrains.com> wrote: > > My name is Ilya, I develop pytest integration in PyCharm IDE. > That's great! I use PyCharm daily and it is an awesome IDE, thanks for all the work. > We can create this package by ourselves (physically we create pytest-subs > package on pypi, > see PEP-561) but at least we need approvement from pytest devs, and any > contributions > are welcome) > I've read PEP-561 and I like the idea of providing .pyi files with pytest itself: having them closer to the code they are in sync with the API, and I think the maintenance would be negligible once the first work is in place as we don't change the API often. One subject in particular is not very clear to me from reading PEP-561: pytest is distributed both as a package (`_pytest`) and a module (`pytest.py`, which exposes the API selectively from `_pytest`). PEP-561 only makes provisions for package-distributed libraries. Anybody know how would could distribute the .pyi files following pytest's source layout? So from my POV, if somebody wants to provide the initial .pyi files and setup, it is easy to maintain them within pytest itself (and it can be dropped in favor of type hints once Python 2 is dropped), so we definitely should accept a PR in that regard IMHO. Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Wed Nov 14 12:21:30 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Wed, 14 Nov 2018 15:21:30 -0200 Subject: [pytest-dev] pytest 4.0.0 released! Message-ID: The pytest team is proud to announce the 4.0.0 release! This version is near identical to 3.10 feature-wise, except now pytest's own deprecated features generate errors, but they can be turned back into warnings as a stop gap measure until 4.1. Users are *strongly* encouraged to take a look at the CHANGELOG for instructions and rationale about the deprecated functionality: https://docs.pytest.org/en/latest/changelog.html For complete documentation, please visit: https://docs.pytest.org/en/latest/ As usual, you can upgrade from PyPI via: pip install -U pytest Thanks to all who contributed to this release! Happy testing, The Pytest Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.marie at se.com Wed Nov 14 12:37:31 2018 From: sylvain.marie at se.com (Sylvain MARIE) Date: Wed, 14 Nov 2018 17:37:31 +0000 Subject: [pytest-dev] pytest-harvest Message-ID: Dear all I am very glad to announce my new plugin pytest-harvest https://smarie.github.io/python-pytest-harvest/ , designed to collect selected fixtures and applicative test results so as to create synthesis tables. A typical use-case (at least the reason why I built it and will use it :) ) is to easily create benchmarks for data science algorithms. I now plan to work on a "pytest-patterns" project that will host reference examples for some design patterns. The example that I want to create first is (how surprising...) a combination of pytest-cases, pytest-steps and pytest-harvest. Maybe at some point I will move the 4 projects under a dedicated "pytest-patterns" github organization, I don't know yet. Best regards and happy pytest 4.x ! (and do not hesitate to provide feedback on the issues page!) Sylvain -----Message d'origine----- De?: pytest-dev [mailto:pytest-dev-bounces+sylvain.marie=se.com at python.org] De la part de Sylvain MARIE Envoy??: lundi 5 novembre 2018 22:26 ??: pytest-dev Objet?: [pytest-dev] parameters and fixtures, storage and benchmarks: feedback appreciated [External email: Use caution with links and attachments] ________________________________ Dear pytest development team In our data science team we develop a lot of machine learning/statistics components and a recurrent need is benchmarking codes against many reference datasets. By benchmarking we often mean "applicative" benchmarking (such as algorithm accuracy), even if execution time may also be looked at as a secondary target. For this reason https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fionelmc%2Fpytest-benchmark&data=02%7C01%7Csylvain.marie%40se.com%7C06866e0d84184e84206708d643653d8e%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636770499433285259&sdata=uXArNxuUZHSIX2mAQYc0NLyDH3xfRVKtwzbTvgVPUP4%3D&reserved=0 does not seem to suit our needs. I developed several versions of a benchmarking toolkit in the past years for this purpose but I managed to port it entirely to pytest, so as to leverage all the great built-in mechanisms (namely, parameters and fixtures). It is mostly for this reason that I broke down the problem into smaller pieces and open-sourced each piece as a separate mechanism. You already know pytest-cases (to separate the test logic from the test cases/datasets) and pytest-steps (to break down the test logic into pieces while keeping it quite readable), the last piece I completed is about storing test results so as to get a true "benchmark" functionality with synthesis reports at the end. I broke down the mechanisms into two parts and would like to have your opinion: - one part will be a decorator for function-scoped fixtures, so as to say "please store all these fixture's instances" (in a dictionary-like storage object under key=test id) - another part will be a special fixture, decorated with the above, allowing people to easily inject "results bags" into their test functions to save results and retrieve them at the end Do you think that this (in particular the first item to store fixture) is compliant with pytest ? From investigating, I found out that params are currently stored in session but not fixtures (purposedly). It therefore seems natural to propose a way for users to store very specific fixtures on a declarative basis. Concerning the place where to store them (the global storage object), I am currently allowing users either to rely on a global variable or on a fixture. Would there be another preferred way to store information in pytest, across all tests ? Of course compliance with pytest-xdist will be a holy grail in the future, I do not want to shoot at it directly but pick the 'least bad' choices. Thanks in advance for your kind review and advices ! Best regards -- Sylvain _______________________________________________ pytest-dev mailing list pytest-dev at python.org https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpytest-dev&data=02%7C01%7Csylvain.marie%40se.com%7C06866e0d84184e84206708d643653d8e%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636770499433295277&sdata=afoCt8lMzAghaNx8NxfEu61CdAICSJX9VTR7LzaYKZw%3D&reserved=0 ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. ______________________________________________________________________ From nicoddemus at gmail.com Fri Nov 23 20:22:33 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Fri, 23 Nov 2018 23:22:33 -0200 Subject: [pytest-dev] pytest 4.0.1 Message-ID: pytest 4.0.1 has just been released to PyPI! This is a bug-fix release, being a drop-in replacement. To upgrade:: pip install --upgrade pytest The full changelog is available at https://docs.pytest.org/en/latest/changelog.html. Thanks to all who contributed to this release, among them: * Anthony Sottile * Bruno Oliveira * Daniel Hahler * Michael D. Hoyle * Ronny Pfannschmidt * Slam Happy testing, The pytest Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilya.kazakevich at jetbrains.com Mon Nov 26 11:41:51 2018 From: ilya.kazakevich at jetbrains.com (Ilya Kazakevich) Date: Mon, 26 Nov 2018 19:41:51 +0300 Subject: [pytest-dev] pyi stubs (PEP 561/ PEP-484) for pytest In-Reply-To: References: Message-ID: Hello Florian, Bruno, We decided to start writing pyi file by ourselves. We'll send you first version for review. > PEP-561 only makes provisions for package-distributed libraries That is correct if you distribute it as part of pytest itself, but separate "pytest-stubs" should work even with module approach. But if you have plans to merge it to the pytest iself, it is better to refactor it to package I think.. Ilya. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronny.pfannschmidt at redhat.com Thu Nov 29 09:57:26 2018 From: ronny.pfannschmidt at redhat.com (Ronny Pfannschmidt) Date: Thu, 29 Nov 2018 15:57:26 +0100 Subject: [pytest-dev] enhancing the assertion rewriting experience with custom integration/workflows Message-ID: Hi everyone, at a project at work which integrates pytest we did build a custom workflow around invoking tests and pytest. This in turn triggers a lot of warnings from the assertion rewriter about things that have been already imported. at first glance fixing this seems rather problematic, as the configuration of the assertion rewriting is deeply bound to the pytest configuration and it seems we cant do something simple and crude like letting a pth file fix the issue. i believe opening up the hooking system could be best done by moving it to a package with some sort of singleton control anyway - then pytest would be just a consumer of that api enabling if not enabled and push in its own "import roots". i'd like ot hear other impressions and ideas on this as well. -- Ronny -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhunt at mozilla.com Fri Nov 30 14:15:21 2018 From: dhunt at mozilla.com (Dave Hunt) Date: Fri, 30 Nov 2018 19:15:21 +0000 Subject: [pytest-dev] Looking for additional maintainers for pytest plugins Message-ID: Due to a change in my role, I?m no longer going to be able to spend as much time as I have with maintaining the plugins listed below. The maintenance burden is very light, and releases are handled through Travis CI. I?ve already had some excellent help from Jim Br?nnlund (BeyondEvil), and have added him as a developer to a few of these. I?d appreciate any additional help from the community to support these plugins, and if you?re aware of somebody who would like to contribute please point them in my direction. https://github.com/pytest-dev/pytest-base-url - A very small plugin, no commits in over a year https://github.com/pytest-dev/pytest-selenium - Jim is a developer, and helps out a lot with this one, he's taken care of much of the recent development and responding to issues https://github.com/pytest-dev/pytest-html - This is probably the most popular plugin I?ve been maintaining, and I think there?s a lot of potential for enhancements (great ideas already in the tracker) https://github.com/pytest-dev/pytest-metadata - Split off as a dependency for pytest-html, relatively small plugin and minimal maintenance needs. Jim is a developer for this plugin too https://github.com/pytest-dev/pytest-variables - Another small plugin with very few maintenance needs https://github.com/pytest-dev/pytest-repeat - I don?t really maintain this one currently, but feel that it?s worth mentioning because I was one of the early contributors I?m happy to answer any questions, and keen to hear any suggestions for handling any handover I?m sure these are in safe hands, and I will continue to use them myself, and promote the use of them to others! Cheers, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From variedthoughts at gmail.com Fri Nov 30 14:41:55 2018 From: variedthoughts at gmail.com (Brian Okken) Date: Fri, 30 Nov 2018 11:41:55 -0800 Subject: [pytest-dev] Looking for additional maintainers for pytest plugins In-Reply-To: References: Message-ID: <11448D37-50E6-410B-B19F-81B736D6D697@gmail.com> Dave, Jim, Would you want this need mentioned on either Test & Code or Python Bytes podcast? I don?t have bandwidth to help out, but perhaps some listeners do. But I don?t want to mention if you?d rather I didn?t. - Brian > On Nov 30, 2018, at 11:15 AM, Dave Hunt wrote: > > Due to a change in my role, I?m no longer going to be able to spend as much time as I have with maintaining the plugins listed below. The maintenance burden is very light, and releases are handled through Travis CI. I?ve already had some excellent help from Jim Br?nnlund (BeyondEvil), and have added him as a developer to a few of these. I?d appreciate any additional help from the community to support these plugins, and if you?re aware of somebody who would like to contribute please point them in my direction. > > https://github.com/pytest-dev/pytest-base-url - A very small plugin, no commits in over a year > https://github.com/pytest-dev/pytest-selenium - Jim is a developer, and helps out a lot with this one, he's taken care of much of the recent development and responding to issues > https://github.com/pytest-dev/pytest-html - This is probably the most popular plugin I?ve been maintaining, and I think there?s a lot of potential for enhancements (great ideas already in the tracker) > https://github.com/pytest-dev/pytest-metadata - Split off as a dependency for pytest-html, relatively small plugin and minimal maintenance needs. Jim is a developer for this plugin too > https://github.com/pytest-dev/pytest-variables - Another small plugin with very few maintenance needs > https://github.com/pytest-dev/pytest-repeat - I don?t really maintain this one currently, but feel that it?s worth mentioning because I was one of the early contributors > > I?m happy to answer any questions, and keen to hear any suggestions for handling any handover > > I?m sure these are in safe hands, and I will continue to use them myself, and promote the use of them to others! > > Cheers, > Dave > _______________________________________________ > 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 aninhacostaribeiro at gmail.com Fri Nov 30 14:51:04 2018 From: aninhacostaribeiro at gmail.com (Ana Ribeiro) Date: Fri, 30 Nov 2018 16:51:04 -0300 Subject: [pytest-dev] Looking for additional maintainers for pytest plugins In-Reply-To: <11448D37-50E6-410B-B19F-81B736D6D697@gmail.com> References: <11448D37-50E6-410B-B19F-81B736D6D697@gmail.com> Message-ID: Hi Dave, I probably have technical knowledge for Pytest-HTML, but I never mantained a popular technical project before. I would be willing to help mantain Pytest-HTML if you could help me for the first weeks. Cheers, Ana > Em 30 de nov de 2018, ?(s) 16:41, Brian Okken escreveu: > > Dave, Jim, > > Would you want this need mentioned on either Test & Code or Python Bytes podcast? > > I don?t have bandwidth to help out, but perhaps some listeners do. But I don?t want to mention if you?d rather I didn?t. > > - Brian > > On Nov 30, 2018, at 11:15 AM, Dave Hunt > wrote: > >> Due to a change in my role, I?m no longer going to be able to spend as much time as I have with maintaining the plugins listed below. The maintenance burden is very light, and releases are handled through Travis CI. I?ve already had some excellent help from Jim Br?nnlund (BeyondEvil), and have added him as a developer to a few of these. I?d appreciate any additional help from the community to support these plugins, and if you?re aware of somebody who would like to contribute please point them in my direction. >> >> https://github.com/pytest-dev/pytest-base-url - A very small plugin, no commits in over a year >> https://github.com/pytest-dev/pytest-selenium - Jim is a developer, and helps out a lot with this one, he's taken care of much of the recent development and responding to issues >> https://github.com/pytest-dev/pytest-html - This is probably the most popular plugin I?ve been maintaining, and I think there?s a lot of potential for enhancements (great ideas already in the tracker) >> https://github.com/pytest-dev/pytest-metadata - Split off as a dependency for pytest-html, relatively small plugin and minimal maintenance needs. Jim is a developer for this plugin too >> https://github.com/pytest-dev/pytest-variables - Another small plugin with very few maintenance needs >> https://github.com/pytest-dev/pytest-repeat - I don?t really maintain this one currently, but feel that it?s worth mentioning because I was one of the early contributors >> >> I?m happy to answer any questions, and keen to hear any suggestions for handling any handover >> >> I?m sure these are in safe hands, and I will continue to use them myself, and promote the use of them to others! >> >> Cheers, >> Dave >> _______________________________________________ >> 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 dhunt at mozilla.com Fri Nov 30 15:35:06 2018 From: dhunt at mozilla.com (Dave Hunt) Date: Fri, 30 Nov 2018 20:35:06 +0000 Subject: [pytest-dev] Looking for additional maintainers for pytest plugins In-Reply-To: <11448D37-50E6-410B-B19F-81B736D6D697@gmail.com> References: <11448D37-50E6-410B-B19F-81B736D6D697@gmail.com> Message-ID: That?s very kind of you Brian, maybe a mention on Twitter would be good, but I don?t think it merits the attention of your podcast listeners (I really enjoyed the latest episode, by the way!) I tried writing a tweet myself, but couldn?t find a satisfying way to word it. :D Cheers, Dave > On 30 Nov 2018, at 19:41, Brian Okken wrote: > > Dave, Jim, > > Would you want this need mentioned on either Test & Code or Python Bytes podcast? > > I don?t have bandwidth to help out, but perhaps some listeners do. But I don?t want to mention if you?d rather I didn?t. > > - Brian > > On Nov 30, 2018, at 11:15 AM, Dave Hunt > wrote: > >> Due to a change in my role, I?m no longer going to be able to spend as much time as I have with maintaining the plugins listed below. The maintenance burden is very light, and releases are handled through Travis CI. I?ve already had some excellent help from Jim Br?nnlund (BeyondEvil), and have added him as a developer to a few of these. I?d appreciate any additional help from the community to support these plugins, and if you?re aware of somebody who would like to contribute please point them in my direction. >> >> https://github.com/pytest-dev/pytest-base-url - A very small plugin, no commits in over a year >> https://github.com/pytest-dev/pytest-selenium - Jim is a developer, and helps out a lot with this one, he's taken care of much of the recent development and responding to issues >> https://github.com/pytest-dev/pytest-html - This is probably the most popular plugin I?ve been maintaining, and I think there?s a lot of potential for enhancements (great ideas already in the tracker) >> https://github.com/pytest-dev/pytest-metadata - Split off as a dependency for pytest-html, relatively small plugin and minimal maintenance needs. Jim is a developer for this plugin too >> https://github.com/pytest-dev/pytest-variables - Another small plugin with very few maintenance needs >> https://github.com/pytest-dev/pytest-repeat - I don?t really maintain this one currently, but feel that it?s worth mentioning because I was one of the early contributors >> >> I?m happy to answer any questions, and keen to hear any suggestions for handling any handover >> >> I?m sure these are in safe hands, and I will continue to use them myself, and promote the use of them to others! >> >> Cheers, >> Dave >> _______________________________________________ >> 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 dhunt at mozilla.com Fri Nov 30 15:36:35 2018 From: dhunt at mozilla.com (Dave Hunt) Date: Fri, 30 Nov 2018 20:36:35 +0000 Subject: [pytest-dev] Looking for additional maintainers for pytest plugins In-Reply-To: References: <11448D37-50E6-410B-B19F-81B736D6D697@gmail.com> Message-ID: <03270EA7-DA8C-424B-B803-182E0F1235BC@mozilla.com> Thanks Ana! I?m not going away entirely, so I?d be happy to help anyone taking on a maintainer role. I may just turn off the Github notifications at some point, so that I only get email when I?m mentioned. :) > On 30 Nov 2018, at 19:51, Ana Ribeiro wrote: > > Hi Dave, > > I probably have technical knowledge for Pytest-HTML, but I never mantained a popular technical project before. I would be willing to help mantain Pytest-HTML if you could help me for the first weeks. > > Cheers, > Ana > >> Em 30 de nov de 2018, ?(s) 16:41, Brian Okken > escreveu: >> >> Dave, Jim, >> >> Would you want this need mentioned on either Test & Code or Python Bytes podcast? >> >> I don?t have bandwidth to help out, but perhaps some listeners do. But I don?t want to mention if you?d rather I didn?t. >> >> - Brian >> >> On Nov 30, 2018, at 11:15 AM, Dave Hunt > wrote: >> >>> Due to a change in my role, I?m no longer going to be able to spend as much time as I have with maintaining the plugins listed below. The maintenance burden is very light, and releases are handled through Travis CI. I?ve already had some excellent help from Jim Br?nnlund (BeyondEvil), and have added him as a developer to a few of these. I?d appreciate any additional help from the community to support these plugins, and if you?re aware of somebody who would like to contribute please point them in my direction. >>> >>> https://github.com/pytest-dev/pytest-base-url - A very small plugin, no commits in over a year >>> https://github.com/pytest-dev/pytest-selenium - Jim is a developer, and helps out a lot with this one, he's taken care of much of the recent development and responding to issues >>> https://github.com/pytest-dev/pytest-html - This is probably the most popular plugin I?ve been maintaining, and I think there?s a lot of potential for enhancements (great ideas already in the tracker) >>> https://github.com/pytest-dev/pytest-metadata - Split off as a dependency for pytest-html, relatively small plugin and minimal maintenance needs. Jim is a developer for this plugin too >>> https://github.com/pytest-dev/pytest-variables - Another small plugin with very few maintenance needs >>> https://github.com/pytest-dev/pytest-repeat - I don?t really maintain this one currently, but feel that it?s worth mentioning because I was one of the early contributors >>> >>> I?m happy to answer any questions, and keen to hear any suggestions for handling any handover >>> >>> I?m sure these are in safe hands, and I will continue to use them myself, and promote the use of them to others! >>> >>> Cheers, >>> Dave >>> _______________________________________________ >>> 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 jimbrannlund at fastmail.com Fri Nov 30 18:32:05 2018 From: jimbrannlund at fastmail.com (=?utf-8?Q?Jim=20Br=C3=A4nnlund?=) Date: Sat, 01 Dec 2018 00:32:05 +0100 Subject: [pytest-dev] Looking for additional maintainers for pytest plugins In-Reply-To: <03270EA7-DA8C-424B-B803-182E0F1235BC@mozilla.com> References: <11448D37-50E6-410B-B19F-81B736D6D697@gmail.com> <03270EA7-DA8C-424B-B803-182E0F1235BC@mozilla.com> Message-ID: <1543620725.666917.1594933176.3795E711@webmail.messagingengine.com> Dave, Ana Re. pytest-html, maybe you and I can team-up Ana? I was telling Dave that I'm comfortable handling the "maintainer duties" for pytest-html but no so much the technical aspects. Even tho I have contributed some small bits here and there. Cheers -- Jim Br?nnlund jimbrannlund at fastmail.com On Fri, Nov 30, 2018, at 9:36 PM, Dave Hunt wrote: > Thanks Ana! I?m not going away entirely, so I?d be happy to help > anyone taking on a maintainer role. I may just turn off the Github > notifications at some point, so that I only get email when I?m > mentioned. :)> >> On 30 Nov 2018, at 19:51, Ana Ribeiro >> wrote:>> >> Hi Dave, >> >> I probably have technical knowledge for Pytest-HTML, but I never >> mantained a popular technical project before. I would be willing to >> help mantain Pytest-HTML if you could help me for the first weeks.>> >> Cheers, >> Ana >> >>> Em 30 de nov de 2018, ?(s) 16:41, Brian Okken >>> escreveu:>>> >>> Dave, Jim, >>> >>> Would you want this need mentioned on either Test & Code or Python >>> Bytes podcast?>>> >>> I don?t have bandwidth to help out, but perhaps some listeners do. >>> But I don?t want to mention if you?d rather I didn?t.>>> >>> - Brian >>> >>> On Nov 30, 2018, at 11:15 AM, Dave Hunt wrote: >>>> Due to a change in my role, I?m no longer going to be able to spend >>>> as much time as I have with maintaining the plugins listed below. >>>> The maintenance burden is very light, and releases are handled >>>> through Travis CI. I?ve already had some excellent help from Jim >>>> Br?nnlund (BeyondEvil), and have added him as a developer to a few >>>> of these. I?d appreciate any additional help from the community to >>>> support these plugins, and if you?re aware of somebody who would >>>> like to contribute please point them in my direction.>>>> >>>> https://github.com/pytest-dev/pytest-base-url - A very small >>>> plugin, no commits in over a year>>>> https://github.com/pytest-dev/pytest-selenium - Jim is a developer, >>>> and helps out a lot with this one, he's taken care of much of the >>>> recent development and responding to issues>>>> https://github.com/pytest-dev/pytest-html - This is probably the >>>> most popular plugin I?ve been maintaining, and I think there?s a >>>> lot of potential for enhancements (great ideas already in the >>>> tracker)>>>> https://github.com/pytest-dev/pytest-metadata - Split off as a >>>> dependency for pytest-html, relatively small plugin and minimal >>>> maintenance needs. Jim is a developer for this plugin too>>>> https://github.com/pytest-dev/pytest-variables - Another small >>>> plugin with very few maintenance needs>>>> https://github.com/pytest-dev/pytest-repeat - I don?t really >>>> maintain this one currently, but feel that it?s worth mentioning >>>> because I was one of the early contributors>>>> >>>> I?m happy to answer any questions, and keen to hear any suggestions >>>> for handling any handover>>>> >>>> I?m sure these are in safe hands, and I will continue to use them >>>> myself, and promote the use of them to others!>>>> >>>> Cheers, >>>> Dave >>>> _______________________________________________ >>>> 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: