From mailing-list+pytest at alexandre.figura.live Thu Aug 2 10:45:22 2018 From: mailing-list+pytest at alexandre.figura.live (Alexandre Figura) Date: Thu, 2 Aug 2018 16:45:22 +0200 Subject: [pytest-dev] PEP420, Namespace Packages and Pytest Test Layout Message-ID: <3E60AAB5-291B-4E5E-87B5-F3A47D359470@alexandre.figura.live> Hi all, I recently discovered that it was possible to import test modules from other test modules without having __init__.py files in my test directories. I thought it was impossible to do so with Pytest. And discovered it was possible because of the PEP420 and namespace packages . However, I am wondering now if I should rely on the PEP420 to import test modules. I mean, is Pytest designed to be used in this way? Or should I avoid to rely on Python 3 behavior, and use a more "Pytestic" way of structuring my test modules? Waiting for your feedback on this topic, Have a nice day ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From flub at devork.be Thu Aug 2 17:40:33 2018 From: flub at devork.be (Floris Bruynooghe) Date: Thu, 02 Aug 2018 23:40:33 +0200 Subject: [pytest-dev] PEP420, Namespace Packages and Pytest Test Layout In-Reply-To: <3E60AAB5-291B-4E5E-87B5-F3A47D359470@alexandre.figura.live> References: <3E60AAB5-291B-4E5E-87B5-F3A47D359470@alexandre.figura.live> Message-ID: <87a7q478ha.fsf@powell.devork.be> Hi Alexandre, On Thu 02 Aug 2018 at 16:45 +0200, Alexandre Figura wrote: > I recently discovered that it was possible to import test modules from > other test modules without having __init__.py files in my test > directories. I thought it was impossible to do so with Pytest. And > discovered it was possible because of the PEP420 and namespace > packages > . > > However, I am wondering now if I should rely on the PEP420 to import > test modules. I mean, is Pytest designed to be used in this way? Or > should I avoid to rely on Python 3 behavior, and use a more "Pytestic" > way of structuring my test modules? Sure, there's nothing wrong with using PEP420 namespace packages in your test modules layout. All the advice which uses __init__.py is probably just because it's old I think (or to be compatible with 2.7 which is still supported). Cheers, Floris From me at the-compiler.org Sat Aug 4 04:50:30 2018 From: me at the-compiler.org (Florian Bruhin) Date: Sat, 4 Aug 2018 10:50:30 +0200 Subject: [pytest-dev] Code of conduct for pytest organisation on GitHub In-Reply-To: <5D313523-E69E-44F2-B89E-3C8C42F9B67A@mozilla.com> References: <5D313523-E69E-44F2-B89E-3C8C42F9B67A@mozilla.com> Message-ID: <20180804085030.qv454iyt2wzgpr2u@hooch.localdomain> On Tue, Jul 31, 2018 at 12:53:51PM +0100, Dave Hunt wrote: > I?d like to add a code of conduct for my pytest plugins, and as > they?re mostly under the pytest organisation on GitHub I thought it > would make sense to use the same as the pytest project. I was > surprised to find that the pytest project does not currently have a > code of conduct according to > https://github.com/pytest-dev/pytest/community. Is there one > documented elsewhere? If not, which should we adopt? So I wanted to open a PR proposing the Contributor Covenant. However, I noticed we don't have a suitable (non-public!) way of contacting us if there's a need to. I'd propose we instead list mail addresses of some maintainers who'd be interested and we feel like could handle potential conflicts in a fair way. I'd gladly volunteer, but it'd be nice if some more people step up - especially those who've been involved in pytest more from the community rather than the technical side :) Florian -- 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 opensource at ronnypfannschmidt.de Sat Aug 4 07:57:45 2018 From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt) Date: Sat, 4 Aug 2018 13:57:45 +0200 Subject: [pytest-dev] Code of conduct for pytest organisation on GitHub In-Reply-To: <20180804085030.qv454iyt2wzgpr2u@hooch.localdomain> References: <5D313523-E69E-44F2-B89E-3C8C42F9B67A@mozilla.com> <20180804085030.qv454iyt2wzgpr2u@hooch.localdomain> Message-ID: <0aa4ee60-1790-d194-6e20-96ee2e9ce3fd@ronnypfannschmidt.de> Hi, pytest+coc at ronnypfannschmidt.de -- Ronny Am 04.08.2018 um 10:50 schrieb Florian Bruhin: > On Tue, Jul 31, 2018 at 12:53:51PM +0100, Dave Hunt wrote: >> I?d like to add a code of conduct for my pytest plugins, and as >> they?re mostly under the pytest organisation on GitHub I thought it >> would make sense to use the same as the pytest project. I was >> surprised to find that the pytest project does not currently have a >> code of conduct according to >> https://github.com/pytest-dev/pytest/community. Is there one >> documented elsewhere? If not, which should we adopt? > So I wanted to open a PR proposing the Contributor Covenant. However, I > noticed we don't have a suitable (non-public!) way of contacting us if > there's a need to. > > I'd propose we instead list mail addresses of some maintainers who'd be > interested and we feel like could handle potential conflicts in a fair > way. > > I'd gladly volunteer, but it'd be nice if some more people step up - > especially those who've been involved in pytest more from the community > rather than the technical side :) > > Florian > > > > _______________________________________________ > 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 Sat Aug 4 09:00:17 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Sat, 4 Aug 2018 10:00:17 -0300 Subject: [pytest-dev] Code of conduct for pytest organisation on GitHub In-Reply-To: <0aa4ee60-1790-d194-6e20-96ee2e9ce3fd@ronnypfannschmidt.de> References: <5D313523-E69E-44F2-B89E-3C8C42F9B67A@mozilla.com> <20180804085030.qv454iyt2wzgpr2u@hooch.localdomain> <0aa4ee60-1790-d194-6e20-96ee2e9ce3fd@ronnypfannschmidt.de> Message-ID: Feel free to add me as well Florian. []s On Sat, Aug 4, 2018 at 8:58 AM RonnyPfannschmidt < opensource at ronnypfannschmidt.de> wrote: > Hi, > > pytest+coc at ronnypfannschmidt.de > > -- Ronny > > Am 04.08.2018 um 10:50 schrieb Florian Bruhin: > > On Tue, Jul 31, 2018 at 12:53:51PM +0100, Dave Hunt wrote: > > I?d like to add a code of conduct for my pytest plugins, and as > they?re mostly under the pytest organisation on GitHub I thought it > would make sense to use the same as the pytest project. I was > surprised to find that the pytest project does not currently have a > code of conduct according tohttps://github.com/pytest-dev/pytest/community. Is there one > documented elsewhere? If not, which should we adopt? > > So I wanted to open a PR proposing the Contributor Covenant. However, I > noticed we don't have a suitable (non-public!) way of contacting us if > there's a need to. > > I'd propose we instead list mail addresses of some maintainers who'd be > interested and we feel like could handle potential conflicts in a fair > way. > > I'd gladly volunteer, but it'd be nice if some more people step up - > especially those who've been involved in pytest more from the community > rather than the technical side :) > > Florian > > > > > _______________________________________________ > pytest-dev mailing listpytest-dev at python.orghttps://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 oliver at bestwalter.de Sat Aug 4 09:23:36 2018 From: oliver at bestwalter.de (Oliver Bestwalter) Date: Sat, 4 Aug 2018 15:23:36 +0200 Subject: [pytest-dev] Code of conduct for pytest organisation on GitHub In-Reply-To: References: <5D313523-E69E-44F2-B89E-3C8C42F9B67A@mozilla.com> <20180804085030.qv454iyt2wzgpr2u@hooch.localdomain> <0aa4ee60-1790-d194-6e20-96ee2e9ce3fd@ronnypfannschmidt.de> Message-ID: Hi, I was following along and will propose the same for tox where I will also volunteer as a contact, so might as well volunteer here. Would be great though if there also was a female person available for contact (if possible then also for tox, if we do thr same there). Cheers, Oliver On Sat 4. Aug 2018 at 15:00, Bruno Oliveira wrote: > Feel free to add me as well Florian. > > []s > > On Sat, Aug 4, 2018 at 8:58 AM RonnyPfannschmidt < > opensource at ronnypfannschmidt.de> wrote: > >> Hi, >> >> pytest+coc at ronnypfannschmidt.de >> >> -- Ronny >> >> Am 04.08.2018 um 10:50 schrieb Florian Bruhin: >> >> On Tue, Jul 31, 2018 at 12:53:51PM +0100, Dave Hunt wrote: >> >> I?d like to add a code of conduct for my pytest plugins, and as >> they?re mostly under the pytest organisation on GitHub I thought it >> would make sense to use the same as the pytest project. I was >> surprised to find that the pytest project does not currently have a >> code of conduct according tohttps://github.com/pytest-dev/pytest/community. Is there one >> documented elsewhere? If not, which should we adopt? >> >> So I wanted to open a PR proposing the Contributor Covenant. However, I >> noticed we don't have a suitable (non-public!) way of contacting us if >> there's a need to. >> >> I'd propose we instead list mail addresses of some maintainers who'd be >> interested and we feel like could handle potential conflicts in a fair >> way. >> >> I'd gladly volunteer, but it'd be nice if some more people step up - >> especially those who've been involved in pytest more from the community >> rather than the technical side :) >> >> Florian >> >> >> >> >> _______________________________________________ >> pytest-dev mailing listpytest-dev at python.orghttps://mail.python.org/mailman/listinfo/pytest-dev >> >> _______________________________________________ >> 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 alex at seedanddew.com Wed Aug 8 01:03:39 2018 From: alex at seedanddew.com (Alex Georgie) Date: Tue, 7 Aug 2018 22:03:39 -0700 Subject: [pytest-dev] Partnership possibility with Pytest In-Reply-To: <20180731193720.2z3bpwypkvbtissq@hooch.localdomain> References: <56db90b0-9be4-ab6c-7bbf-38baef3c6cae@ronnypfannschmidt.de> <20180731082358.62eomvrolypfadlx@hooch.localdomain> <20180731193720.2z3bpwypkvbtissq@hooch.localdomain> Message-ID: Hey everyone, Didn't actually see Florian's last email until just now. >I guess it could still work out, but I feel like >assigning/dividing funds manually (think Patreon) both results in a more >fair distribution, and gives me control where my money actually goes, >based on what I find most important/useful/... for what I do. I suspect when people try to give money that way, the money tends to silo in one of the bigger, more visible projects - like Bootstrap or Vue. There's nothing wrong with those projects getting money but there are plenty of others that get forgotten in the process. I think you have a point about control. We don't really want to compete with projects like Patreon or others. I think they have their place but our differentiating factor is that you don't need to control anything. Our target market is the techie in his 30-40's. They have a family and maybe kids and while code and open source is important to them, it's really low on the totem pole of their priorities. They don't currently contribute anything but its not about the money, its that they need to figure out where their money should go to and redistribute every few months. It's a decision they keep needing to make and if we keep asking people to do work on top of contributing, they'll eventually stop contributing altogether. The big draw of the platform is that it's passive income for projects and passive distribution for users. You set it and forget it and automatically contribute. Does that seem reasonable? Any other questions, concerns or feedback? Are we comfortable with trying this out with Open Collective? Alex On Tue, Jul 31, 2018 at 12:37 PM, Florian Bruhin wrote: > On Tue, Jul 31, 2018 at 09:13:01AM -0700, Alex Georgie wrote: > > >Where would the money go? > > We actually work with an organization called OpenCollective ( > > https://opencollective.com/) that creates a non-profit for you. The > idea is > > they handle the legalese and create an account where donations can go. > All > > donations and expenses are also on the site, so it becomes fully > > transparent. I believe their cost structure is 5% of donations. We can > send > > money straight to them. Does that work for you guys? > > https://opencollective.com/opensource claims 5% platform fee + 5% host > fee + ~3% payment fee. So we're down to getting about 57% of funds ;-) > > It still doesn't answer the question what we actually would use funds > for (but that's not for you to answer of course :D). > > The only reason I can see right now is future development sprints, where > this likely won't yield enough, while another crowdfunding likely would > work out very well. > > > >I'm also not sure if this works out. I use pytest a lot, but I rarely > > >look at its documentation. > > Not even as reference? Does that apply to other projects where you're > not a > > dev as well? I've heard this feedback before and its fair but my > hypothesis > > is that people still go back every now and then for reference and this > > applies evenly across all projects, so it should lead to the same > > proportion of revenue on a larger time frame. > > I might go back there for a quick look (not really for pytest because I > know the features I use); but still, I probably wouldn't spend much time > there. I guess it could still work out, but I feel like > assigning/dividing funds manually (think Patreon) both results in a more > fair distribution, and gives me control where my money actually goes, > based on what I find most important/useful/... for what I do. > > Just my $0.02 though ;-) > > Florian > > -- > 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 -------------- An HTML attachment was scrubbed... URL: From rustyhowell at gmail.com Tue Aug 14 14:18:07 2018 From: rustyhowell at gmail.com (Rusty Howell) Date: Tue, 14 Aug 2018 12:18:07 -0600 Subject: [pytest-dev] junitxml update Message-ID: Hey all, I am interested in working on junitxml. There are several bugs right now relating to it. https://github.com/pytest-dev/pytest/issues/3777 https://github.com/pytest-dev/pytest/issues/3547 https://github.com/pytest-dev/pytest/issues/1862 https://github.com/pytest-dev/pytest/issues/1126 In the comments in those bugs, there are some big ideas about the path forward, but I'd like to have a more consolidated space for those ideas. My end goal would be to have xml output that is compatible with the Jenkins Junit Test Report plugin. We may even have to support multiple versions of the plugin. Additionally, there are certainly other xUnit style tools that my be slightly different than Junit. Ronny mentioned in one of the bugs the idea of Pytest creating a serialized test log, and then have an Junitxml plugin consume the serialized data and reformat/output as needed. To me it seems that perhaps this could be analogous to logging Loggers and Handlers, where a handler could be specific, like "Jenkins Junit Test Report v1.3" vs "Jenkins Junit Test Report v1.4", or "Allure 2.6.0", etc. What are the general thoughts on the path forward for junitxml? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From flub at devork.be Wed Aug 15 16:33:08 2018 From: flub at devork.be (Floris Bruynooghe) Date: Wed, 15 Aug 2018 22:33:08 +0200 Subject: [pytest-dev] junitxml update In-Reply-To: References: Message-ID: <87zhxnjrp7.fsf@powell.devork.be> Hi Rusty, On Tue 14 Aug 2018 at 12:18 -0600, Rusty Howell wrote: > Hey all, > I am interested in working on junitxml. Great! It would really nice if the default support for junitxml would be up to scratch again. > Ronny mentioned in one of the bugs the idea of Pytest creating a serialized > test log, and then have an Junitxml plugin consume the serialized data and > reformat/output as needed. To me it seems that perhaps this could be > analogous to logging Loggers and Handlers, where a handler could be > specific, like "Jenkins Junit Test Report v1.3" vs "Jenkins Junit Test > Report v1.4", or "Allure 2.6.0", etc. Firstly a disclaimer I'm not very familiar with junitxml and the current problems with the plugin. So I may not be giving the best advice. I'm not sure the logging model is a great thing to clone here. It is a lot of complexity and won't necessarily help with keeping the code simpler. In a way this dispatching already exists with the hooks the plugin needs to implement. E.g. you could think of each "Handler" as a separate plugin and enable the plugin for a specific version conditionally on a commandline flag. This way you could for example implement the various versions as a class each, where the class is the plugin. Then either have a base class for anything shared, or probably better avoid inheritance and share anything common by directly instantiating any common functionality in an object or calling some functions. Thanks for looking at this! Floris From opensource at ronnypfannschmidt.de Thu Aug 16 01:12:33 2018 From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt) Date: Thu, 16 Aug 2018 07:12:33 +0200 Subject: [pytest-dev] junitxml update In-Reply-To: References: Message-ID: <9813a509-6528-e557-6be2-3836d80370ad@ronnypfannschmidt.de> Hi Rusty, my basic idea to move it forward is to remove it from the pytest core so it has freedom to evolve, and then getting interested parties to actually work on it as they see fit. (i for one aren't interested in working on junitxml at all, i just recognize that right now its broken for users and has no-one working on fixing that situation) -- Ronny Am 14.08.2018 um 20:18 schrieb Rusty Howell: > Hey all, > I am interested in working on junitxml. There are several bugs right > now relating to it. > > https://github.com/pytest-dev/pytest/issues/3777 > https://github.com/pytest-dev/pytest/issues/3547 > https://github.com/pytest-dev/pytest/issues/1862 > https://github.com/pytest-dev/pytest/issues/1126 > > In the comments in those bugs, there are some big ideas about the path > forward, but I'd like to have a more consolidated space for those > ideas.? My end goal would be to have xml output that is compatible > with the Jenkins Junit Test Report plugin.? We may even have to > support multiple versions of the plugin. Additionally, there are > certainly other xUnit style tools that my be slightly different than > Junit.?? > > Ronny mentioned in one of the bugs the idea of Pytest creating a > serialized test log, and then have an Junitxml plugin consume the > serialized data and reformat/output as needed. To me it seems that > perhaps this could be analogous to logging Loggers and Handlers, where > a handler could be specific, like "Jenkins Junit Test Report v1.3" vs > "Jenkins Junit Test Report v1.4", or "Allure 2.6.0", etc. > > What are the general thoughts on the path forward for junitxml? > Thanks > > > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Thu Aug 16 08:04:48 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Thu, 16 Aug 2018 09:04:48 -0300 Subject: [pytest-dev] junitxml update In-Reply-To: <9813a509-6528-e557-6be2-3836d80370ad@ronnypfannschmidt.de> References: <9813a509-6528-e557-6be2-3836d80370ad@ronnypfannschmidt.de> Message-ID: Hi folks, On Thu, Aug 16, 2018 at 2:19 AM RonnyPfannschmidt < opensource at ronnypfannschmidt.de> wrote: > Hi Rusty, > > my basic idea to move it forward is to remove it from the pytest core so > it has freedom to evolve, > and then getting interested parties to actually work on it as they see fit. > I have a different take on this. I believe moving the plugin out of the core won't automatically fix its issues. We need to get interested people involved anyway (like Rusty is offering), and nothing prevents them to contribute to the core. My main point is that this not a technical issue IMHO, it is a matter of getting people to contribute, and just taking it out of the core in a separate plugin won't really help that. There's also a technical problem involved, because in order to preserve backward compatibility, pytest will now need to depend on the external plugin, and I don't think that cross dependency is healthy. Also the issues don't look too bad to me, and hopefully they can all be fixed without too much problems if someone would step up. (i for one aren't interested in working on junitxml at all, i just > recognize that right now its broken for users and has no-one working on > fixing that situation) > Fair enough. We use it everyday at work with Jenkins but I just checked and we are stuck in xUnit 1.1, I guess that's why it has not being bothering me. :P Cheers, Bruno > -- Ronny > > > Am 14.08.2018 um 20:18 schrieb Rusty Howell: > > Hey all, > I am interested in working on junitxml. There are several bugs right now > relating to it. > > https://github.com/pytest-dev/pytest/issues/3777 > https://github.com/pytest-dev/pytest/issues/3547 > https://github.com/pytest-dev/pytest/issues/1862 > https://github.com/pytest-dev/pytest/issues/1126 > > In the comments in those bugs, there are some big ideas about the path > forward, but I'd like to have a more consolidated space for those ideas. > My end goal would be to have xml output that is compatible with the Jenkins > Junit Test Report plugin. We may even have to support multiple versions of > the plugin. Additionally, there are certainly other xUnit style tools that > my be slightly different than Junit. > > Ronny mentioned in one of the bugs the idea of Pytest creating a > serialized test log, and then have an Junitxml plugin consume the > serialized data and reformat/output as needed. To me it seems that perhaps > this could be analogous to logging Loggers and Handlers, where a handler > could be specific, like "Jenkins Junit Test Report v1.3" vs "Jenkins Junit > Test Report v1.4", or "Allure 2.6.0", etc. > > What are the general thoughts on the path forward for junitxml? > Thanks > > > > _______________________________________________ > pytest-dev mailing listpytest-dev at python.orghttps://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 opensource at ronnypfannschmidt.de Thu Aug 16 09:10:39 2018 From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt) Date: Thu, 16 Aug 2018 15:10:39 +0200 Subject: [pytest-dev] junitxml update In-Reply-To: References: <9813a509-6528-e557-6be2-3836d80370ad@ronnypfannschmidt.de> Message-ID: Hi Bruno Im fine with any other proposal that sorts out the breakage dimensions to be expected - but until someone makes one i'll hold the strong conviction that externalization before evolution will be the only way to give users control over their fate with xunitxml without locking them into very specific pytest versions. moving forward i'll consider xunit as something i will not touch. -- Ronny Am 16.08.2018 um 14:04 schrieb Bruno Oliveira: > Hi folks,?? > > On Thu, Aug 16, 2018 at 2:19 AM RonnyPfannschmidt > > wrote: > > Hi Rusty, > > my basic idea to move it forward is to remove it from the pytest > core so it has freedom to evolve, > and then getting interested parties to actually work on it as they > see fit. > > > I have a different take on this. I believe moving the plugin out of the > core won't automatically fix its issues. We need to > get?interested?people involved anyway (like Rusty is offering), and > nothing prevents them to contribute to the core. My main point is that > this not a technical issue IMHO, it is a matter of getting people to > contribute, and just taking it out of the core in a separate plugin > won't really help that. > > There's also a technical problem involved, because in order to preserve > backward compatibility, pytest will now need to depend on the external > plugin, and I don't think that cross dependency is healthy. > > Also the issues don't look too bad to me, and hopefully they can all be > fixed without too much problems if someone would step up. > > (i for one aren't interested in working on junitxml at all, i just > recognize that right now its broken for users and has no-one working > on fixing that situation) > > > Fair enough. We use it everyday at work with Jenkins but I just checked > and we are stuck in xUnit 1.1, I guess that's why it has not being > bothering me. :P > > Cheers, > Bruno > > ? > > -- Ronny > > > Am 14.08.2018 um 20:18 schrieb Rusty Howell: >> Hey all, >> I am interested in working on junitxml. There are several bugs >> right now relating to it. >> >> https://github.com/pytest-dev/pytest/issues/3777 >> https://github.com/pytest-dev/pytest/issues/3547 >> https://github.com/pytest-dev/pytest/issues/1862 >> https://github.com/pytest-dev/pytest/issues/1126 >> >> In the comments in those bugs, there are some big ideas about the >> path forward, but I'd like to have a more consolidated space for >> those ideas.? My end goal would be to have xml output that is >> compatible with the Jenkins Junit Test Report plugin.? We may even >> have to support multiple versions of the plugin. Additionally, >> there are certainly other xUnit style tools that my be slightly >> different than Junit.?? >> >> Ronny mentioned in one of the bugs the idea of Pytest creating a >> serialized test log, and then have an Junitxml plugin consume the >> serialized data and reformat/output as needed. To me it seems that >> perhaps this could be analogous to logging Loggers and Handlers, >> where a handler could be specific, like "Jenkins Junit Test Report >> v1.3" vs "Jenkins Junit Test Report v1.4", or "Allure 2.6.0", etc. >> >> What are the general thoughts on the path forward for junitxml? >> Thanks >> >> >> >> _______________________________________________ >> pytest-dev mailing list >> pytest-dev at python.org >> https://mail.python.org/mailman/listinfo/pytest-dev > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > From nicoddemus at gmail.com Thu Aug 16 11:16:23 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Thu, 16 Aug 2018 12:16:23 -0300 Subject: [pytest-dev] junitxml update In-Reply-To: References: <9813a509-6528-e557-6be2-3836d80370ad@ronnypfannschmidt.de> Message-ID: Howdy Ronny, On Thu, Aug 16, 2018 at 10:10 AM RonnyPfannschmidt < opensource at ronnypfannschmidt.de> wrote: > Hi Bruno > > Im fine with any other proposal that sorts out the breakage dimensions > to be expected - but until someone makes one i'll hold the strong > conviction that externalization before evolution will be the only way to > give users control over their fate with xunitxml without locking them > into very specific pytest versions. > I see your point, but I don't think the xunitxml standard changes very frequently and in backward incompatible ways that this can become a problem. But I could be wrong of course. Rusty, Would love to also hear your thoughts about all this! Cheers, Bruno. > > moving forward i'll consider xunit as something i will not touch. > > -- Ronny > > Am 16.08.2018 um 14:04 schrieb Bruno Oliveira: > > Hi folks, > > > > On Thu, Aug 16, 2018 at 2:19 AM RonnyPfannschmidt > > > > wrote: > > > > Hi Rusty, > > > > my basic idea to move it forward is to remove it from the pytest > > core so it has freedom to evolve, > > and then getting interested parties to actually work on it as they > > see fit. > > > > > > I have a different take on this. I believe moving the plugin out of the > > core won't automatically fix its issues. We need to > > get interested people involved anyway (like Rusty is offering), and > > nothing prevents them to contribute to the core. My main point is that > > this not a technical issue IMHO, it is a matter of getting people to > > contribute, and just taking it out of the core in a separate plugin > > won't really help that. > > > > There's also a technical problem involved, because in order to preserve > > backward compatibility, pytest will now need to depend on the external > > plugin, and I don't think that cross dependency is healthy. > > > > Also the issues don't look too bad to me, and hopefully they can all be > > fixed without too much problems if someone would step up. > > > > (i for one aren't interested in working on junitxml at all, i just > > recognize that right now its broken for users and has no-one working > > on fixing that situation) > > > > > > Fair enough. We use it everyday at work with Jenkins but I just checked > > and we are stuck in xUnit 1.1, I guess that's why it has not being > > bothering me. :P > > > > Cheers, > > Bruno > > > > > > > > -- Ronny > > > > > > Am 14.08.2018 um 20:18 schrieb Rusty Howell: > >> Hey all, > >> I am interested in working on junitxml. There are several bugs > >> right now relating to it. > >> > >> https://github.com/pytest-dev/pytest/issues/3777 > >> https://github.com/pytest-dev/pytest/issues/3547 > >> https://github.com/pytest-dev/pytest/issues/1862 > >> https://github.com/pytest-dev/pytest/issues/1126 > >> > >> In the comments in those bugs, there are some big ideas about the > >> path forward, but I'd like to have a more consolidated space for > >> those ideas. My end goal would be to have xml output that is > >> compatible with the Jenkins Junit Test Report plugin. We may even > >> have to support multiple versions of the plugin. Additionally, > >> there are certainly other xUnit style tools that my be slightly > >> different than Junit. > >> > >> Ronny mentioned in one of the bugs the idea of Pytest creating a > >> serialized test log, and then have an Junitxml plugin consume the > >> serialized data and reformat/output as needed. To me it seems that > >> perhaps this could be analogous to logging Loggers and Handlers, > >> where a handler could be specific, like "Jenkins Junit Test Report > >> v1.3" vs "Jenkins Junit Test Report v1.4", or "Allure 2.6.0", etc. > >> > >> What are the general thoughts on the path forward for junitxml? > >> Thanks > >> > >> > >> > >> _______________________________________________ > >> 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 flub at devork.be Thu Aug 16 13:56:25 2018 From: flub at devork.be (Floris Bruynooghe) Date: Thu, 16 Aug 2018 19:56:25 +0200 Subject: [pytest-dev] junitxml update In-Reply-To: References: <9813a509-6528-e557-6be2-3836d80370ad@ronnypfannschmidt.de> Message-ID: <87wosqjiuu.fsf@powell.devork.be> On Thu 16 Aug 2018 at 15:10 +0200, RonnyPfannschmidt wrote: > Im fine with any other proposal that sorts out the breakage dimensions > to be expected Is this the problem where junitxml changes slightly in a new jenkins release and fixing it requires an update to the plugin? At this point users will either have to not update jenkins or update the external plugin or update all of pytest if the plugin stays internal. I don't think the release cycle of pytest is so slow there is a major benefit to moving it external for this? Given that IIUC Rusty is proposing the plugin would be able to generate older incompatible versions (e.g. with --junit-version=x) this would work AFAIK. Happy to hear where I'm wrong though. (I'm kind of +1 on Bruno's opinion of keeping it in the core btw, we should enable ppl to easily contribute to junitxml in the core which I believe our current contributing policies do) Cheers, Floris From rustyhowell at gmail.com Thu Aug 16 16:52:59 2018 From: rustyhowell at gmail.com (Rusty Howell) Date: Thu, 16 Aug 2018 14:52:59 -0600 Subject: [pytest-dev] junitxml update In-Reply-To: <87wosqjiuu.fsf@powell.devork.be> References: <9813a509-6528-e557-6be2-3836d80370ad@ronnypfannschmidt.de> <87wosqjiuu.fsf@powell.devork.be> Message-ID: I personally like the idea of a junit version flag "--junitxml_vesion=x.x" and then in the junitxml module perhaps have a subclass that handles each of the different versions. If the flag is omitted, the default would be the latest junit schema. This would also allow us to fix issues on older junit version (if we miss something), and if the schema changes, adding a new junit format would be straightforward I think. The big issue I see is finding authoritative documentation for the various schemas. In the comments in one of the bugs, there is a link to apache.org and their xsd. This is a good start. But this is just looking at the Junit Test Report Plugin in Jenkins. Are there other xml-consuming reporting tools that are popular enough to support as well? I think to begin with, I will work on seeing what it will take to create a baseclass/subclass for a particular junit version, and adding in any extra command line args. Once I have a proof of concept, I'll comeback and share what I have before I move forward. Rusty On Thu, Aug 16, 2018 at 11:56 AM, Floris Bruynooghe wrote: > On Thu 16 Aug 2018 at 15:10 +0200, RonnyPfannschmidt wrote: > > Im fine with any other proposal that sorts out the breakage dimensions > > to be expected > > Is this the problem where junitxml changes slightly in a new jenkins > release and fixing it requires an update to the plugin? At this point > users will either have to not update jenkins or update the external > plugin or update all of pytest if the plugin stays internal. I don't > think the release cycle of pytest is so slow there is a major benefit to > moving it external for this? Given that IIUC Rusty is proposing the > plugin would be able to generate older incompatible versions (e.g. with > --junit-version=x) this would work AFAIK. > > Happy to hear where I'm wrong though. > > (I'm kind of +1 on Bruno's opinion of keeping it in the core btw, we > should enable ppl to easily contribute to junitxml in the core which I > believe our current contributing policies do) > > Cheers, > Floris > _______________________________________________ > 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 rustyhowell at gmail.com Sat Aug 18 00:08:28 2018 From: rustyhowell at gmail.com (Rusty Howell) Date: Fri, 17 Aug 2018 22:08:28 -0600 Subject: [pytest-dev] junitxml update In-Reply-To: References: <9813a509-6528-e557-6be2-3836d80370ad@ronnypfannschmidt.de> <87wosqjiuu.fsf@powell.devork.be> Message-ID: In doing some research on this, I see that the py library is in maintenance mode and "should not be used in new code", according to the docs at https://pypi.org/project/py/. Are there any concerns with continuing to use this library going forward? On Thu, Aug 16, 2018 at 2:52 PM Rusty Howell wrote: > I personally like the idea of a junit version flag "--junitxml_vesion=x.x" > and then in the junitxml module perhaps have a subclass that handles each > of the different versions. If the flag is omitted, the default would be the > latest junit schema. This would also allow us to fix issues on older > junit version (if we miss something), and if the schema changes, adding a > new junit format would be straightforward I think. The big issue I see is > finding authoritative documentation for the various schemas. In the > comments in one of the bugs, there is a link to apache.org and their xsd. > This is a good start. But this is just looking at the Junit Test Report > Plugin in Jenkins. Are there other xml-consuming reporting tools that are > popular enough to support as well? > > I think to begin with, I will work on seeing what it will take to create a > baseclass/subclass for a particular junit version, and adding in any extra > command line args. Once I have a proof of concept, I'll comeback and share > what I have before I move forward. > > Rusty > > > On Thu, Aug 16, 2018 at 11:56 AM, Floris Bruynooghe > wrote: > >> On Thu 16 Aug 2018 at 15:10 +0200, RonnyPfannschmidt wrote: >> > Im fine with any other proposal that sorts out the breakage dimensions >> > to be expected >> >> Is this the problem where junitxml changes slightly in a new jenkins >> release and fixing it requires an update to the plugin? At this point >> users will either have to not update jenkins or update the external >> plugin or update all of pytest if the plugin stays internal. I don't >> think the release cycle of pytest is so slow there is a major benefit to >> moving it external for this? Given that IIUC Rusty is proposing the >> plugin would be able to generate older incompatible versions (e.g. with >> --junit-version=x) this would work AFAIK. >> >> Happy to hear where I'm wrong though. >> >> (I'm kind of +1 on Bruno's opinion of keeping it in the core btw, we >> should enable ppl to easily contribute to junitxml in the core which I >> believe our current contributing policies do) >> >> Cheers, >> Floris >> _______________________________________________ >> pytest-dev mailing list >> pytest-dev at python.org >> https://mail.python.org/mailman/listinfo/pytest-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From flub at devork.be Sat Aug 18 08:17:38 2018 From: flub at devork.be (Floris Bruynooghe) Date: Sat, 18 Aug 2018 14:17:38 +0200 Subject: [pytest-dev] junitxml update In-Reply-To: References: <9813a509-6528-e557-6be2-3836d80370ad@ronnypfannschmidt.de> <87wosqjiuu.fsf@powell.devork.be> Message-ID: <87tvnrkgwt.fsf@powell.devork.be> Hi Rusty, On Fri 17 Aug 2018 at 22:08 -0600, Rusty Howell wrote: > In doing some research on this, I see that the py library is in maintenance > mode and "should not be used in new code", according to the docs at > https://pypi.org/project/py/. Are there any concerns with continuing to use > this library going forward? Given that this team also maintains the py library there's no issue with keeping using it for anything for which we already use it. So anything from the py library which is already being used by pytest you can happily keep using. If you want to start using new things from the py lib then maybe ping this list first to see if that's still the best solution. Cheers, Floris > On Thu, Aug 16, 2018 at 2:52 PM Rusty Howell wrote: > >> I personally like the idea of a junit version flag "--junitxml_vesion=x.x" >> and then in the junitxml module perhaps have a subclass that handles each >> of the different versions. If the flag is omitted, the default would be the >> latest junit schema. This would also allow us to fix issues on older >> junit version (if we miss something), and if the schema changes, adding a >> new junit format would be straightforward I think. The big issue I see is >> finding authoritative documentation for the various schemas. In the >> comments in one of the bugs, there is a link to apache.org and their xsd. >> This is a good start. But this is just looking at the Junit Test Report >> Plugin in Jenkins. Are there other xml-consuming reporting tools that are >> popular enough to support as well? >> >> I think to begin with, I will work on seeing what it will take to create a >> baseclass/subclass for a particular junit version, and adding in any extra >> command line args. Once I have a proof of concept, I'll comeback and share >> what I have before I move forward. >> >> Rusty >> >> >> On Thu, Aug 16, 2018 at 11:56 AM, Floris Bruynooghe >> wrote: >> >>> On Thu 16 Aug 2018 at 15:10 +0200, RonnyPfannschmidt wrote: >>> > Im fine with any other proposal that sorts out the breakage dimensions >>> > to be expected >>> >>> Is this the problem where junitxml changes slightly in a new jenkins >>> release and fixing it requires an update to the plugin? At this point >>> users will either have to not update jenkins or update the external >>> plugin or update all of pytest if the plugin stays internal. I don't >>> think the release cycle of pytest is so slow there is a major benefit to >>> moving it external for this? Given that IIUC Rusty is proposing the >>> plugin would be able to generate older incompatible versions (e.g. with >>> --junit-version=x) this would work AFAIK. >>> >>> Happy to hear where I'm wrong though. >>> >>> (I'm kind of +1 on Bruno's opinion of keeping it in the core btw, we >>> should enable ppl to easily contribute to junitxml in the core which I >>> believe our current contributing policies do) >>> >>> Cheers, >>> Floris >>> _______________________________________________ >>> pytest-dev mailing list >>> pytest-dev at python.org >>> https://mail.python.org/mailman/listinfo/pytest-dev >>> >> >> From nicoddemus at gmail.com Sat Aug 18 10:09:58 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Sat, 18 Aug 2018 11:09:58 -0300 Subject: [pytest-dev] junitxml update In-Reply-To: <87tvnrkgwt.fsf@powell.devork.be> References: <9813a509-6528-e557-6be2-3836d80370ad@ronnypfannschmidt.de> <87wosqjiuu.fsf@powell.devork.be> <87tvnrkgwt.fsf@powell.devork.be> Message-ID: Hey, On Sat, Aug 18, 2018 at 9:17 AM Floris Bruynooghe wrote: > Hi Rusty, > > On Fri 17 Aug 2018 at 22:08 -0600, Rusty Howell wrote: > > > In doing some research on this, I see that the py library is in > maintenance > > mode and "should not be used in new code", according to the docs at > > https://pypi.org/project/py/. Are there any concerns with continuing to > use > > this library going forward? > > Given that this team also maintains the py library there's no issue with > keeping using it for anything for which we already use it. So anything > from the py library which is already being used by pytest you can > happily keep using. > > If you want to start using new things from the py lib then maybe ping > this list first to see if that's still the best solution. > Just want to add that if you want to use something else from the standard library then please go ahead. The pylib was created many years ago as a bridge between Python 2 and 3 and various utilities, the latter which have since then been added to the standard library. Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Sat Aug 18 10:29:02 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Sat, 18 Aug 2018 11:29:02 -0300 Subject: [pytest-dev] pytest 3.7.2 released Message-ID: pytest 3.7.2 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 http://doc.pytest.org/en/latest/changelog.html. Thanks to all who contributed to this release, among them: * Anthony Sottile * Bruno Oliveira * Daniel Hahler * Josh Holland * Ronny Pfannschmidt * Sankt Petersbug * Wes Thomas * turturica Happy testing, The pytest Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at ronnypfannschmidt.de Mon Aug 20 10:11:34 2018 From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt) Date: Mon, 20 Aug 2018 16:11:34 +0200 Subject: [pytest-dev] junitxml update In-Reply-To: References: <9813a509-6528-e557-6be2-3836d80370ad@ronnypfannschmidt.de> <87wosqjiuu.fsf@powell.devork.be> <87tvnrkgwt.fsf@powell.devork.be> Message-ID: <10d462f2-ec7e-a47d-2149-ff0d7f8dea13@ronnypfannschmidt.de> Am 18.08.2018 um 16:09 schrieb Bruno Oliveira: > Hey, > > On Sat, Aug 18, 2018 at 9:17 AM Floris Bruynooghe > wrote: > > Hi Rusty, > > On Fri 17 Aug 2018 at 22:08 -0600, Rusty Howell wrote: > > > In doing some research on this, I see that the py library is in > maintenance > > mode and "should not be used in new code", according to the docs at > > https://pypi.org/project/py/. Are there any concerns with > continuing to use > > this library going forward? > > Given that this team also maintains the py library there's no issue with > keeping using it for anything for which we already use it.? So anything > from the py library which is already being used by pytest you can > happily keep using. > > If you want to start using new things from the py lib then maybe ping > this list first to see if that's still the best solution. > > > Just want to add that if you want to use something else from the > standard library then please go ahead. The pylib was created many years > ago as a bridge between Python 2 and 3 and various utilities, the latter > which have since then been added to the standard library. a little correction - pylib started inside of pypy along with pytest, actually a while before python3 was a thing -- Ronny > > Cheers, > Bruno. From opensource at ronnypfannschmidt.de Tue Aug 21 03:00:11 2018 From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt) Date: Tue, 21 Aug 2018 09:00:11 +0200 Subject: [pytest-dev] sorting out broken config initialization - by doing major releases with api breakages Message-ID: Hi everyone, currently pytest configguration initialization is pretty much broken in many details, and as far as i can tell its going to be even more tricky to try and fix than marks, i will not again go trough the pain that i had with marks and want to sort out a gate to lift and change detail apis that will be broken. -- Ronny From nicoddemus at gmail.com Tue Aug 21 08:01:12 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Tue, 21 Aug 2018 09:01:12 -0300 Subject: [pytest-dev] sorting out broken config initialization - by doing major releases with api breakages In-Reply-To: References: Message-ID: Hi Ronny, On Tue, Aug 21, 2018 at 4:00 AM RonnyPfannschmidt < opensource at ronnypfannschmidt.de> wrote: > Hi everyone, > > currently pytest configguration initialization is pretty much broken in > many details, > and as far as i can tell its going to be even more tricky to try and fix > than marks, > > i will not again go trough the pain that i had with marks and want to > sort out a gate > to lift and change detail apis that will be broken. > I know what you mean, for example `-p no:logging` does not work on xdist works for some reason, and that is due to how config and parsing are initialized. I tried to follow the implementation once while working on something else, but couldn't figure it out and ended up giving up. I think the first step is to actually write down the issues/actions points, so I propose we start a tracking issue so we can at least start to list the problems that we want to fix, and then create action points from there. Or perhaps another media, like a page on the Wiki or a GH Project? Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at ronnypfannschmidt.de Tue Aug 21 08:14:18 2018 From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt) Date: Tue, 21 Aug 2018 14:14:18 +0200 Subject: [pytest-dev] sorting out broken config initialization - by doing major releases with api breakages In-Reply-To: References: Message-ID: <70bfc654-aaa0-7b08-f72b-426ec796ab83@ronnypfannschmidt.de> Hi Bruno, i created https://github.com/pytest-dev/pytest/projects/2 as a starting point a while back, but its still far from the botton of things, My current impression is, that a detailed analysis will take a major block of time. My intentionally inflated estimate is about 1 work week, since everything about config initialization gives me the impression its intertwined. which is why i'd prefer a a iterative approach that's allowed to break things. (i simply cant afford even a 2 day block to get into things, and i certainly don't want to spread it over time as it adds quite some extra overhead for getting back into things) however i still suspect low outside effect overall. -- Ronny Am 21.08.2018 um 14:01 schrieb Bruno Oliveira: > Hi Ronny, > > On Tue, Aug 21, 2018 at 4:00 AM RonnyPfannschmidt > > wrote: > > Hi everyone, > > currently pytest configguration initialization is pretty much broken in > many details, > and as far as i can tell its going to be even more tricky to try and fix > than marks, > > i will not again go trough the pain that i had with marks and want to > sort out a gate > to lift and change detail apis that will be broken. > > > I know what you mean, for example `-p no:logging` does not work on xdist > works for some reason, and that is due to how config and parsing are > initialized. I tried to follow the implementation once while working on > something else, but couldn't figure it out and ended up giving up.? > > I think the first step is to actually write down the issues/actions > points, so I propose we start a tracking issue so we can at least start > to list the problems that we want to fix, and then create action points > from there. Or perhaps another media, like a page on the Wiki or a GH > Project? > > Cheers, > Bruno. From nicoddemus at gmail.com Tue Aug 21 10:03:05 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Tue, 21 Aug 2018 11:03:05 -0300 Subject: [pytest-dev] sorting out broken config initialization - by doing major releases with api breakages In-Reply-To: <70bfc654-aaa0-7b08-f72b-426ec796ab83@ronnypfannschmidt.de> References: <70bfc654-aaa0-7b08-f72b-426ec796ab83@ronnypfannschmidt.de> Message-ID: On Tue, Aug 21, 2018 at 9:14 AM RonnyPfannschmidt < opensource at ronnypfannschmidt.de> wrote: > Hi Bruno, > > i created https://github.com/pytest-dev/pytest/projects/2 as a starting > point a while back, > but its still far from the botton of things, > > My current impression is, that a detailed analysis will take a major > block of time. > > My intentionally inflated estimate is about 1 work week, > since everything about config initialization gives me the impression its > intertwined. > > which is why i'd prefer a a iterative approach that's allowed to break > things. (i simply cant afford even a 2 day block to get into things, and > i certainly don't want to spread it over time as it adds quite some > extra overhead for getting back into things) > I agree an interactive approach is the way to go. I suspect just by investigating why -p doesn't work with xdist works is enough to bring some action points to light. Personally my next goal is the task to replace the internal warnings system to use the standard warnings module, which I should be able to tackle soon as I have some vacation time coming up, but after that I'm happy to help with the configuration refactoring. Cheers, Bruno. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at ronnypfannschmidt.de Tue Aug 21 10:20:30 2018 From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt) Date: Tue, 21 Aug 2018 16:20:30 +0200 Subject: [pytest-dev] sorting out broken config initialization - by doing major releases with api breakages In-Reply-To: References: <70bfc654-aaa0-7b08-f72b-426ec796ab83@ronnypfannschmidt.de> Message-ID: <95f59b2f-6bb3-08a2-cc2c-2654319a717e@ronnypfannschmidt.de> Am 21.08.2018 um 16:03 schrieb Bruno Oliveira: > > > On Tue, Aug 21, 2018 at 9:14 AM RonnyPfannschmidt > > wrote: > > Hi Bruno, > > i created https://github.com/pytest-dev/pytest/projects/2 as a starting > point a while back, > but its still far from the botton of things, > > My current impression is, that a detailed analysis will take a major > block of time. > > My intentionally inflated estimate is about 1 work week, > since everything about config initialization gives me the impression its > intertwined. > > which is why i'd prefer a a iterative approach that's allowed to break > things. (i simply cant afford even a 2 day block to get into things, and > i certainly don't want to spread it over time as it adds quite some > extra overhead for getting back into things) > > > I agree an interactive approach is the way to go. I suspect just by > investigating why -p doesn't work with xdist works is enough to bring > some action points to light. that happens because we have a mismatch in the startup sequences of the config initialization on xdist workers we always load all plugins first, while on normal execution we block the unwanted ones first > > Personally my next goal is the task to replace the internal warnings > system to use the standard warnings module, which I should be able to > tackle soon as I have some vacation time coming up, but after that I'm > happy to help with the configuration refactoring. > > Cheers, > Bruno. > > From flub at devork.be Tue Aug 21 17:02:37 2018 From: flub at devork.be (Floris Bruynooghe) Date: Tue, 21 Aug 2018 23:02:37 +0200 Subject: [pytest-dev] sorting out broken config initialization - by doing major releases with api breakages In-Reply-To: References: <70bfc654-aaa0-7b08-f72b-426ec796ab83@ronnypfannschmidt.de> Message-ID: <87zhxfe8lu.fsf@powell.devork.be> On Tue 21 Aug 2018 at 11:03 -0300, Bruno Oliveira wrote: > Personally my next goal is the task to replace the internal warnings system > to use the standard warnings module, which I should be able to tackle soon > as I have some vacation time coming up, but after that I'm happy to help > with the configuration refactoring. Hum, have you successfully used the stdlib warning module in such a fashion in another project before? I recall trying to do this many years ago but concluding that the stdlib warnings system is there not for your code but for Python itself. And especially with respect to testing I recall that it was deliberate not to use this since it would make testing code which uses warnings even more tricky. But it's quite likely that my opinion is somewhat out of date and you've actually got good reason for this. Cheers, Floris From nicoddemus at gmail.com Tue Aug 21 17:38:25 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Tue, 21 Aug 2018 18:38:25 -0300 Subject: [pytest-dev] sorting out broken config initialization - by doing major releases with api breakages In-Reply-To: <87zhxfe8lu.fsf@powell.devork.be> References: <70bfc654-aaa0-7b08-f72b-426ec796ab83@ronnypfannschmidt.de> <87zhxfe8lu.fsf@powell.devork.be> Message-ID: Hi Floris, On Tue, Aug 21, 2018 at 6:02 PM Floris Bruynooghe wrote: > On Tue 21 Aug 2018 at 11:03 -0300, Bruno Oliveira wrote: > > Personally my next goal is the task to replace the internal warnings > system > > to use the standard warnings module, which I should be able to tackle > soon > > as I have some vacation time coming up, but after that I'm happy to help > > with the configuration refactoring. > > Hum, have you successfully used the stdlib warning module in such a > fashion in another project before? I recall trying to do this many > years ago but concluding that the stdlib warnings system is there not > for your code but for Python itself. And especially with respect to > testing I recall that it was deliberate not to use this since it would > make testing code which uses warnings even more tricky. > Hmm never used it before like this, but we have give it some thought and the plan is described here: https://github.com/pytest-dev/pytest/issues/2452#issuecomment-305466827 Please do comment on that in case your experience differs from our expectations while thinking about that issue. Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at merlinux.eu Wed Aug 29 08:37:41 2018 From: holger at merlinux.eu (holger krekel) Date: Wed, 29 Aug 2018 14:37:41 +0200 Subject: [pytest-dev] anyone up for giving a training in SFO? Message-ID: <20180829123741.GW4058@beto> Hello pytest testing experts and devs, a good longtime client has asked me if someone not too far away from San francisco could give pytest training(s) (beginner/advanced). Me and Carl Meyer have given these trainings but are both not available currently (and not very local to SFO). There is good tested training materials i can provide -- and preferred is someone who wouldn't have long travel to SFO. Please let me know if you are interested. best, holger From nicoddemus at gmail.com Thu Aug 30 11:08:54 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Thu, 30 Aug 2018 12:08:54 -0300 Subject: [pytest-dev] pytest Quick Start Guide Message-ID: Hi everyone, I'm pleased to announce the release of my book about pytest: https://www.packtpub.com/web-development/pytest-quick-start-guide I cover how to get started quickly to use pytest in your daily work, and some more niche topics like techniques to convert unittest-based suites to pytest. Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliver at bestwalter.de Thu Aug 30 11:31:55 2018 From: oliver at bestwalter.de (Oliver Bestwalter) Date: Thu, 30 Aug 2018 17:31:55 +0200 Subject: [pytest-dev] pytest Quick Start Guide In-Reply-To: References: Message-ID: H Bruno, congratulations! Bought it right away - coming from you it has to be good :) Cheers, Oliver On Thu, 30 Aug 2018 at 17:09 Bruno Oliveira wrote: > Hi everyone, > > I'm pleased to announce the release of my book about pytest: > > https://www.packtpub.com/web-development/pytest-quick-start-guide > > I cover how to get started quickly to use pytest in your daily work, and > some more niche topics like techniques to convert unittest-based suites to > pytest. > > 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 Thu Aug 30 11:33:19 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Thu, 30 Aug 2018 12:33:19 -0300 Subject: [pytest-dev] pytest Quick Start Guide In-Reply-To: References: Message-ID: Thanks a lot Oliver, it means a lot! Em qui, 30 de ago de 2018 12:32, Oliver Bestwalter escreveu: > H Bruno, > > congratulations! Bought it right away - coming from you it has to be good > :) > > Cheers, > Oliver > > On Thu, 30 Aug 2018 at 17:09 Bruno Oliveira wrote: > >> Hi everyone, >> >> I'm pleased to announce the release of my book about pytest: >> >> https://www.packtpub.com/web-development/pytest-quick-start-guide >> >> I cover how to get started quickly to use pytest in your daily work, and >> some more niche topics like techniques to convert unittest-based suites to >> pytest. >> >> 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: