From opensource at ronnypfannschmidt.de Fri Jan 1 12:13:08 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Fri, 01 Jan 2016 18:13:08 +0100 Subject: [pytest-dev] Paid contract desired/bountysource label on gh ? Message-ID: <01583A9F-0F9A-4122-985D-DDD186E6B7E0@ronnypfannschmidt.de> Hi all, While grooming I stumbled upon issues where Holger rightfully noted that he wouldn't tackle them in free time I wonder if it would be a good idea to create contract work and/or bounty labels And experiment with the effect. -- Ronny -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Fri Jan 1 12:28:31 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Fri, 01 Jan 2016 17:28:31 +0000 Subject: [pytest-dev] Paid contract desired/bountysource label on gh ? In-Reply-To: <01583A9F-0F9A-4122-985D-DDD186E6B7E0@ronnypfannschmidt.de> References: <01583A9F-0F9A-4122-985D-DDD186E6B7E0@ronnypfannschmidt.de> Message-ID: I think it is a good idea to have bounty labels... having an official channel for people to explicitly offer bounties would be nice. On Fri, Jan 1, 2016 at 3:20 PM Ronny Pfannschmidt < opensource at ronnypfannschmidt.de> wrote: > Hi all, > > While grooming I stumbled upon issues where Holger rightfully noted that > he wouldn't tackle them in free time > > I wonder if it would be a good idea to create contract work and/or bounty > labels > And experiment with the effect. > > -- Ronny > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > gesendet._______________________________________________ > 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 Sun Jan 3 12:58:59 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Sun, 03 Jan 2016 18:58:59 +0100 Subject: [pytest-dev] Dropping python 2.6 support in pytest 2.9 Message-ID: <1C24F17B-3835-441A-BEDC-89CC2D4B01F2@ronnypfannschmidt.de> Hi everyone, Since 2.6 is eol since a while now I'd like to drop support for it in pytest 2.9 This would allow to get rid of various bug workarounds and remove various expensive to implement 2.6 only bugs from out plate Feedback on twitter was positive, and its generally suggested to drop 2.6 unless someone pays for continued support. If somebody really needs python 2.6 they can still pin pytest 2.8. -- Ronny -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Sun Jan 3 13:12:33 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Sun, 03 Jan 2016 18:12:33 +0000 Subject: [pytest-dev] Dropping python 2.6 support in pytest 2.9 In-Reply-To: <1C24F17B-3835-441A-BEDC-89CC2D4B01F2@ronnypfannschmidt.de> References: <1C24F17B-3835-441A-BEDC-89CC2D4B01F2@ronnypfannschmidt.de> Message-ID: On Sun, Jan 3, 2016 at 3:59 PM Ronny Pfannschmidt < opensource at ronnypfannschmidt.de> wrote: > Hi everyone, > > Since 2.6 is eol since a while now I'd like to drop support for it in > pytest 2.9 > As I said on the thread for this issue, I'm +0 on it. :) Cheers, -------------- next part -------------- An HTML attachment was scrubbed... URL: From brianna.laugher at gmail.com Tue Jan 5 23:52:29 2016 From: brianna.laugher at gmail.com (Brianna Laugher) Date: Wed, 6 Jan 2016 15:52:29 +1100 Subject: [pytest-dev] Paid contract desired/bountysource label on gh ? In-Reply-To: References: <01583A9F-0F9A-4122-985D-DDD186E6B7E0@ronnypfannschmidt.de> Message-ID: I have never seen bounty stuff work well in open source TBH. Perhaps the website needs to be a bit more pointed in showing that there are consultants (such as Holger, but surely others too) available to work on pytest for a fee. IMO pytest is well into the size and popularity that it would benefit from a fulltime paid staff or 1 or more. We have quite an active volunteer community which is great! but it's difficult for volunteers to resolve problems that require major refactors. cheers Brianna On 2 January 2016 at 04:28, Bruno Oliveira wrote: > I think it is a good idea to have bounty labels... having an official > channel for people to explicitly offer bounties would be nice. > > On Fri, Jan 1, 2016 at 3:20 PM Ronny Pfannschmidt < > opensource at ronnypfannschmidt.de> wrote: > >> Hi all, >> >> While grooming I stumbled upon issues where Holger rightfully noted that >> he wouldn't tackle them in free time >> >> I wonder if it would be a good idea to create contract work and/or bounty >> labels >> And experiment with the effect. >> >> -- Ronny >> -- >> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail >> gesendet._______________________________________________ >> 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 > > -- They've just been waiting in a mountain for the right moment: http://modernthings.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at merlinux.eu Thu Jan 7 05:28:17 2016 From: holger at merlinux.eu (holger krekel) Date: Thu, 7 Jan 2016 10:28:17 +0000 Subject: [pytest-dev] Paid contract desired/bountysource label on gh ? In-Reply-To: References: <01583A9F-0F9A-4122-985D-DDD186E6B7E0@ronnypfannschmidt.de> Message-ID: <20160107102817.GA3793@merlinux.eu> On Wed, Jan 06, 2016 at 15:52 +1100, Brianna Laugher wrote: > I have never seen bounty stuff work well in open source TBH. me neither. The overhead in accounting and communication can easily swallow the benefit. But maybe we could tell companies that they can chip in multiples of 500 euros and they get to prioritize issues and otherwise money will flow into work deemed useful by the team. That money could be invoiced and distributed (companies prefer invoices not some random paypal transfers) by merlinux, my little company, based on decisions by the team. Question is how we do all this without inducing too much overhead. What i did see work somewhat ok is campaigning for particular proposals like the PyPy project does (see right hand side of http://pypy.org ). They work with the US-based Software Freedom Conservancy which takes a 10% cut and otherwise cares for getting the money in and distributing it to whoever is tasked with implementing the proposal. > Perhaps the website needs to be a bit more pointed in showing that there > are consultants (such as Holger, but surely others too) available to work > on pytest for a fee. Makes sense IMHO. FWIW I am doing a 2h online consulting session with a company tomorrow and am happy to refer companies to other pytestonistas. > IMO pytest is well into the size and popularity that it would benefit from > a fulltime paid staff or 1 or more. We have quite an active volunteer > community which is great! but it's difficult for volunteers to resolve > problems that require major refactors. Last time i asked everybody appeared busy enough to not feel able to commit much time even if there is money. FWIW i suggest we first head for a fundraiser for travel and lodging costs to do a 3-5 day sprint in spring or summer 2016. I offer to organize it in my home town Freiburg in the black forest. I guess we'd need a couple of thousand Euros to get everybody interested to come. best, holger > cheers > Brianna > > On 2 January 2016 at 04:28, Bruno Oliveira wrote: > > > I think it is a good idea to have bounty labels... having an official > > channel for people to explicitly offer bounties would be nice. > > > > On Fri, Jan 1, 2016 at 3:20 PM Ronny Pfannschmidt < > > opensource at ronnypfannschmidt.de> wrote: > > > >> Hi all, > >> > >> While grooming I stumbled upon issues where Holger rightfully noted that > >> he wouldn't tackle them in free time > >> > >> I wonder if it would be a good idea to create contract work and/or bounty > >> labels > >> And experiment with the effect. > >> > >> -- Ronny > >> -- > >> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > >> gesendet._______________________________________________ > >> 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 > > > > > > > -- > They've just been waiting in a mountain for the right moment: > http://modernthings.org/ > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev -- about me: http://holgerkrekel.net/about-me/ contracting: http://merlinux.eu From holger at merlinux.eu Thu Jan 7 05:40:28 2016 From: holger at merlinux.eu (holger krekel) Date: Thu, 7 Jan 2016 10:40:28 +0000 Subject: [pytest-dev] pytest sprint 2016 / getting started Message-ID: <20160107104028.GB3793@merlinux.eu> Hey all, let's try to find out if we can make a pytest sprint happen in 2016. Here are some suggestions/thoughts on key points. Participants: anyway who has contributed to pytest in recent years but also interested newcomers/wanna-be-contributors. Contributors are eligible for getting their travel costs reimbursed (see funding below). Location: somewhere around Freiburg, black forest, Germany. Date ranges: 20-26th June or 30th June - 6th July. Travel: arrive on the first day, leave the last. Funding: we'll do a Indiegogo or betterplace.org campaign and ask companies and individuals to help come up with funding for travel costs, lodging and food for participants. If participants can come on their company's time and money even better. In fact, the gathering will be a great opportunity to dive deeper into pytest and make the best use of it for your company. sprint contents: pytest-3.0 and a major new revision of the xdist plugin? Cleaning up wards, introducing new features (to be continued ...). deadline for funding compaign: maybe February/March so everybody can start booking. Who'd be up for it? how much do you estimate you need for travel? Would the date range fit? best, holger From me at the-compiler.org Thu Jan 7 05:52:55 2016 From: me at the-compiler.org (Florian Bruhin) Date: Thu, 7 Jan 2016 11:52:55 +0100 Subject: [pytest-dev] pytest sprint 2016 / getting started In-Reply-To: <20160107104028.GB3793@merlinux.eu> References: <20160107104028.GB3793@merlinux.eu> Message-ID: <20160107105255.GL13305@tonks> * holger krekel [2016-01-07 10:40:28 +0000]: > let's try to find out if we can make a pytest sprint happen in 2016. Yay! :) > Location: somewhere around Freiburg, black forest, Germany. That'd work very well for me. Travel costs are probably something like 35 - 40 EUR total ;) > Date ranges: > > 20-26th June or > 30th June - 6th July. > > Travel: arrive on the first day, leave the last. Both works for me. What about sleeping? FWIW I don't need much more than a little bit of space on some floor and my sleeping mat/bag ;) > Funding: we'll do a Indiegogo or betterplace.org campaign and ask > companies and individuals to help come up with funding for travel > costs, lodging and food for participants. If participants can come > on their company's time and money even better. In fact, the gathering > will be a great opportunity to dive deeper into pytest and make the best > use of it for your company. I'm not sure how comfortable companies are with crowdfunding platforms, but I don't have a better proposal ;) Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nicoddemus at gmail.com Thu Jan 7 19:50:20 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Fri, 08 Jan 2016 00:50:20 +0000 Subject: [pytest-dev] pytest sprint 2016 / getting started In-Reply-To: <20160107104028.GB3793@merlinux.eu> References: <20160107104028.GB3793@merlinux.eu> Message-ID: On Thu, Jan 7, 2016 at 8:40 AM holger krekel wrote: > let's try to find out if we can make a pytest sprint happen in 2016. > Excellent, my first pytest sprint (hopefully). :D > Location: somewhere around Freiburg, black forest, Germany. > Date ranges: > > 20-26th June or > > 30th June - 6th July. > Both work for me. I assume there are hostels/hotels/bed-and-breakfast nearby for lodging. :) > deadline for funding compaign: maybe February/March > so everybody can start booking. > Sounds good. > how much do you estimate you need for travel? > A quick search for flight prices show an estimate of about 570 - 700 EUR (from Brazil). Oh dear! :) Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pizza at netspace.net.au Fri Jan 8 01:55:16 2016 From: pizza at netspace.net.au (Jason King) Date: Fri, 08 Jan 2016 17:55:16 +1100 Subject: [pytest-dev] no self-awareness for pytest Message-ID: <568F5D54.1010401@netspace.net.au> Hi, I'm most of the way through a conversion of matplotlib to using pytest instead of nose, and I'm having a problem. PR is here https://github.com/matplotlib/matplotlib/pull/5405 Th is is the error text I'm getting: ==================================== ERRORS ==================================== ____________________________ ERROR at setup of test ____________________________ file /home/travis/build/matplotlib/matplotlib/venv/lib/python2.7/site-packages/numpy/testing/nosetester.py, line 249 def test(self, label='fast', verbose=1, extra_argv=None, doctests=False, fixture 'self' not found available fixtures: tmpdir_factory, pytestconfig, cov, cache, recwarn, monkeypatch, record_xml_property, capfd, capsys, tmpdir use 'py.test --fixtures [testpath]' for help on them. /home/travis/build/matplotlib/matplotlib/venv/lib/python2.7/site-packages/numpy/testing/nosetester.py:249 ____________________________ ERROR at setup of test ____________________________ file /home/travis/build/matplotlib/matplotlib/venv/lib/python2.7/site-packages/numpy/testing/nosetester.py, line 249 def test(self, label='fast', verbose=1, extra_argv=None, doctests=False, fixture 'self' not found available fixtures: tmpdir_factory, pytestconfig, cov, cache, recwarn, monkeypatch, record_xml_property, capfd, capsys, tmpdir use 'py.test --fixtures [testpath]' for help on them. /home/travis/build/matplotlib/matplotlib/venv/lib/python2.7/site-packages/numpy/testing/nosetester.py:249 3571 passed, 9 skipped, 28 xfailed, 2 pytest-warnings, 2 error in 120.55 seconds So it seems to be locating a function called 'test' in numpy's nosetester.py file, thats in the virtualenv, and trying to set it up as a test. Which isn't what I want. (I only want tests located in matplotlib's install directory) I've tried specifying "numpy" in tox.ini's [pytest] norecursedir option, but pytest seems to be ignoring that. Also tried using '--ignore=site-packages/numpy/testing/.' as a string in the list that is given to pytest.main(). and last, as a joke, tried creating a fixture called 'self' but it seemed to ignore that too. Does anyone know how to make pytest self-aware so it can take on skynet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From flub at devork.be Fri Jan 8 03:46:52 2016 From: flub at devork.be (Floris Bruynooghe) Date: Fri, 8 Jan 2016 08:46:52 +0000 Subject: [pytest-dev] no self-awareness for pytest In-Reply-To: <568F5D54.1010401@netspace.net.au> References: <568F5D54.1010401@netspace.net.au> Message-ID: Hi On 8 January 2016 at 06:55, Jason King wrote: [...] > So it seems to be locating a function called 'test' in numpy's nosetester.py > file, thats in the virtualenv, and trying to set > it up as a test. Which isn't what I want. (I only want tests located in > matplotlib's install directory) Can you not pass this directory you want to the py.test commandline then? E.g. py.test [opts] lib/matplotlib/tests. That way py.test will only try to collect tests from your test directory instead of everything in you current working directory. Regards, Floris From holger at merlinux.eu Fri Jan 8 03:49:00 2016 From: holger at merlinux.eu (holger krekel) Date: Fri, 8 Jan 2016 08:49:00 +0000 Subject: [pytest-dev] no self-awareness for pytest In-Reply-To: References: <568F5D54.1010401@netspace.net.au> Message-ID: <20160108084900.GM3793@merlinux.eu> On Fri, Jan 08, 2016 at 08:46 +0000, Floris Bruynooghe wrote: > Hi > > On 8 January 2016 at 06:55, Jason King wrote: > [...] > > So it seems to be locating a function called 'test' in numpy's nosetester.py > > file, thats in the virtualenv, and trying to set > > it up as a test. Which isn't what I want. (I only want tests located in > > matplotlib's install directory) > > Can you not pass this directory you want to the py.test commandline > then? E.g. py.test [opts] lib/matplotlib/tests. That way py.test > will only try to collect tests from your test directory instead of > everything in you current working directory. Also, "py.test -h" reveals there is a "testpaths" setting for the ini file where you can positively set the paths/directories where you want to see collection happening if no positional arguments are passed to pytest. holger From flub at devork.be Fri Jan 8 04:11:12 2016 From: flub at devork.be (Floris Bruynooghe) Date: Fri, 8 Jan 2016 09:11:12 +0000 Subject: [pytest-dev] pytest sprint 2016 / getting started In-Reply-To: <20160107104028.GB3793@merlinux.eu> References: <20160107104028.GB3793@merlinux.eu> Message-ID: Hello, On 7 January 2016 at 10:40, holger krekel wrote: > Hey all, > > let's try to find out if we can make a pytest sprint happen in 2016. > Here are some suggestions/thoughts on key points. > > Participants: anyway who has contributed to pytest in recent years but also > interested newcomers/wanna-be-contributors. Contributors are eligible > for getting their travel costs reimbursed (see funding below). > > Location: somewhere around Freiburg, black forest, Germany. > > Date ranges: > > 20-26th June or > > 30th June - 6th July. > > Travel: arrive on the first day, leave the last. This is a little trick for me I think. I'm supposed to attend Monitorama in PDX which is 27-29 June so right in between these dates. As that's for work and we're suppose to sponsor I imagine I'll be very busy just before. The week after might be better but I'd miss the start I imagine and as my boss is taking that time off already I'm not sure I can abandon the others in the office. Sadly that's shortly followed by Europython which I think work will also be sponsoring so I probably can't really skip that either. So for me earlier in June or late July/August would would better. But if I'd have to choose from the above the 2nd option is probably the better. > Funding: we'll do a Indiegogo or betterplace.org campaign and ask > companies and individuals to help come up with funding for travel > costs, lodging and food for participants. If participants can come > on their company's time and money even better. In fact, the gathering > will be a great opportunity to dive deeper into pytest and make the best > use of it for your company. I will try to see if I can get my work to contribute (no guarantees though ;-)), but I'd need an invoice for that. Maybe something like that could be easier done by directly buying one of the long-distance plane tickets or so however so probably not a great deal. Regards, Floris From pizza at netspace.net.au Fri Jan 8 07:09:05 2016 From: pizza at netspace.net.au (Jason King) Date: Fri, 08 Jan 2016 23:09:05 +1100 Subject: [pytest-dev] no self-awareness for pytest In-Reply-To: <20160108084900.GM3793@merlinux.eu> References: <568F5D54.1010401@netspace.net.au> <20160108084900.GM3793@merlinux.eu> Message-ID: <568FA6E1.8040807@netspace.net.au> On 08/01/16 19:49, holger krekel wrote: > On Fri, Jan 08, 2016 at 08:46 +0000, Floris Bruynooghe wrote: >> Hi >> >> On 8 January 2016 at 06:55, Jason King wrote: >> [...] >>> So it seems to be locating a function called 'test' in numpy's nosetester.py >>> file, thats in the virtualenv, and trying to set >>> it up as a test. Which isn't what I want. (I only want tests located in >>> matplotlib's install directory) >> Can you not pass this directory you want to the py.test commandline >> then? E.g. py.test [opts] lib/matplotlib/tests. That way py.test >> will only try to collect tests from your test directory instead of >> everything in you current working directory. > Also, "py.test -h" reveals there is a "testpaths" setting for the ini > file where you can positively set the paths/directories where you want > to see collection happening if no positional arguments are passed to > pytest. > > holger > pytest is being called like this: pytest.main(['--pyargs'] + default_test_modules + ['--ignore=site-packages/numpy/testing/.']) where default_test_modules is: [ u'matplotlib.tests.test_agg', u'matplotlib.tests.test_animation', u'matplotlib.tests.test_arrow_patches', u'matplotlib.tests.test_artist', u'matplotlib.tests.test_axes', u'matplotlib.tests.test_backend_bases', u'matplotlib.tests.test_backend_pdf', u'matplotlib.tests.test_backend_pgf', u'matplotlib.tests.test_backend_ps', u'matplotlib.tests.test_backend_qt4', u'matplotlib.tests.test_backend_qt5', u'matplotlib.tests.test_backend_svg', u'matplotlib.tests.test_basic', u'matplotlib.tests.test_bbox_tight', u'matplotlib.tests.test_cbook', u'matplotlib.tests.test_coding_standards', u'matplotlib.tests.test_collections', u'matplotlib.tests.test_colorbar', u'matplotlib.tests.test_colors', u'matplotlib.tests.test_compare_images', u'matplotlib.tests.test_container', u'matplotlib.tests.test_contour', u'matplotlib.tests.test_dates', u'matplotlib.tests.test_delaunay', u'matplotlib.tests.test_dviread', u'matplotlib.tests.test_figure', u'matplotlib.tests.test_font_manager', u'matplotlib.tests.test_gridspec', u'matplotlib.tests.test_image', u'matplotlib.tests.test_legend', u'matplotlib.tests.test_lines', u'matplotlib.tests.test_mathtext', u'matplotlib.tests.test_mlab', u'matplotlib.tests.test_offsetbox', u'matplotlib.tests.test_patches', u'matplotlib.tests.test_path', u'matplotlib.tests.test_patheffects', u'matplotlib.tests.test_pickle', u'matplotlib.tests.test_png', u'matplotlib.tests.test_quiver', u'matplotlib.tests.test_rcparams', u'matplotlib.tests.test_scale', u'matplotlib.tests.test_simplification', u'matplotlib.tests.test_spines', u'matplotlib.tests.test_streamplot', u'matplotlib.tests.test_style', u'matplotlib.tests.test_subplots', u'matplotlib.tests.test_table', u'matplotlib.tests.test_text', u'matplotlib.tests.test_texmanager', u'matplotlib.tests.test_ticker', u'matplotlib.tests.test_tightlayout', u'matplotlib.tests.test_transforms', u'matplotlib.tests.test_triangulation', u'matplotlib.tests.test_type1font', u'matplotlib.tests.test_units', u'matplotlib.tests.test_widgets', u'matplotlib.tests.test_cycles', u'matplotlib.tests.test_labeled_data_unpacking', u'matplotlib.sphinxext.tests.test_tinypages', u'mpl_toolkits.tests.test_mplot3d', u'mpl_toolkits.tests.test_axes_grid1', u'mpl_toolkits.tests.test_axes_grid'] Which should be specifying where to look for the tests I'll give testpaths a go and see what happens. From brianna.laugher at gmail.com Fri Jan 8 07:52:41 2016 From: brianna.laugher at gmail.com (Brianna Laugher) Date: Fri, 8 Jan 2016 23:52:41 +1100 Subject: [pytest-dev] pytest sprint 2016 / getting started In-Reply-To: <20160107104028.GB3793@merlinux.eu> References: <20160107104028.GB3793@merlinux.eu> Message-ID: Bruno I see your 700? and raise you 1000?... ;) The dates are fine for me and I would love to come, but a bigger question is if I can justify flying to Europe from Australia for such a short trip. I am starting a new job in February and should have enough leave for that, but not much more. I guess I will raise it with my future bosses and see what they say. It's very tempting though, as I really enjoyed time with pytesters at PyCon US and Europython :) A couple of considerations - - is it worth aligning with a conference such as Europython (immediately before/after)? Maybe Europython sprints + 2 extra days is easier than 5 days just for pytest. Or maybe not, I'm not sure. - what's the optimal number of participants? I imagine something like 5-15. Cheers Brianna On 07/01/2016 9:40 PM, "holger krekel" wrote: > Hey all, > > let's try to find out if we can make a pytest sprint happen in 2016. > Here are some suggestions/thoughts on key points. > > Participants: anyway who has contributed to pytest in recent years but also > interested newcomers/wanna-be-contributors. Contributors are eligible > for getting their travel costs reimbursed (see funding below). > > Location: somewhere around Freiburg, black forest, Germany. > > Date ranges: > > 20-26th June or > > 30th June - 6th July. > > Travel: arrive on the first day, leave the last. > > Funding: we'll do a Indiegogo or betterplace.org campaign and ask > companies and individuals to help come up with funding for travel > costs, lodging and food for participants. If participants can come > on their company's time and money even better. In fact, the gathering > will be a great opportunity to dive deeper into pytest and make the best > use of it for your company. > > sprint contents: pytest-3.0 and a major new revision of the xdist plugin? > Cleaning up wards, introducing new features (to be continued ...). > > deadline for funding compaign: maybe February/March > so everybody can start booking. > > Who'd be up for it? how much do you estimate you need for travel? > Would the date range fit? > > best, > holger > _______________________________________________ > 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 pizza at netspace.net.au Fri Jan 8 08:19:09 2016 From: pizza at netspace.net.au (Jason King) Date: Sat, 09 Jan 2016 00:19:09 +1100 Subject: [pytest-dev] no self-awareness for pytest In-Reply-To: <568FA6E1.8040807@netspace.net.au> References: <568F5D54.1010401@netspace.net.au> <20160108084900.GM3793@merlinux.eu> <568FA6E1.8040807@netspace.net.au> Message-ID: <568FB74D.3080903@netspace.net.au> > I'll give testpaths a go and see what happens. > _______________________________________________ turns out I'd specified 'testpaths = tests' already in tox.ini one thing I didn't make clear, running pytest.main() with the arguments I listed earlier means that Its looking at the matplotlib install location, (ie in the site-packages dir, inside the venv, next to where numpy is installed. (not where the files were unpacked from) From contact at ionelmc.ro Fri Jan 8 08:56:50 2016 From: contact at ionelmc.ro (=?UTF-8?Q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Fri, 8 Jan 2016 15:56:50 +0200 Subject: [pytest-dev] no self-awareness for pytest In-Reply-To: <568FB74D.3080903@netspace.net.au> References: <568F5D54.1010401@netspace.net.au> <20160108084900.GM3793@merlinux.eu> <568FA6E1.8040807@netspace.net.au> <568FB74D.3080903@netspace.net.au> Message-ID: Would collection hooks help you here? Eg: skip/filter files that aren't part of matplotlib. pytest.org/latest/writing_plugins.html#collection-hooks Thanks, -- Ionel Cristian M?rie?, http://blog.ionelmc.ro On Fri, Jan 8, 2016 at 3:19 PM, Jason King wrote: > > I'll give testpaths a go and see what happens. >> _______________________________________________ >> > > turns out I'd specified 'testpaths = tests' already in tox.ini > > one thing I didn't make clear, running pytest.main() with the arguments I > listed > earlier means that Its looking at the matplotlib install location, (ie in > the site-packages dir, > inside the venv, next to where numpy is installed. (not where the files > were unpacked from) > > _______________________________________________ > 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 edluzonjr at gmail.com Fri Jan 8 12:30:26 2016 From: edluzonjr at gmail.com (Ernesto D. Luzon Jr.) Date: Fri, 8 Jan 2016 17:30:26 +0000 Subject: [pytest-dev] More flexibility on test function naming conventions Message-ID: Hi All, Is there a way to specify multiple naming conventions for test functions? For example, in my pytest.ini, I would like: [pytest] python_functions=[given, when, then, and, but] Then pytest can discover functions such as: def given_iam_an_author(): pass def and_i_wrote_an_article(): pass def when_i_do_this(): pass def then_result_is_good(): pass If this functionality doesn't exist yet, any hint on which pytest code I can play with to experiment on this? Many thanks, Ernesto D. Luzon Jr. -------------- next part -------------- An HTML attachment was scrubbed... URL: From raphael at hackebrot.de Fri Jan 8 12:35:35 2016 From: raphael at hackebrot.de (Raphael Pierzina) Date: Fri, 8 Jan 2016 17:35:35 +0000 Subject: [pytest-dev] More flexibility on test function naming conventions In-Reply-To: References: Message-ID: Hi Ernesto, maybe this is what you are looking for https://pytest.org/latest/customize.html#confval-python_functions hth Raphael > On 08 Jan 2016, at 17:30, Ernesto D. Luzon Jr. wrote: > > Hi All, > > Is there a way to specify multiple naming conventions for test functions? > > For example, in my pytest.ini, I would like: > > [pytest] > python_functions=[given, when, then, and, but] > > > Then pytest can discover functions such as: > > def given_iam_an_author(): pass > def and_i_wrote_an_article(): pass > def when_i_do_this(): pass > def then_result_is_good(): pass > > If this functionality doesn't exist yet, any hint on which pytest code I can play with to experiment on this? > > Many thanks, > Ernesto D. Luzon Jr. > _______________________________________________ > 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 digitalxero at gmail.com Fri Jan 8 16:49:00 2016 From: digitalxero at gmail.com (Dj Gilcrease) Date: Fri, 08 Jan 2016 21:49:00 +0000 Subject: [pytest-dev] More flexibility on test function naming conventions In-Reply-To: References: Message-ID: You may also want to look at https://github.com/pytest-dev/pytest-bdd On Fri, Jan 8, 2016 at 9:47 AM Raphael Pierzina wrote: > Hi Ernesto, > > maybe this is what you are looking for > https://pytest.org/latest/customize.html#confval-python_functions > > hth > Raphael > > On 08 Jan 2016, at 17:30, Ernesto D. Luzon Jr. > wrote: > > Hi All, > > Is there a way to specify multiple naming conventions for test functions? > > For example, in my pytest.ini, I would like: > > [pytest] > python_functions=[given, when, then, and, but] > > > Then pytest can discover functions such as: > > def given_iam_an_author(): pass > def and_i_wrote_an_article(): pass > def when_i_do_this(): pass > def then_result_is_good(): pass > > If this functionality doesn't exist yet, any hint on which pytest code I > can play with to experiment on this? > > Many thanks, > Ernesto D. Luzon Jr. > _______________________________________________ > 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 omarkohl at gmail.com Fri Jan 8 17:09:45 2016 From: omarkohl at gmail.com (Omar Kohl) Date: Fri, 8 Jan 2016 23:09:45 +0100 Subject: [pytest-dev] pytest sprint 2016 / getting started In-Reply-To: <20160107104028.GB3793@merlinux.eu> References: <20160107104028.GB3793@merlinux.eu> Message-ID: <569033A9.7000409@gmail.com> Hi there, I live in Freiburg and I was at the EuroPython 2015 pytest sprint. I would very much like to participate and my travel and lodging costs are 0? :-D Kind regards, Omar El 07/01/16 a las 11:40, holger krekel escribi?: > Hey all, > > let's try to find out if we can make a pytest sprint happen in 2016. > Here are some suggestions/thoughts on key points. > > Participants: anyway who has contributed to pytest in recent years but also > interested newcomers/wanna-be-contributors. Contributors are eligible > for getting their travel costs reimbursed (see funding below). > > Location: somewhere around Freiburg, black forest, Germany. > > Date ranges: > > 20-26th June or > > 30th June - 6th July. > > Travel: arrive on the first day, leave the last. > > Funding: we'll do a Indiegogo or betterplace.org campaign and ask > companies and individuals to help come up with funding for travel > costs, lodging and food for participants. If participants can come > on their company's time and money even better. In fact, the gathering > will be a great opportunity to dive deeper into pytest and make the best > use of it for your company. > > sprint contents: pytest-3.0 and a major new revision of the xdist plugin? > Cleaning up wards, introducing new features (to be continued ...). > > deadline for funding compaign: maybe February/March > so everybody can start booking. > > Who'd be up for it? how much do you estimate you need for travel? > Would the date range fit? > > best, > holger > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev -- Omar Kohl *************************************************************** Emails are not secure! They can be read and even modified by a third party. http://en.wikipedia.org/wiki/Email#Privacy_concerns Use OpenPGP for secure encryption: Thunderbird & Enigmail are free and easy to configure. For Windows users: Gpg4win. My PGP fingerprint: C226 AAB4 ADB4 901B D0E5 6DD4 4624 3C28 C092 F79E *************************************************************** From edluzonjr at gmail.com Fri Jan 8 22:57:14 2016 From: edluzonjr at gmail.com (Ernesto D. Luzon Jr.) Date: Sat, 9 Jan 2016 03:57:14 +0000 Subject: [pytest-dev] More flexibility on test function naming conventions In-Reply-To: References: Message-ID: Thanks Raphael, It is almost the thing that I want, however, I would like to be able to pass a tuple/list to pytest_functions. This way, I think, will allow me to instruct pytest to collect specific set of function prefixes without the need to end all my test functions with a specific suffix. So instead of python_functions=*_check, something like python_functions=[given, when, then, and, but] would be more desirable. Thanks Dj, I am also aware of pytest-bdd plugin, however, I think my particular case can not be handled with this plugin. To demonstrate further, I created this example BDD test written in Jupyter. https://github.com/ldiary/marigoso/blob/master/notes/an_example_of_using_jupyter_for_documenting_and_automating_bdd_style_tests.ipynb My future plan is to write a pytest plugin that can discover and run tests written like these in Jupyter, but I am just a novice python programmer so I want to start small steps by first writing a script that can copy and paste these into test functions pytest can collect. Many thanks, Ernesto D. Luzon Jr. On Fri, Jan 8, 2016 at 9:49 PM, Dj Gilcrease wrote: > You may also want to look at > > https://github.com/pytest-dev/pytest-bdd > > > > On Fri, Jan 8, 2016 at 9:47 AM Raphael Pierzina > wrote: > >> Hi Ernesto, >> >> maybe this is what you are looking for >> https://pytest.org/latest/customize.html#confval-python_functions >> >> hth >> Raphael >> >> On 08 Jan 2016, at 17:30, Ernesto D. Luzon Jr. >> wrote: >> >> Hi All, >> >> Is there a way to specify multiple naming conventions for test functions? >> >> For example, in my pytest.ini, I would like: >> >> [pytest] >> python_functions=[given, when, then, and, but] >> >> >> Then pytest can discover functions such as: >> >> def given_iam_an_author(): pass >> def and_i_wrote_an_article(): pass >> def when_i_do_this(): pass >> def then_result_is_good(): pass >> >> If this functionality doesn't exist yet, any hint on which pytest code I >> can play with to experiment on this? >> >> Many thanks, >> Ernesto D. Luzon Jr. >> _______________________________________________ >> 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 edluzonjr at gmail.com Sat Jan 9 05:16:27 2016 From: edluzonjr at gmail.com (Ernesto D. Luzon Jr.) Date: Sat, 9 Jan 2016 10:16:27 +0000 Subject: [pytest-dev] More flexibility on test function naming conventions In-Reply-To: References: Message-ID: Hi All, I found the solution. It is already implemented in pytest but the usage only exists in the test and not in the documentation. I looked backed on Bruno's commit here and made a similar pytest.ini file he created for the test. https://bitbucket.org/pytest-dev/pytest/commits/4fb4cb5ae00f So in my case, this is the perfect solution: [pytest] python_functions = given and when then but Many thanks, Ernesto D. Luzon Jr. On Sat, Jan 9, 2016 at 3:57 AM, Ernesto D. Luzon Jr. wrote: > Thanks Raphael, > > It is almost the thing that I want, however, I would like to be able > to pass a tuple/list to pytest_functions. > This way, I think, will allow me to instruct pytest to collect > specific set of function prefixes without the need to end all my test > functions with a specific suffix. > So instead of python_functions=*_check, something > like python_functions=[given, when, then, and, but] would be more desirable. > > > Thanks Dj, > > I am also aware of pytest-bdd plugin, however, I think my particular > case can not be handled with this plugin. > To demonstrate further, I created this example BDD test written in > Jupyter. > > https://github.com/ldiary/marigoso/blob/master/notes/an_example_of_using_jupyter_for_documenting_and_automating_bdd_style_tests.ipynb > > My future plan is to write a pytest plugin that can discover and run > tests written like these in Jupyter, but I am just a novice python > programmer so I want to start small steps by first writing a script that > can copy and paste these into test functions pytest can collect. > > Many thanks, > Ernesto D. Luzon Jr. > > > On Fri, Jan 8, 2016 at 9:49 PM, Dj Gilcrease > wrote: > >> You may also want to look at >> >> https://github.com/pytest-dev/pytest-bdd >> >> >> >> On Fri, Jan 8, 2016 at 9:47 AM Raphael Pierzina >> wrote: >> >>> Hi Ernesto, >>> >>> maybe this is what you are looking for >>> https://pytest.org/latest/customize.html#confval-python_functions >>> >>> hth >>> Raphael >>> >>> On 08 Jan 2016, at 17:30, Ernesto D. Luzon Jr. >>> wrote: >>> >>> Hi All, >>> >>> Is there a way to specify multiple naming conventions for test functions? >>> >>> For example, in my pytest.ini, I would like: >>> >>> [pytest] >>> python_functions=[given, when, then, and, but] >>> >>> >>> Then pytest can discover functions such as: >>> >>> def given_iam_an_author(): pass >>> def and_i_wrote_an_article(): pass >>> def when_i_do_this(): pass >>> def then_result_is_good(): pass >>> >>> If this functionality doesn't exist yet, any hint on which pytest code I >>> can play with to experiment on this? >>> >>> Many thanks, >>> Ernesto D. Luzon Jr. >>> _______________________________________________ >>> 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 nicoddemus at gmail.com Sat Jan 9 08:38:55 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Sat, 09 Jan 2016 13:38:55 +0000 Subject: [pytest-dev] pytest.org down? Message-ID: Hi guys, Is pytest.org down? To me it lands on a ?Go Daddy? domain sales site? []s, ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Sat Jan 9 08:41:06 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Sat, 09 Jan 2016 13:41:06 +0000 Subject: [pytest-dev] More flexibility on test function naming conventions In-Reply-To: References: Message-ID: Ernesto, Nice that you found the solution. Just to note that the documentation seems correct: .. confval:: python_functions One or more name prefixes or glob-patterns determining which test functions and methods are considered tests. Cheers, Bruno. On Sat, Jan 9, 2016 at 8:16 AM Ernesto D. Luzon Jr. wrote: > Hi All, > > I found the solution. It is already implemented in pytest but the usage > only exists in the test and not in the documentation. > I looked backed on Bruno's commit here and made a similar pytest.ini file > he created for the test. > https://bitbucket.org/pytest-dev/pytest/commits/4fb4cb5ae00f > > So in my case, this is the perfect solution: > [pytest] > python_functions = given and when then but > > Many thanks, > Ernesto D. Luzon Jr. > > On Sat, Jan 9, 2016 at 3:57 AM, Ernesto D. Luzon Jr. > wrote: > >> Thanks Raphael, >> >> It is almost the thing that I want, however, I would like to be able >> to pass a tuple/list to pytest_functions. >> This way, I think, will allow me to instruct pytest to collect >> specific set of function prefixes without the need to end all my test >> functions with a specific suffix. >> So instead of python_functions=*_check, something >> like python_functions=[given, when, then, and, but] would be more desirable. >> >> >> Thanks Dj, >> >> I am also aware of pytest-bdd plugin, however, I think my particular >> case can not be handled with this plugin. >> To demonstrate further, I created this example BDD test written in >> Jupyter. >> >> https://github.com/ldiary/marigoso/blob/master/notes/an_example_of_using_jupyter_for_documenting_and_automating_bdd_style_tests.ipynb >> >> My future plan is to write a pytest plugin that can discover and run >> tests written like these in Jupyter, but I am just a novice python >> programmer so I want to start small steps by first writing a script that >> can copy and paste these into test functions pytest can collect. >> >> Many thanks, >> Ernesto D. Luzon Jr. >> >> >> On Fri, Jan 8, 2016 at 9:49 PM, Dj Gilcrease >> wrote: >> >>> You may also want to look at >>> >>> https://github.com/pytest-dev/pytest-bdd >>> >>> >>> >>> On Fri, Jan 8, 2016 at 9:47 AM Raphael Pierzina >>> wrote: >>> >>>> Hi Ernesto, >>>> >>>> maybe this is what you are looking for >>>> https://pytest.org/latest/customize.html#confval-python_functions >>>> >>>> hth >>>> Raphael >>>> >>>> On 08 Jan 2016, at 17:30, Ernesto D. Luzon Jr. >>>> wrote: >>>> >>>> Hi All, >>>> >>>> Is there a way to specify multiple naming conventions for test >>>> functions? >>>> >>>> For example, in my pytest.ini, I would like: >>>> >>>> [pytest] >>>> python_functions=[given, when, then, and, but] >>>> >>>> >>>> Then pytest can discover functions such as: >>>> >>>> def given_iam_an_author(): pass >>>> def and_i_wrote_an_article(): pass >>>> def when_i_do_this(): pass >>>> def then_result_is_good(): pass >>>> >>>> If this functionality doesn't exist yet, any hint on which pytest code >>>> I can play with to experiment on this? >>>> >>>> Many thanks, >>>> Ernesto D. Luzon Jr. >>>> _______________________________________________ >>>> 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 >>>> >>> >> > _______________________________________________ > 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 raphael at hackebrot.de Sat Jan 9 08:42:40 2016 From: raphael at hackebrot.de (Raphael Pierzina) Date: Sat, 9 Jan 2016 13:42:40 +0000 Subject: [pytest-dev] pytest.org down? In-Reply-To: References: Message-ID: Hi Bruno, I get ?The connection to the server was reset while the page was loading.? :( Raphael > On 09 Jan 2016, at 13:38, Bruno Oliveira wrote: > > Hi guys, > > Is pytest.org down? To me it lands on a ?Go Daddy? domain sales site? > > []s, > > _______________________________________________ > 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 holger at merlinux.eu Sat Jan 9 16:58:04 2016 From: holger at merlinux.eu (holger krekel) Date: Sat, 9 Jan 2016 21:58:04 +0000 Subject: [pytest-dev] pytest.org down? In-Reply-To: References: Message-ID: <20160109215804.GQ3793@merlinux.eu> Hey Bruno, all, thanks for notifying, there was a problem with a credit card and their notification was indistiguishable from spam it seems. Prolonged it now, should be back soon. holger On Sat, Jan 09, 2016 at 13:38 +0000, Bruno Oliveira wrote: > Hi guys, > > Is pytest.org down? To me it lands on a ?Go Daddy? domain sales site? > > []s, > ? > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev -- about me: http://holgerkrekel.net/about-me/ contracting: http://merlinux.eu From flub at devork.be Sun Jan 10 14:08:45 2016 From: flub at devork.be (Floris Bruynooghe) Date: Sun, 10 Jan 2016 19:08:45 +0000 Subject: [pytest-dev] pytest sprint 2016 / getting started In-Reply-To: References: <20160107104028.GB3793@merlinux.eu> Message-ID: On 10 Jan 2016 18:59, "Floris Bruynooghe" wrote: > > On 8 Jan 2016 09:11, "Floris Bruynooghe" wrote: > > > Date ranges: > > > > > > 20-26th June or > > > > > > 30th June - 6th July. > > > > > > Travel: arrive on the first day, leave the last. > > > > This is a little trick for me I think. I'm supposed to attend > > Monitorama in PDX which is 27-29 June so right in between these dates. > > As that's for work and we're suppose to sponsor I imagine I'll be very > > busy just before. The week after might be better but I'd miss the > > start I imagine and as my boss is taking that time off already I'm not > > sure I can abandon the others in the office. > > Had a quick chat about this and seems like the first dates proposed should be easier then I thought, at worst I may have to leave a day early or so. > > Floris -------------- next part -------------- An HTML attachment was scrubbed... URL: From brianna.laugher at gmail.com Mon Jan 11 19:55:20 2016 From: brianna.laugher at gmail.com (Brianna Laugher) Date: Tue, 12 Jan 2016 11:55:20 +1100 Subject: [pytest-dev] pytest sprint 2016 / getting started In-Reply-To: References: <20160107104028.GB3793@merlinux.eu> Message-ID: I spoke to them and they seem positive about working something out, so I'm tentatively in :DDD On 8 January 2016 at 23:52, Brianna Laugher wrote: > The dates are fine for me and I would love to come, but a bigger question > is if I can justify flying to Europe from Australia for such a short trip. > I am starting a new job in February and should have enough leave for that, > but not much more. I guess I will raise it with my future bosses and see > what they say. > -- They've just been waiting in a mountain for the right moment: http://modernthings.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at merlinux.eu Tue Jan 12 16:54:47 2016 From: holger at merlinux.eu (holger krekel) Date: Tue, 12 Jan 2016 21:54:47 +0000 Subject: [pytest-dev] tentative pytest sprint june 2016 / funding In-Reply-To: <20160107104028.GB3793@merlinux.eu> References: <20160107104028.GB3793@merlinux.eu> Message-ID: <20160112215447.GE3793@merlinux.eu> Hey Florian, Bruno, Brianna, Floris, Omar, all, great to hear that 20-26th June could work for you all! Ronny is missing though and i haven't heart from Anatoly for a longer time. I slightly prefer the june date to attaching the sprint to EuroPython2016 which i am not sure i'll make. As i am bound to be on travels (currently in San Francisco) quite a bit this year i'd prefer hosting the sprint in Freiburg to not add yet another longer duration where i am completely away from family. So now that we have a tentative plan i think it's time to go for the funding campaign! If no one beats me to it i can see to draft a text end january. I guess we can ask for EUR 4000 to be on the safe side as it stands. my company could handle the accounting or we appoint someone else who does it (i am not eager so please step foward if you like -- the overhead with my accountant is probably 10% :) Anyone prefering a particular platform like indiegogo or betterplace or so? I don't have much experience with those platforms myself. If we aim at getting primarily companies to fund it we could even go without those platforms and just setup a campain page on pytest.org and provide a contact mail. A company funding it is also invited to send their developer(s) to participate, learn and contribute for mutual benefit?! :) best, holger On Thu, Jan 07, 2016 at 10:40 +0000, holger krekel wrote: > Hey all, > > let's try to find out if we can make a pytest sprint happen in 2016. > Here are some suggestions/thoughts on key points. > > Participants: anyway who has contributed to pytest in recent years but also > interested newcomers/wanna-be-contributors. Contributors are eligible > for getting their travel costs reimbursed (see funding below). > > Location: somewhere around Freiburg, black forest, Germany. > > Date ranges: > > 20-26th June or > > 30th June - 6th July. > > Travel: arrive on the first day, leave the last. > > Funding: we'll do a Indiegogo or betterplace.org campaign and ask > companies and individuals to help come up with funding for travel > costs, lodging and food for participants. If participants can come > on their company's time and money even better. In fact, the gathering > will be a great opportunity to dive deeper into pytest and make the best > use of it for your company. > > sprint contents: pytest-3.0 and a major new revision of the xdist plugin? > Cleaning up wards, introducing new features (to be continued ...). > > deadline for funding compaign: maybe February/March > so everybody can start booking. > > Who'd be up for it? how much do you estimate you need for travel? > Would the date range fit? > > best, > holger > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -- about me: http://holgerkrekel.net/about-me/ contracting: http://merlinux.eu From opensource at ronnypfannschmidt.de Tue Jan 12 17:41:38 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Tue, 12 Jan 2016 23:41:38 +0100 Subject: [pytest-dev] tentative pytest sprint june 2016 / funding In-Reply-To: <20160112215447.GE3793@merlinux.eu> References: <20160107104028.GB3793@merlinux.eu> <20160112215447.GE3793@merlinux.eu> Message-ID: <56958122.5050601@ronnypfannschmidt.de> Hi all, I'm currently keeping it a bit out, I'm in the process of switching jobs, moving and some personal life changes, so i probably can't say anything in detail, until the beginning of may. However -- Ronny Am 12.01.2016 um 22:54 schrieb holger krekel: > Hey Florian, Bruno, Brianna, Floris, Omar, all, > > great to hear that 20-26th June could work for you all! > Ronny is missing though and i haven't heart from Anatoly > for a longer time. > > I slightly prefer the june date to attaching the sprint to > EuroPython2016 which i am not sure i'll make. As i am bound to be on > travels (currently in San Francisco) quite a bit this year i'd prefer > hosting the sprint in Freiburg to not add yet another longer duration > where i am completely away from family. > > So now that we have a tentative plan i think it's time to go for the > funding campaign! If no one beats me to it i can see to draft a text > end january. I guess we can ask for EUR 4000 to be on the safe side as > it stands. my company could handle the accounting or we appoint someone > else who does it (i am not eager so please step foward if you like -- > the overhead with my accountant is probably 10% :) > > Anyone prefering a particular platform like indiegogo or betterplace or > so? I don't have much experience with those platforms myself. If we > aim at getting primarily companies to fund it we could even go without > those platforms and just setup a campain page on pytest.org and provide > a contact mail. A company funding it is also invited to send their > developer(s) to participate, learn and contribute for mutual benefit?! > :) > > best, > holger > > > On Thu, Jan 07, 2016 at 10:40 +0000, holger krekel wrote: >> Hey all, >> >> let's try to find out if we can make a pytest sprint happen in 2016. >> Here are some suggestions/thoughts on key points. >> >> Participants: anyway who has contributed to pytest in recent years but also >> interested newcomers/wanna-be-contributors. Contributors are eligible >> for getting their travel costs reimbursed (see funding below). >> >> Location: somewhere around Freiburg, black forest, Germany. >> >> Date ranges: >> >> 20-26th June or >> >> 30th June - 6th July. >> >> Travel: arrive on the first day, leave the last. >> >> Funding: we'll do a Indiegogo or betterplace.org campaign and ask >> companies and individuals to help come up with funding for travel >> costs, lodging and food for participants. If participants can come >> on their company's time and money even better. In fact, the gathering >> will be a great opportunity to dive deeper into pytest and make the best >> use of it for your company. >> >> sprint contents: pytest-3.0 and a major new revision of the xdist plugin? >> Cleaning up wards, introducing new features (to be continued ...). >> >> deadline for funding compaign: maybe February/March >> so everybody can start booking. >> >> Who'd be up for it? how much do you estimate you need for travel? >> Would the date range fit? >> >> best, >> holger >> _______________________________________________ >> pytest-dev mailing list >> pytest-dev at python.org >> https://mail.python.org/mailman/listinfo/pytest-dev >> From brianna.laugher at gmail.com Tue Jan 12 19:24:12 2016 From: brianna.laugher at gmail.com (Brianna Laugher) Date: Wed, 13 Jan 2016 11:24:12 +1100 Subject: [pytest-dev] tentative pytest sprint june 2016 / funding In-Reply-To: <20160112215447.GE3793@merlinux.eu> References: <20160107104028.GB3793@merlinux.eu> <20160112215447.GE3793@merlinux.eu> Message-ID: I guess more people might be able to commit to participating when event details are locked down. Bit of a catch 22 for organising. I don't have a preference on platform (I think kickstarter is best if making a lot of money/getting a lot of backers is the most important thing, which it's probably not here), but I strongly recommend not doing it yourself. :) http://funding.openinitiative.com/ is specifically for open source projects though. PSF will probably contribute a bit too https://www.python.org/psf/grants/ cheers Brianna On 13 January 2016 at 08:54, holger krekel wrote: > Hey Florian, Bruno, Brianna, Floris, Omar, all, > > great to hear that 20-26th June could work for you all! > Ronny is missing though and i haven't heart from Anatoly > for a longer time. > > I slightly prefer the june date to attaching the sprint to > EuroPython2016 which i am not sure i'll make. As i am bound to be on > travels (currently in San Francisco) quite a bit this year i'd prefer > hosting the sprint in Freiburg to not add yet another longer duration > where i am completely away from family. > > So now that we have a tentative plan i think it's time to go for the > funding campaign! If no one beats me to it i can see to draft a text > end january. I guess we can ask for EUR 4000 to be on the safe side as > it stands. my company could handle the accounting or we appoint someone > else who does it (i am not eager so please step foward if you like -- > the overhead with my accountant is probably 10% :) > > Anyone prefering a particular platform like indiegogo or betterplace or > so? I don't have much experience with those platforms myself. If we > aim at getting primarily companies to fund it we could even go without > those platforms and just setup a campain page on pytest.org and provide > a contact mail. A company funding it is also invited to send their > developer(s) to participate, learn and contribute for mutual benefit?! > :) > > best, > holger > > > On Thu, Jan 07, 2016 at 10:40 +0000, holger krekel wrote: > > Hey all, > > > > let's try to find out if we can make a pytest sprint happen in 2016. > > Here are some suggestions/thoughts on key points. > > > > Participants: anyway who has contributed to pytest in recent years but > also > > interested newcomers/wanna-be-contributors. Contributors are eligible > > for getting their travel costs reimbursed (see funding below). > > > > Location: somewhere around Freiburg, black forest, Germany. > > > > Date ranges: > > > > 20-26th June or > > > > 30th June - 6th July. > > > > Travel: arrive on the first day, leave the last. > > > > Funding: we'll do a Indiegogo or betterplace.org campaign and ask > > companies and individuals to help come up with funding for travel > > costs, lodging and food for participants. If participants can come > > on their company's time and money even better. In fact, the gathering > > will be a great opportunity to dive deeper into pytest and make the best > > use of it for your company. > > > > sprint contents: pytest-3.0 and a major new revision of the xdist plugin? > > Cleaning up wards, introducing new features (to be continued ...). > > > > deadline for funding compaign: maybe February/March > > so everybody can start booking. > > > > Who'd be up for it? how much do you estimate you need for travel? > > Would the date range fit? > > > > best, > > holger > > _______________________________________________ > > pytest-dev mailing list > > pytest-dev at python.org > > https://mail.python.org/mailman/listinfo/pytest-dev > > > > -- > about me: http://holgerkrekel.net/about-me/ > contracting: http://merlinux.eu > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -- They've just been waiting in a mountain for the right moment: http://modernthings.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Thu Jan 14 19:15:39 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Fri, 15 Jan 2016 00:15:39 +0000 Subject: [pytest-dev] Testing pytest releases using devpi and CI servers Message-ID: Hi guys, Recently we discussed how one could test pytest release packages using devpi in multiple machines, before the release is made official. I created a small repository[1] which only contains appveyor and travis scripts which simply use "devpi test" to test and publish results for the pytest 2.8.5 release[2] in Travis and AppVeyor. IMO this greatly facilitates the process and ensures the package is being tested in clean machine to boot. I'm thinking, if pytest core developers like this idea, to make the repository more general (so any core developer can use it to test devpi packages) and make it the recommended way to test release packages before publishing them to PyPI. The repository is just a proof of concept to see what others think, so opinions are welcome! Bruno. [1] https://github.com/nicoddemus/devpi-pytest [2] https://devpi.net/nicoddemus/dev/pytest/2.8.5 -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Fri Jan 15 00:15:37 2016 From: me at the-compiler.org (Florian Bruhin) Date: Fri, 15 Jan 2016 06:15:37 +0100 Subject: [pytest-dev] Testing pytest releases using devpi and CI servers In-Reply-To: References: Message-ID: <20160115051537.GD22730@tonks> Hey, * Bruno Oliveira [2016-01-15 00:15:39 +0000]: > I created a small repository[1] which only contains appveyor and travis > scripts which simply use "devpi test" to test and publish results for the > pytest 2.8.5 release[2] in Travis and AppVeyor. Thanks! This is about what I imagined when talking about it in the Hangout. I wanted to write a more detailed proposal to the ML but never got to it ;) As I said there, the devpi part was the most painful point of doing the release for me (not because of devpi directly, I think). I had to set it up on multiple machines, and had various trouble ([1]) which nobody else seems to be having, which why I'd like a reproducible environment. [1] https://github.com/pytest-dev/pytest/issues/1114 https://github.com/pytest-dev/pytest/issues/1115 https://github.com/pytest-dev/pytest/issues/1116 Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From c.buelter at arcor.de Sat Jan 16 08:43:44 2016 From: c.buelter at arcor.de (Christoph Buelter) Date: Sat, 16 Jan 2016 14:43:44 +0100 Subject: [pytest-dev] Introspecting fixtures from within a test Message-ID: <569A4910.9060109@arcor.de> Hi there, I have a small question about fixtures. Basically inside a test function I would like to know which fixtures are active/avaialable and I want to be able to reference them and get their return values. @pytest.fixture def inner(): return 1 @pytest.fixture def foo(inner): return 2 @pytest.fixture def bar(): return 3 @pytest.mark.bar def test_foo(foo): # Let's assume the 'bar' mark magically requests the bar fixture. # Now all of 'inner', 'foo' and 'bar' should be available in here. # Is there a way to actually reference them here and get their # return values, e.g. like: request.getfuncargvalue(...) but # only for fixtures that have alreay been requested? pass I hope that makes sense to you. I am new to pytest development, so if there is a section in the docs that covers this that I have missed, any pointers would be greatly appreciated. Cheers, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From raphael at hackebrot.de Sat Jan 16 10:26:00 2016 From: raphael at hackebrot.de (Raphael Pierzina) Date: Sat, 16 Jan 2016 15:26:00 +0000 Subject: [pytest-dev] Introspecting fixtures from within a test In-Reply-To: <569A4910.9060109@arcor.de> References: <569A4910.9060109@arcor.de> Message-ID: Hi Christoph, you can retrieve the used fixtures from the test node and use named function right after. See https://gist.github.com/hackebrot/848ab671583540fe18d1 Hope this helps! Raphael > On 16 Jan 2016, at 13:43, Christoph Buelter wrote: > > Hi there, > > I have a small question about fixtures. Basically inside a test function I would like to know which fixtures are active/avaialable and I want to be able to reference them and get their return values. > > @pytest.fixture > def inner(): > return 1 > > @pytest.fixture > def foo(inner): > return 2 > > @pytest.fixture > def bar(): > return 3 > > @pytest.mark.bar > def test_foo(foo): > # Let's assume the 'bar' mark magically requests the bar fixture. > # Now all of 'inner', 'foo' and 'bar' should be available in here. > # Is there a way to actually reference them here and get their > # return values, e.g. like: request.getfuncargvalue(...) but > # only for fixtures that have alreay been requested? > pass > > I hope that makes sense to you. I am new to pytest development, so if there is a section in the docs that covers this that I have missed, any pointers would be greatly appreciated. > > Cheers, > Christoph > > > _______________________________________________ > 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 holger at merlinux.eu Sat Jan 16 15:01:33 2016 From: holger at merlinux.eu (Holger Krekel) Date: Sat, 16 Jan 2016 12:01:33 -0800 Subject: [pytest-dev] Testing pytest releases using devpi and CI servers In-Reply-To: <20160115051537.GD22730@tonks> References: <20160115051537.GD22730@tonks> Message-ID: <32DD96DB-3128-4041-8FD5-E7767A093E97@merlinux.eu> The crucial part that is missing wrt to devpi/tox/pytest is the ability to automatically schedule tests to hosts. Rackspace provides us some funding for open source which we can use to have a Windows and a Linux host for running tests. A Windows machine already exists, 4 cores, 8 gigs ram. We could make them ssh accessible for all ssh keys we have from contributors for the time being so that no one needs to setup hosts and everyone can go to the machines to check failures out, reproduce them, work on them. If someone has a nice ansible/chef/... Recipe for setting up a Linux box with all interpreters, headers files and c compiler environment, virtualenv that'd be helpful. I can also hand someone credentials to start/stop machines. Help welcome. Maybe a little script that goes to the hosts and runs "devpi test..." would be good to automate the final step. The other remaining automation issues are the docs/pdf generation and pytest.org docs push. Greetings from sf, holger On January 14, 2016 9:15:37 PM PST, Florian Bruhin wrote: >Hey, > >* Bruno Oliveira [2016-01-15 00:15:39 +0000]: >> I created a small repository[1] which only contains appveyor and >travis >> scripts which simply use "devpi test" to test and publish results for >the >> pytest 2.8.5 release[2] in Travis and AppVeyor. > >Thanks! This is about what I imagined when talking about it in the >Hangout. I wanted to write a more detailed proposal to the ML but >never got to it ;) > >As I said there, the devpi part was the most painful point of doing >the release for me (not because of devpi directly, I think). I had to >set it up on multiple machines, and had various trouble ([1]) which >nobody else seems to be having, which why I'd like a reproducible >environment. > >[1] https://github.com/pytest-dev/pytest/issues/1114 > https://github.com/pytest-dev/pytest/issues/1115 > https://github.com/pytest-dev/pytest/issues/1116 > >Florian > >-- >http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) > GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc > I love long mails! | http://email.is-not-s.ms/ > > >------------------------------------------------------------------------ > >_______________________________________________ >pytest-dev mailing list >pytest-dev at python.org >https://mail.python.org/mailman/listinfo/pytest-dev -- Sent using mobile touch keys, increased chances for errors and misunderstandings. Enjoy! -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Sat Jan 16 16:37:42 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Sat, 16 Jan 2016 21:37:42 +0000 Subject: [pytest-dev] Testing pytest releases using devpi and CI servers In-Reply-To: <32DD96DB-3128-4041-8FD5-E7767A093E97@merlinux.eu> References: <20160115051537.GD22730@tonks> <32DD96DB-3128-4041-8FD5-E7767A093E97@merlinux.eu> Message-ID: Hi Holger, On Sat, Jan 16, 2016 at 6:01 PM Holger Krekel wrote: > The crucial part that is missing wrt to devpi/tox/pytest is the ability to > automatically schedule tests to hosts. Rackspace provides us some funding > for open source which we can use to have a Windows and a Linux host for > running tests. A Windows machine already exists, 4 cores, 8 gigs ram. We > could make them ssh accessible for all ssh keys we have from contributors > for the time being so that no one needs to setup hosts and everyone can go > to the machines to check failures out, reproduce them, work on them. If > someone has a nice ansible/chef/... Recipe for setting up a Linux box with > all interpreters, headers files and c compiler environment, virtualenv > that'd be helpful. I can also hand someone credentials to start/stop > machines. Help welcome. > > Maybe a little script that goes to the hosts and runs "devpi test..." > would be good to automate the final step > Do you mean regarding devpi in general, or for testing pytest releases specifically? If the latter, what would be the advantages of using such a system instead of the existing Travis/AppVeyor infrastructure? With my quick experiment I was able to successfully test 2.8.5 using devpi across all interpreter versions in Linux and Windows, integrated with GitHub. It would be just a couple more hours of work to make the repository generic and useful by all pytest contributors in order to test the package before a release. > The other remaining automation issues are the docs/pdf generation and > pytest.org docs push. > Sure. I also think this can be handled by Travis, we just would need to generate a new deployment key for Travis, which we could securely encrypt into the .travis.yml file itself. This way documentation could be automatically generated and uploaded. I think Ronny has a similar idea. Cheers, Bruno. > > Greetings from sf, holger > > > > > > > > On January 14, 2016 9:15:37 PM PST, Florian Bruhin > wrote: >> >> Hey, >> >> * Bruno Oliveira [2016-01-15 00:15:39 +0000]: >> >>> I created a small repository[1] which only contains appveyor and travis >>> scripts which simply use "devpi test" to test and publish results for the >>> pytest 2.8.5 release[2] in Travis and AppVeyor. >>> >> >> Thanks! This is about what I imagined when talking about it in the >> Hangout. I wanted to write a more detailed proposal to the ML but >> never got to it ;) >> >> As I said there, the devpi part was the most painful point of doing >> the release for me (not because of devpi directly, I think). I had to >> set it up on multiple machines, and had various trouble ([1]) which >> nobody else seems to be having, which why I'd like a reproducible >> environment. >> >> [1] https://github.com/pytest-dev/pytest/issues/1114 >> https://github.com/pytest-dev/pytest/issues/1115 >> https://github.com/pytest-dev/pytest/issues/1116 >> >> Florian >> >> > -- > Sent using mobile touch keys, increased chances for errors and > misunderstandings. Enjoy! > _______________________________________________ > 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 holger at merlinux.eu Sat Jan 16 21:32:20 2016 From: holger at merlinux.eu (Holger Krekel) Date: Sat, 16 Jan 2016 18:32:20 -0800 Subject: [pytest-dev] Testing pytest releases using devpi and CI servers In-Reply-To: References: <20160115051537.GD22730@tonks> <32DD96DB-3128-4041-8FD5-E7767A093E97@merlinux.eu> Message-ID: <7228B76C-5749-4908-8CEE-23BE645301E5@merlinux.eu> Haven't played yet with your integration code. So I can't contrast it. It was indeed a more general comment regarding what I perceive as the missing piece in open source testing infrastructure. It's true that I kind of am uncomfortable with using commercial hosting services like appveyor and Travis if the platform is not driven by open source software. Practicality beats purity sometimes though. Cheers holger On January 16, 2016 1:37:42 PM PST, Bruno Oliveira wrote: >Hi Holger, > >On Sat, Jan 16, 2016 at 6:01 PM Holger Krekel >wrote: > >> The crucial part that is missing wrt to devpi/tox/pytest is the >ability to >> automatically schedule tests to hosts. Rackspace provides us some >funding >> for open source which we can use to have a Windows and a Linux host >for >> running tests. A Windows machine already exists, 4 cores, 8 gigs ram. >We >> could make them ssh accessible for all ssh keys we have from >contributors >> for the time being so that no one needs to setup hosts and everyone >can go >> to the machines to check failures out, reproduce them, work on them. >If >> someone has a nice ansible/chef/... Recipe for setting up a Linux box >with >> all interpreters, headers files and c compiler environment, >virtualenv >> that'd be helpful. I can also hand someone credentials to start/stop >> machines. Help welcome. >> >> Maybe a little script that goes to the hosts and runs "devpi test..." >> would be good to automate the final step >> > >Do you mean regarding devpi in general, or for testing pytest releases >specifically? > >If the latter, what would be the advantages of using such a system >instead >of the existing Travis/AppVeyor infrastructure? With my quick >experiment I >was able to successfully test 2.8.5 using devpi across all interpreter >versions in Linux and Windows, integrated with GitHub. It would be just >a >couple more hours of work to make the repository generic and useful by >all >pytest contributors in order to test the package before a release. > > >> The other remaining automation issues are the docs/pdf generation and >> pytest.org docs push. >> > >Sure. I also think this can be handled by Travis, we just would need to >generate a new deployment key for Travis, which we could securely >encrypt >into the .travis.yml file itself. This way documentation could be >automatically generated and uploaded. I think Ronny has a similar idea. > >Cheers, >Bruno. > > >> >> Greetings from sf, holger >> >> >> >> >> >> >> >> On January 14, 2016 9:15:37 PM PST, Florian Bruhin > >> wrote: >>> >>> Hey, >>> >>> * Bruno Oliveira [2016-01-15 00:15:39 +0000]: >>> >>>> I created a small repository[1] which only contains appveyor and >travis >>>> scripts which simply use "devpi test" to test and publish results >for the >>>> pytest 2.8.5 release[2] in Travis and AppVeyor. >>>> >>> >>> Thanks! This is about what I imagined when talking about it in the >>> Hangout. I wanted to write a more detailed proposal to the ML but >>> never got to it ;) >>> >>> As I said there, the devpi part was the most painful point of doing >>> the release for me (not because of devpi directly, I think). I had >to >>> set it up on multiple machines, and had various trouble ([1]) which >>> nobody else seems to be having, which why I'd like a reproducible >>> environment. >>> >>> [1] https://github.com/pytest-dev/pytest/issues/1114 >>> https://github.com/pytest-dev/pytest/issues/1115 >>> https://github.com/pytest-dev/pytest/issues/1116 >>> >>> Florian >>> >>> >> -- >> Sent using mobile touch keys, increased chances for errors and >> misunderstandings. Enjoy! >> _______________________________________________ >> pytest-dev mailing list >> pytest-dev at python.org >> https://mail.python.org/mailman/listinfo/pytest-dev >> -- Sent using mobile touch keys, increased chances for errors and misunderstandings. Enjoy! -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at pelme.se Sun Jan 17 10:39:09 2016 From: andreas at pelme.se (Andreas Pelme) Date: Sun, 17 Jan 2016 16:39:09 +0100 Subject: [pytest-dev] pytest sprint 2016 / getting started In-Reply-To: <20160107104028.GB3793@merlinux.eu> References: <20160107104028.GB3793@merlinux.eu> Message-ID: <390A3C1B-85E0-484B-9956-20073D8358E7@pelme.se> Hi all, > On 7 jan. 2016, at 11:40, holger krekel wrote: > > Who'd be up for it? how much do you estimate you need for travel? > Would the date range fit? This is great idea. I?m in and really looking forward to it. :) Both date ranges is good for me. My company will pay my expenses+contribute ~500 EUR to the funding campaign. Cheers, Andreas From raphael at hackebrot.de Sun Jan 17 15:22:56 2016 From: raphael at hackebrot.de (Raphael Pierzina) Date: Sun, 17 Jan 2016 20:22:56 +0000 Subject: [pytest-dev] pytest sprint 2016 / getting started In-Reply-To: <20160107104028.GB3793@merlinux.eu> References: <20160107104028.GB3793@merlinux.eu> Message-ID: <30D1621C-78AE-4CB4-B85D-764BBEF80DBE@hackebrot.de> Hi, I love the idea! Although I would happily attend the sprint, I don?t know if I will be able to make it. I relocated to Edinburgh, UK this month and joined a new company. Hope to get back to you with good news in a bit. Cheers Raphael > On 07 Jan 2016, at 10:40, holger krekel wrote: > > Hey all, > > let's try to find out if we can make a pytest sprint happen in 2016. > Here are some suggestions/thoughts on key points. > > Participants: anyway who has contributed to pytest in recent years but also > interested newcomers/wanna-be-contributors. Contributors are eligible > for getting their travel costs reimbursed (see funding below). > > Location: somewhere around Freiburg, black forest, Germany. > > Date ranges: > > 20-26th June or > > 30th June - 6th July. > > Travel: arrive on the first day, leave the last. > > Funding: we'll do a Indiegogo or betterplace.org campaign and ask > companies and individuals to help come up with funding for travel > costs, lodging and food for participants. If participants can come > on their company's time and money even better. In fact, the gathering > will be a great opportunity to dive deeper into pytest and make the best > use of it for your company. > > sprint contents: pytest-3.0 and a major new revision of the xdist plugin? > Cleaning up wards, introducing new features (to be continued ...). > > deadline for funding compaign: maybe February/March > so everybody can start booking. > > Who'd be up for it? how much do you estimate you need for travel? > Would the date range fit? > > best, > holger > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev From encukou at gmail.com Mon Jan 18 05:27:39 2016 From: encukou at gmail.com (Petr Viktorin) Date: Mon, 18 Jan 2016 11:27:39 +0100 Subject: [pytest-dev] Testing pytest releases using devpi and CI servers In-Reply-To: <7228B76C-5749-4908-8CEE-23BE645301E5@merlinux.eu> References: <20160115051537.GD22730@tonks> <32DD96DB-3128-4041-8FD5-E7767A093E97@merlinux.eu> <7228B76C-5749-4908-8CEE-23BE645301E5@merlinux.eu> Message-ID: <569CBE1B.1010100@gmail.com> On 01/17/2016 03:32 AM, Holger Krekel wrote: > Haven't played yet with your integration code. So I can't contrast it. > It was indeed a more general comment regarding what I perceive as the > missing piece in open source testing infrastructure. > > It's true that I kind of am uncomfortable with using commercial hosting > services like appveyor and Travis if the platform is not driven by open > source software. Practicality beats purity sometimes though. Interesting that you explicitly add "if the platform is not driven by open source software". The code for Travis CI is actually MIT-licensed: https://github.com/travis-ci Of course, the code is there but docs are mostly missing. The Github-style business model (free for open source, paid for private, expensive for on-premises) removes many incentives for them to support people/companies spinning up their own server. And the hosted app model makes it impossible to check that the sources they publish are actually what they run. Anyway they're certainly way more open-source than most SaaS. (Ironically, in the old days, lack of docs was a sure sign of a free/open source project...) From raphael at hackebrot.de Mon Jan 18 17:12:39 2016 From: raphael at hackebrot.de (Raphael Pierzina) Date: Mon, 18 Jan 2016 22:12:39 +0000 Subject: [pytest-dev] pytest sprint 2016 / getting started In-Reply-To: <20160107104028.GB3793@merlinux.eu> References: <20160107104028.GB3793@merlinux.eu> Message-ID: <13A4A05B-BD12-44C3-B4F7-220945D6682F@hackebrot.de> Hi friends, there?s been a blog post on FOSS funding recently, which received quite a bit of attention on HackerNews/Twitter and alike: https://medium.com/@nayafia/how-i-stumbled-upon-the-internet-s-biggest-blind-spot-b9aa23618c58#.kf5a41ubn The author Nadia Eghbal (@nayafia) now started a doc on projects that require support. https://twitter.com/nayafia/status/689174577302253568 I added pytest to the list and who knows, maybe it will help us fund the dev sprint. @Brianna: I put in the orgs twitter handle to get in touch. Please feel free to update this to what you feel suits best. Cheers Raphael > On 07 Jan 2016, at 10:40, holger krekel wrote: > > Hey all, > > let's try to find out if we can make a pytest sprint happen in 2016. > Here are some suggestions/thoughts on key points. > > Participants: anyway who has contributed to pytest in recent years but also > interested newcomers/wanna-be-contributors. Contributors are eligible > for getting their travel costs reimbursed (see funding below). > > Location: somewhere around Freiburg, black forest, Germany. > > Date ranges: > > 20-26th June or > > 30th June - 6th July. > > Travel: arrive on the first day, leave the last. > > Funding: we'll do a Indiegogo or betterplace.org campaign and ask > companies and individuals to help come up with funding for travel > costs, lodging and food for participants. If participants can come > on their company's time and money even better. In fact, the gathering > will be a great opportunity to dive deeper into pytest and make the best > use of it for your company. > > sprint contents: pytest-3.0 and a major new revision of the xdist plugin? > Cleaning up wards, introducing new features (to be continued ...). > > deadline for funding compaign: maybe February/March > so everybody can start booking. > > Who'd be up for it? how much do you estimate you need for travel? > Would the date range fit? > > best, > holger > _______________________________________________ > 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 brianna.laugher at gmail.com Mon Jan 18 23:36:56 2016 From: brianna.laugher at gmail.com (Brianna Laugher) Date: Tue, 19 Jan 2016 15:36:56 +1100 Subject: [pytest-dev] pytest sprint 2016 / getting started In-Reply-To: <13A4A05B-BD12-44C3-B4F7-220945D6682F@hackebrot.de> References: <20160107104028.GB3793@merlinux.eu> <13A4A05B-BD12-44C3-B4F7-220945D6682F@hackebrot.de> Message-ID: That's fine with me Raphael. BTW if anyone else would like to tweet for pytest, just contact me offlist to arrange :) I summarised the discussion etc so far here: https://github.com/pytest-dev/pytest/wiki/2016-dev-sprint and put some ideas I had about crowdfunding 'rewards'. I think more or less any github user can edit the wiki, so please do if you want to add something. cheers Brianna On 19 January 2016 at 09:12, Raphael Pierzina wrote: > Hi friends, > > there?s been a blog post on FOSS funding recently, which received quite a > bit of attention on HackerNews/Twitter and alike: > > https://medium.com/@nayafia/how-i-stumbled-upon-the-internet-s-biggest-blind-spot-b9aa23618c58#.kf5a41ubn > > The author Nadia Eghbal (@nayafia) now started a doc on projects that > require support. > https://twitter.com/nayafia/status/689174577302253568 > > I added pytest to the list and who knows, maybe it will help us fund the > dev sprint. > > @Brianna: I put in the orgs twitter handle to get in touch. Please feel > free to update this to what you feel suits best. > > Cheers > Raphael > > On 07 Jan 2016, at 10:40, holger krekel wrote: > > Hey all, > > let's try to find out if we can make a pytest sprint happen in 2016. > Here are some suggestions/thoughts on key points. > > Participants: anyway who has contributed to pytest in recent years but also > interested newcomers/wanna-be-contributors. Contributors are eligible > for getting their travel costs reimbursed (see funding below). > > Location: somewhere around Freiburg, black forest, Germany. > > Date ranges: > > 20-26th June or > > 30th June - 6th July. > > Travel: arrive on the first day, leave the last. > > Funding: we'll do a Indiegogo or betterplace.org campaign and ask > companies and individuals to help come up with funding for travel > costs, lodging and food for participants. If participants can come > on their company's time and money even better. In fact, the gathering > will be a great opportunity to dive deeper into pytest and make the best > use of it for your company. > > sprint contents: pytest-3.0 and a major new revision of the xdist plugin? > Cleaning up wards, introducing new features (to be continued ...). > > deadline for funding compaign: maybe February/March > so everybody can start booking. > > Who'd be up for it? how much do you estimate you need for travel? > Would the date range fit? > > best, > holger > _______________________________________________ > 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 > > -- They've just been waiting in a mountain for the right moment: http://modernthings.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pizza at netspace.net.au Tue Jan 19 07:37:07 2016 From: pizza at netspace.net.au (Jason King) Date: Tue, 19 Jan 2016 23:37:07 +1100 Subject: [pytest-dev] no self-awareness for pytest In-Reply-To: References: <568F5D54.1010401@netspace.net.au> <20160108084900.GM3793@merlinux.eu> <568FA6E1.8040807@netspace.net.au> <568FB74D.3080903@netspace.net.au> Message-ID: <569E2DF3.6010308@netspace.net.au> On 09/01/16 00:56, Ionel Cristian M?rie? wrote: > Would collection hooks help you here? Eg: skip/filter files that > aren't part of matplotlib. > > pytest.org/latest/writing_plugins.html#collection-hooks > > I followed your suggestion, and made a plugin that didn't allow files that had 'numpy' in its path, but the plugin never activated on such a file. so I think I've tracked down whats causing the problem I was experiencing: just to recap, I was getting an error of this (twice) _________ __ ERROR at setup of test ____________________________ file /home/travis/build/matplotlib/matplotlib/venv/lib/python2.7/site-packages/numpy/testing/nosetester.py, line 249 def test(self, label='fast', verbose=1, extra_argv=None, doctests=False, fixture 'self' not found available fixtures: tmpdir_factory, pytestconfig, cov, cache, recwarn, monkeypatch, record_xml_property, capfd, capsys, tmpdir use 'py.test --fixtures [testpath]' for help on them. /hom e/travis/ build/matplotlib/matplotlib/venv/lib/python2.7/site-packages/numpy/testing/nosetester.py:249 as it turns out, there were two files that was causing the error, and the line that seems to be doing it is.. from pylab import * yup, a import statement was doing it. only reason I found it was because of the instafail plugin (5 tests after a stack trace of a failing test, the pytest error appeared) Is it possible to have pytest print out the name of the test that its about to do , with the result , instead of ".....E.xsss..." etc? That would make weird occurrences/errors easier to find in future. -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Tue Jan 19 08:00:13 2016 From: me at the-compiler.org (Florian Bruhin) Date: Tue, 19 Jan 2016 14:00:13 +0100 Subject: [pytest-dev] no self-awareness for pytest In-Reply-To: <569E2DF3.6010308@netspace.net.au> References: <568F5D54.1010401@netspace.net.au> <20160108084900.GM3793@merlinux.eu> <568FA6E1.8040807@netspace.net.au> <568FB74D.3080903@netspace.net.au> <569E2DF3.6010308@netspace.net.au> Message-ID: <20160119130013.GD22126@tonks> * Jason King [2016-01-19 23:37:07 +1100]: > Is it possible to have pytest print out the name of the test that its about > to do , with the result , instead of ".....E.xsss..." etc? > That would make weird occurrences/errors easier to find in future. Invoke it with -v/--verbose. Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nicoddemus at gmail.com Fri Jan 22 14:56:34 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Fri, 22 Jan 2016 19:56:34 +0000 Subject: [pytest-dev] pytest 2.8.6 released Message-ID: Hey everyone, I'm happy to announce pytest 2.8.6 has been released. pytest is a widely used mature test runner both for unit and functional tests in Python. See http://pytest.org for documentation and examples. Here are the fixes for this release: - fix #1259: allow for double nodeids in junitxml, this was a regression failing plugins combinations like pytest-pep8 + pytest-flakes - Workaround for exception that occurs in pyreadline when using ``--pdb`` with standard I/O capture enabled. Thanks Erik M. Bray for the PR. - fix #900: Better error message in case the target of a ``monkeypatch`` call raises an ``ImportError``. - fix #1292: monkeypatch calls (setattr, setenv, etc.) are now O(1). Thanks David R. MacIver for the report and Bruno Oliveira for the PR. - fix #1223: captured stdout and stderr are now properly displayed before entering pdb when ``--pdb`` is used instead of being thrown away. Thanks Cal Leeming for the PR. - fix #1305: pytest warnings emitted during ``pytest_terminal_summary`` are now properly displayed. Thanks Ionel Maries Cristian for the report and Bruno Oliveira for the PR. - fix #628: fixed internal UnicodeDecodeError when doctests contain unicode. Thanks Jason R. Coombs for the report and Bruno Oliveira for the PR. - fix #1334: Add captured stdout to jUnit XML report on setup error. Thanks Georgy Dyuldin for the PR. Thanks to all who contributed to this release, among them: AMiT Kumar Bruno Oliveira Erik M. Bray Florian Bruhin Georgy Dyuldin Jeff Widman Kartik Singhal Lo?c Est?ve Manu Phatak Peter Demin Rick van Hattem Ronny Pfannschmidt Ulrich Petri foxx Thanks for using pytest, enjoy the new release! Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Fri Jan 22 15:30:12 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Fri, 22 Jan 2016 20:30:12 +0000 Subject: [pytest-dev] pytest docs on readthedocs? Message-ID: Hi everyone, Currently one of the steps involved in the release process is manually generating the documentation and uploading to pytest.org (using rsync). I was wondering if we should move pytest docs over to readthedocs.org? It automatically builds and hosts the documentation based on tags or branches, so it would simplify the release build process a bit, plus it automatically hosts multiple versions of the documentation (would be nice to see how the docs for 2.9 in the features branch look like, for instance). Readthedocs even supports using canonical urls[1] so users would still access the documentation through pytest.org. Also, pytest.readthedocs.org already exists and hosts documentation for the 2.7.0 release. Ronny cleverly noticed that that release probably was the last release before moving to GitHub, otherwise it would be still serving up-to-date documentation as the project on readthedocs is still configured to clone the bitbucket repository. Holger, you are the owner[2] of pytest.readthedocs.org, do you remember if there was a reason to not fully move documentation hosting over there? What others think of this idea? [1] https://docs.readthedocs.org/en/latest/canonical.html [2] https://readthedocs.org/projects/pytest/ Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brianna.laugher at gmail.com Fri Jan 22 16:02:31 2016 From: brianna.laugher at gmail.com (Brianna Laugher) Date: Sat, 23 Jan 2016 08:02:31 +1100 Subject: [pytest-dev] TLS certificate expired Message-ID: Hi, It was pointed out on Twitter that our tls certificate has expired. Cheers Brianna -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at merlinux.eu Fri Jan 22 17:30:06 2016 From: holger at merlinux.eu (Holger Krekel) Date: Fri, 22 Jan 2016 14:30:06 -0800 Subject: [pytest-dev] TLS certificate expired In-Reply-To: References: Message-ID: <180C0F51-CA71-4D65-AE25-926E0A33A779@merlinux.eu> Hi, Not sure I get to this before I take the plane from sfo to Switzerland in a few hours, so the situation will remain for a bit. If someone wants root rights and configure a new ssl cert I can arrange that before I am in the plane. What's the best selection cert solution currently btw? In the past I have used startssl... Cheers holger On January 22, 2016 1:02:31 PM PST, Brianna Laugher wrote: >Hi, > >It was pointed out on Twitter that our tls certificate has expired. > >Cheers >Brianna > > >------------------------------------------------------------------------ > >_______________________________________________ >pytest-dev mailing list >pytest-dev at python.org >https://mail.python.org/mailman/listinfo/pytest-dev -- Sent using mobile touch keys, increased chances for errors and misunderstandings. Enjoy! -------------- next part -------------- An HTML attachment was scrubbed... URL: From florian.schulze at gmx.net Sat Jan 23 03:35:36 2016 From: florian.schulze at gmx.net (Florian Schulze) Date: Sat, 23 Jan 2016 09:35:36 +0100 Subject: [pytest-dev] TLS certificate expired In-Reply-To: <180C0F51-CA71-4D65-AE25-926E0A33A779@merlinux.eu> References: <180C0F51-CA71-4D65-AE25-926E0A33A779@merlinux.eu> Message-ID: <73D0D138-D6C0-4069-9FF4-AF553D4BEED3@gmx.net> I'd say letsencrypt. I wrote a tool to make it easy to create a certificate locally without giving their tool root access: https://pypi.python.org/pypi/letsencrypt-remote Regards, Florian Schulze On 22 Jan 2016, at 23:30, Holger Krekel wrote: > Hi, > Not sure I get to this before I take the plane from sfo to Switzerland > in a few hours, so the situation will remain for a bit. If someone > wants root rights and configure a new ssl cert I can arrange that > before I am in the plane. > > What's the best selection cert solution currently btw? In the past I > have used startssl... > Cheers holger > > On January 22, 2016 1:02:31 PM PST, Brianna Laugher > wrote: >> Hi, >> >> It was pointed out on Twitter that our tls certificate has expired. >> >> Cheers >> Brianna >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> pytest-dev mailing list >> pytest-dev at python.org >> https://mail.python.org/mailman/listinfo/pytest-dev > > -- > Sent using mobile touch keys, increased chances for errors and > misunderstandings. > Enjoy!_______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev From opensource at ronnypfannschmidt.de Sat Jan 23 06:01:35 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Sat, 23 Jan 2016 12:01:35 +0100 Subject: [pytest-dev] how about merging features into master and a 2.9 release? Message-ID: <56A35D8F.6010409@ronnypfannschmidt.de> Hi everyone, i think features made quite some accumulations, and its time for a 2.9 release, i propose to merge features into master after a cooldown period for 2.8.6 (i think 1-2 weeks is fine) afterwards a 2.9 release can be prepared -- Ronny From opensource at ronnypfannschmidt.de Sat Jan 23 06:04:56 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Sat, 23 Jan 2016 12:04:56 +0100 Subject: [pytest-dev] pytest docs on readthedocs? In-Reply-To: References: Message-ID: <56A35E58.9090202@ronnypfannschmidt.de> Hi Bruno, i'm +1 on putting it on that infrastructure in particular the recent unintended infrastructure issues have put some emphasis on solving infrastructure differently, and my understanding is, that readthedocs does not have those issues at a fundamental level Am 22.01.2016 um 21:30 schrieb Bruno Oliveira: > Hi everyone, > > Currently one of the steps involved in the release process is manually > generating the documentation and uploading to pytest.org > (using rsync). > > I was wondering if we should move pytest docs over to readthedocs.org > ? It automatically builds and hosts the > documentation based on tags or branches, so it would simplify the > release build process a bit, plus it automatically hosts multiple > versions of the documentation (would be nice to see how the docs for > 2.9 in the features branch look like, for instance). > > Readthedocs even supports using canonical urls[1] so users would still > access the documentation through pytest.org . > > Also, pytest.readthedocs.org already > exists and hosts documentation for the 2.7.0 release. Ronny cleverly > noticed that that release probably was the last release before moving > to GitHub, otherwise it would be still serving up-to-date > documentation as the project on readthedocs is still configured to > clone the bitbucket repository. > > Holger, you are the owner[2] of pytest.readthedocs.org > , do you remember if there was a reason > to not fully move documentation hosting over there? > > What others think of this idea? > > [1] https://docs.readthedocs.org/en/latest/canonical.html > [2] https://readthedocs.org/projects/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 Sat Jan 23 08:20:42 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Sat, 23 Jan 2016 13:20:42 +0000 Subject: [pytest-dev] how about merging features into master and a 2.9 release? In-Reply-To: <56A35D8F.6010409@ronnypfannschmidt.de> References: <56A35D8F.6010409@ronnypfannschmidt.de> Message-ID: Hi Ronny, Sounds good too me. We've put off 2.9 for some time now. Let's start planning 2.9 two weeks for now then, to see if any critical bug which warrants a 2.8.7 release shows up. As an aside, I would like to see #1199 [1] in 2.9 as it will open up the path to solve a number of bugs dependent on py.code. [1] https://github.com/pytest-dev/pytest/issues/1199 Cheers, Bruno. On Sat, Jan 23, 2016 at 9:01 AM Ronny Pfannschmidt < opensource at ronnypfannschmidt.de> wrote: > Hi everyone, > > i think features made quite some accumulations, > and its time for a 2.9 release, > > i propose to merge features into master > after a cooldown period for 2.8.6 (i think 1-2 weeks is fine) > > afterwards a 2.9 release can be prepared > > -- 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 Sun Jan 24 17:53:30 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Sun, 24 Jan 2016 23:53:30 +0100 Subject: [pytest-dev] Pytest 2.8.7 - a hotfix release Message-ID: <56A555EA.1010000@ronnypfannschmidt.de> pytest-2.8.7 ============ This is a hotfix release to solve a regression in the builtin monkeypatch plugin that got introduced in 2.8.6. pytest is a mature Python testing tool with more than a 1100 tests against itself, passing on many different interpreters and platforms. This release is supposed to be drop-in compatible to 2.8.5. See below for the changes and see docs at: http://pytest.org As usual, you can upgrade from pypi via:: pip install -U pytest Thanks to all who contributed to this release, among them: Ronny Pfannschmidt Happy testing, The py.test Development Team 2.8.7 (compared to 2.8.6) ------------------------- - fix #1338: use predictable object resolution for monkeypatch From opensource at ronnypfannschmidt.de Sun Jan 24 18:32:04 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Mon, 25 Jan 2016 00:32:04 +0100 Subject: [pytest-dev] on abolishing the feature branch concept Message-ID: <56A55EF4.100@ronnypfannschmidt.de> Hi everyone, since it seems we collect more and more changes on the feature branch, that do not get released, i think it is time, to reevaluate if we should keep that workflow as is, from my pov we should focus more on using semver and simply bump versions as needed, and of course deliver more and all changes, instead of accumulating things somewhere without battle-testing. -- Ronny From opensource at ronnypfannschmidt.de Sun Jan 24 18:38:33 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Mon, 25 Jan 2016 00:38:33 +0100 Subject: [pytest-dev] a potential alternative to the py.code merge Message-ID: <56A56079.3070203@ronnypfannschmidt.de> Hi everyone, this is probably a bit late, in particular since Bruno did already spend a considerable amount of time, but instead of merging py.code for the exception repressentation, i would like to propose introducing a abstraction layer, and allowing to set the exception representation in pytest.ini or via plugins this would allow more free experimentation, and also a really clean transition from py.code as default * new possible, to py.code the legacy and new code the default. -- Ronny From opensource at ronnypfannschmidt.de Sun Jan 24 18:46:44 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Mon, 25 Jan 2016 00:46:44 +0100 Subject: [pytest-dev] Configurable collection roots and reusable testsuites - Brainstorming Message-ID: <56A56264.9070208@ronnypfannschmidt.de> Hi everyone, a topic thats gripping since quite a while, is wanting to have reusable testsuites, so plugins/extensions that implement a behaviout, can import and use integration tests from a installed package, and use them in a different configuration another detail that plays into that is certain plugins needing different collections as well an example is the doctest-module, which should scan for doctests in the installed modules that where imported, and not the ones in the working directory. unfortunately its hard to find a good way to express those configured roots for collection, since the ini format on its own is rather limited, and i would like to avoid introducing sub-languagess -- Ronny From nicoddemus at gmail.com Sun Jan 24 19:13:43 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 25 Jan 2016 00:13:43 +0000 Subject: [pytest-dev] on abolishing the feature branch concept In-Reply-To: <56A55EF4.100@ronnypfannschmidt.de> References: <56A55EF4.100@ronnypfannschmidt.de> Message-ID: Hi Ronny, If we abolish the features branch and still honor semantic versioning, it is very likely that every other release will increase the minor version... so we would have pytest 2.20.0 by the end of the year or so. :) I don't really mind it, but others may dislike this. I don't have a preference over this matter, but would like to hear other's opinion on this. Cheers, Bruno. On Sun, Jan 24, 2016 at 9:32 PM Ronny Pfannschmidt < opensource at ronnypfannschmidt.de> wrote: > Hi everyone, > > since it seems we collect more and more changes on the feature branch, > that do not get released, > i think it is time, to reevaluate if we should keep that workflow as is, > > from my pov we should focus more on using semver and simply bump > versions as needed, > and of course deliver more and all changes, instead of accumulating > things somewhere without battle-testing. > > -- 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 nicoddemus at gmail.com Sun Jan 24 19:17:41 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 25 Jan 2016 00:17:41 +0000 Subject: [pytest-dev] a potential alternative to the py.code merge In-Reply-To: <56A56079.3070203@ronnypfannschmidt.de> References: <56A56079.3070203@ronnypfannschmidt.de> Message-ID: Hi Ronny, IIUC, the motivation for the py.code merge is to fix bugs in py.code in a timely manner without depending on py releases, and py.code contains more code than just the exception representation. If that's correct, this having a different code for the exception representation wouldn't prevent us from merging py.code at all. Having said that, I'm not against changing the exception representation at all. :) Cheers, Bruno. On Sun, Jan 24, 2016 at 9:38 PM Ronny Pfannschmidt < opensource at ronnypfannschmidt.de> wrote: > Hi everyone, > > this is probably a bit late, in particular since Bruno did already spend > a considerable amount of time, > > but instead of merging py.code for the exception repressentation, > i would like to propose introducing a abstraction layer, > and allowing to set the exception representation in pytest.ini or via > plugins > > this would allow more free experimentation, and also a really clean > transition from > py.code as default * new possible, to py.code the legacy and new code > the default. > > -- 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 nicoddemus at gmail.com Sun Jan 24 19:22:26 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 25 Jan 2016 00:22:26 +0000 Subject: [pytest-dev] Configurable collection roots and reusable testsuites - Brainstorming In-Reply-To: <56A56264.9070208@ronnypfannschmidt.de> References: <56A56264.9070208@ronnypfannschmidt.de> Message-ID: Hi Ronny, About reusable test suites, what I have done is to put the required tests/checks into fixtures or even classes which are importable across projects and reused there. Could you provide a more specific example of the problem you see? About the collection roots, I also didn't quite get what you mean... I think some examples would also be helpful. :) Cheers, Bruno. On Sun, Jan 24, 2016 at 9:47 PM Ronny Pfannschmidt < opensource at ronnypfannschmidt.de> wrote: > Hi everyone, > > a topic thats gripping since quite a while, is wanting to have reusable > testsuites, > so plugins/extensions that implement a behaviout, > can import and use integration tests from a installed package, > and use them in a different configuration > > another detail that plays into that is certain plugins needing different > collections as well > an example is the doctest-module, which should scan for doctests in the > installed modules > that where imported, and not the ones in the working directory. > > unfortunately its hard to find a good way to express those configured > roots for collection, > since the ini format on its own is rather limited, and i would like to > avoid introducing sub-languagess > > -- 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 me at the-compiler.org Mon Jan 25 00:57:04 2016 From: me at the-compiler.org (Florian Bruhin) Date: Mon, 25 Jan 2016 06:57:04 +0100 Subject: [pytest-dev] Configurable collection roots and reusable testsuites - Brainstorming In-Reply-To: References: <56A56264.9070208@ronnypfannschmidt.de> Message-ID: <20160125055704.GS533@tonks> Hey, * Bruno Oliveira [2016-01-25 00:22:26 +0000]: > About reusable test suites, what I have done is to put the required > tests/checks into fixtures or even classes which are importable across > projects and reused there. Could you provide a more specific example of the > problem you see? > > About the collection roots, I also didn't quite get what you mean... I > think some examples would also be helpful. :) I read Ronny's mail before my first coffee, then again after it. Unfortunately I didn't really understand it either, even after the coffee :P Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From me at the-compiler.org Mon Jan 25 01:03:35 2016 From: me at the-compiler.org (Florian Bruhin) Date: Mon, 25 Jan 2016 07:03:35 +0100 Subject: [pytest-dev] on abolishing the feature branch concept In-Reply-To: References: <56A55EF4.100@ronnypfannschmidt.de> Message-ID: <20160125060335.GT533@tonks> * Bruno Oliveira [2016-01-25 00:13:43 +0000]: > If we abolish the features branch and still honor semantic versioning, it > is very likely that every other release will increase the minor version... > so we would have pytest 2.20.0 by the end of the year or so. :) > > I don't really mind it, but others may dislike this. I agree with this. Also looking at the previous few feature releases, we always needed a few bugfix releases for regressions introduced by them. If we *also* add new features with every (used-to-be) bugfix release, I fear we won't really have a stable battle-tested pytest at all. I think the right route to go is to make releases easier (I think Bruno is doing a great job on that!), and then maybe switch to time-based releases rather than milestone-based releases like gitlab does? https://about.gitlab.com/2015/12/07/why-we-shift-objectives-and-not-release-dates-at-gitlab/ Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From me at the-compiler.org Mon Jan 25 01:08:11 2016 From: me at the-compiler.org (Florian Bruhin) Date: Mon, 25 Jan 2016 07:08:11 +0100 Subject: [pytest-dev] how about merging features into master and a 2.9 release? In-Reply-To: References: <56A35D8F.6010409@ronnypfannschmidt.de> Message-ID: <20160125060811.GU533@tonks> * Bruno Oliveira [2016-01-23 13:20:42 +0000]: > Hi Ronny, > > Sounds good too me. We've put off 2.9 for some time now. > > Let's start planning 2.9 two weeks for now then, to see if any critical bug > which warrants a 2.8.7 release shows up. Make that 2.8.8 I guess? :P But +1 on a 2.9 release. > As an aside, I would like to see #1199 [1] in 2.9 as it will open up the > path to solve a number of bugs dependent on py.code. > > [1] https://github.com/pytest-dev/pytest/issues/1199 I lost track a bit - what's holding this back? Ronny proposed adding deprecation warnings to replace ExceptionInfo objects. It seems to me like this is unrelated to the rest of the py.code move, no? Maybe it should be tackled separately, say for 2.10? Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From me at the-compiler.org Mon Jan 25 01:10:31 2016 From: me at the-compiler.org (Florian Bruhin) Date: Mon, 25 Jan 2016 07:10:31 +0100 Subject: [pytest-dev] pytest docs on readthedocs? In-Reply-To: References: Message-ID: <20160125061031.GV533@tonks> * Bruno Oliveira [2016-01-22 20:30:12 +0000]: > Hi everyone, > > Currently one of the steps involved in the release process is manually > generating the documentation and uploading to pytest.org (using rsync). > > I was wondering if we should move pytest docs over to readthedocs.org? It > automatically builds and hosts the documentation based on tags or branches, > so it would simplify the release build process a bit, plus it automatically > hosts multiple versions of the documentation (would be nice to see how the > docs for 2.9 in the features branch look like, for instance). > > Readthedocs even supports using canonical urls[1] so users would still > access the documentation through pytest.org. +1 on that. While RTD is another external service we'll "depend on", I think it streamlines things a lot. > Also, pytest.readthedocs.org already exists and hosts documentation for the > 2.7.0 release. Ronny cleverly noticed that that release probably was the > last release before moving to GitHub, otherwise it would be still serving > up-to-date documentation as the project on readthedocs is still configured > to clone the bitbucket repository. Yeah, definitely makes sense to update this then. Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From contact at ionelmc.ro Mon Jan 25 03:03:11 2016 From: contact at ionelmc.ro (=?UTF-8?Q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Mon, 25 Jan 2016 10:03:11 +0200 Subject: [pytest-dev] Configurable collection roots and reusable testsuites - Brainstorming In-Reply-To: <20160125055704.GS533@tonks> References: <56A56264.9070208@ronnypfannschmidt.de> <20160125055704.GS533@tonks> Message-ID: I think I'm the evil mastermind behind that idea. It's about collecting from places that cannot be represented as path arguments to `py.test`, like a runtime-defined place (a basic example would be if you want to collect something from site-packages). Thanks, -- Ionel Cristian M?rie?, http://blog.ionelmc.ro On Mon, Jan 25, 2016 at 7:57 AM, Florian Bruhin wrote: > Hey, > > * Bruno Oliveira [2016-01-25 00:22:26 +0000]: > > About reusable test suites, what I have done is to put the required > > tests/checks into fixtures or even classes which are importable across > > projects and reused there. Could you provide a more specific example of > the > > problem you see? > > > > About the collection roots, I also didn't quite get what you mean... I > > think some examples would also be helpful. :) > > I read Ronny's mail before my first coffee, then again after it. > > Unfortunately I didn't really understand it either, even after the > coffee :P > > Florian > > -- > http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) > GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc > I love long mails! | http://email.is-not-s.ms/ > > _______________________________________________ > 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 holger at merlinux.eu Mon Jan 25 05:17:40 2016 From: holger at merlinux.eu (holger krekel) Date: Mon, 25 Jan 2016 10:17:40 +0000 Subject: [pytest-dev] a potential alternative to the py.code merge In-Reply-To: <56A56079.3070203@ronnypfannschmidt.de> References: <56A56079.3070203@ronnypfannschmidt.de> Message-ID: <20160125101740.GD3793@merlinux.eu> Hi Ronny, On Mon, Jan 25, 2016 at 00:38 +0100, Ronny Pfannschmidt wrote: > Hi everyone, > > this is probably a bit late, in particular since Bruno did already spend > a considerable amount of time, > > but instead of merging py.code for the exception repressentation, > i would like to propose introducing a abstraction layer, > and allowing to set the exception representation in pytest.ini or via > plugins > > this would allow more free experimentation, and also a really clean > transition from > py.code as default * new possible, to py.code the legacy and new code > the default. In all the years of pytest/py development no one ever seemed to seriously want to replace the exception representation so i think going full-scale flexible here is premature. Also the move of code from py.code to py.test is kind of orthogonal as Bruno already mentioned. best, holger From holger at merlinux.eu Mon Jan 25 05:22:40 2016 From: holger at merlinux.eu (holger krekel) Date: Mon, 25 Jan 2016 10:22:40 +0000 Subject: [pytest-dev] on abolishing the feature branch concept In-Reply-To: <20160125060335.GT533@tonks> References: <56A55EF4.100@ronnypfannschmidt.de> <20160125060335.GT533@tonks> Message-ID: <20160125102240.GE3793@merlinux.eu> On Mon, Jan 25, 2016 at 07:03 +0100, Florian Bruhin wrote: > * Bruno Oliveira [2016-01-25 00:13:43 +0000]: > > If we abolish the features branch and still honor semantic versioning, it > > is very likely that every other release will increase the minor version... > > so we would have pytest 2.20.0 by the end of the year or so. :) > > > > I don't really mind it, but others may dislike this. > > I agree with this. > > Also looking at the previous few feature releases, we always needed a > few bugfix releases for regressions introduced by them. If we *also* > add new features with every (used-to-be) bugfix release, I fear we > won't really have a stable battle-tested pytest at all. think so as well. > I think the right route to go is to make releases easier (I think > Bruno is doing a great job on that!), and then maybe switch to > time-based releases rather than milestone-based releases like gitlab > does? > > https://about.gitlab.com/2015/12/07/why-we-shift-objectives-and-not-release-dates-at-gitlab/ automating the release process, yay! Not sure about time based releases but we could try to release the features branch more regularly. holger From holger at merlinux.eu Mon Jan 25 05:30:21 2016 From: holger at merlinux.eu (holger krekel) Date: Mon, 25 Jan 2016 10:30:21 +0000 Subject: [pytest-dev] Configurable collection roots and reusable testsuites - Brainstorming In-Reply-To: <56A56264.9070208@ronnypfannschmidt.de> References: <56A56264.9070208@ronnypfannschmidt.de> Message-ID: <20160125103021.GF3793@merlinux.eu> Hi Ronny, Ionel, all, On Mon, Jan 25, 2016 at 00:46 +0100, Ronny Pfannschmidt wrote: > Hi everyone, > > a topic thats gripping since quite a while, is wanting to have reusable > testsuites, > so plugins/extensions that implement a behaviout, > can import and use integration tests from a installed package, > and use them in a different configuration That's already possible to a degree. If you hg-checkout https://bitbucket.org/hpk42/devpi and then look at devpi/server/test_devpi_server/functional.py which is included from devpi/server/test_devpi_server/test_views.py and also from the client side (from the installed devpi-server package): devpi/client/testing/test_functional.py you'll note that the same tests run against different versions of a fixture, i.e. "mapp" which gives high level access to devpi behaviour. ASFAIK this pattern is also used by other projects. I was sometimes thinking that some way to tell pytest more dynamically what to collect, i.e. adding something to the test collection would be nice. You can already do it by hooking into the plugin collection hooks but that's a bit low-level as you need to tie into the collection tree carefully. The hard part of "it would be nice" here is to write down a suggestion in forms of documentation on what API/semantics exactly we want to add and then go for implementing it. best, holger > another detail that plays into that is certain plugins needing different > collections as well > an example is the doctest-module, which should scan for doctests in the > installed modules > that where imported, and not the ones in the working directory. > > unfortunately its hard to find a good way to express those configured > roots for collection, > since the ini format on its own is rather limited, and i would like to > avoid introducing sub-languagess > > -- Ronny > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -- about me: http://holgerkrekel.net/about-me/ contracting: http://merlinux.eu From nicoddemus at gmail.com Mon Jan 25 05:34:07 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 25 Jan 2016 10:34:07 +0000 Subject: [pytest-dev] on abolishing the feature branch concept In-Reply-To: <20160125060335.GT533@tonks> References: <56A55EF4.100@ronnypfannschmidt.de> <20160125060335.GT533@tonks> Message-ID: On Mon, Jan 25, 2016 at 4:03 AM Florian Bruhin wrote: > I think the right route to go is to make releases easier (I think > Bruno is doing a great job on that!), and then maybe switch to > time-based releases rather than milestone-based releases like gitlab > does? > Thanks! :) I read that link, thanks for that. It got me interested in trying that for pytest, seems like a good fit. As you noted, for that to work we would have to automate the process even further... for example, if we move the docs over to readthedocs, that would be one less step that needed to be done. Another point that should be automated is regendoc, which could follow a similar approach to what has been done in my devpi-pytest repository experiment, where we use Travis to run regendoc and open a PR against the pytest repository with the changes. All in all I'm really motivated to automate the release process as much as possible using the existing infrastructure we already have (Travis and AppVeyor). Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at merlinux.eu Mon Jan 25 05:38:34 2016 From: holger at merlinux.eu (holger krekel) Date: Mon, 25 Jan 2016 10:38:34 +0000 Subject: [pytest-dev] pytest docs on readthedocs? In-Reply-To: <20160125061031.GV533@tonks> References: <20160125061031.GV533@tonks> Message-ID: <20160125103834.GG3793@merlinux.eu> Hi Bruno, all, could you give me your handles on readthedocs so i can add you as maintainers to pytest.readthedocs.org? If we can maintain the current URL layout of pytest.org and have it served from rtfd i'd be fine with going for it. There are many references across the web into pytest.org URLs so i wouldn't want to just change the hosting to play around and break them. Maybe we could replace pytest.org with a different not so version dependent start page and have doc.pytest.org be the new home? We could then make old pytest.org URLs redirect while the web and google get used to the new doc.pytest.org site served from RTD. holger On Mon, Jan 25, 2016 at 07:10 +0100, Florian Bruhin wrote: > * Bruno Oliveira [2016-01-22 20:30:12 +0000]: > > Hi everyone, > > > > Currently one of the steps involved in the release process is manually > > generating the documentation and uploading to pytest.org (using rsync). > > > > I was wondering if we should move pytest docs over to readthedocs.org? It > > automatically builds and hosts the documentation based on tags or branches, > > so it would simplify the release build process a bit, plus it automatically > > hosts multiple versions of the documentation (would be nice to see how the > > docs for 2.9 in the features branch look like, for instance). > > > > Readthedocs even supports using canonical urls[1] so users would still > > access the documentation through pytest.org. > > +1 on that. While RTD is another external service we'll "depend on", I > think it streamlines things a lot. > > > Also, pytest.readthedocs.org already exists and hosts documentation for the > > 2.7.0 release. Ronny cleverly noticed that that release probably was the > > last release before moving to GitHub, otherwise it would be still serving > > up-to-date documentation as the project on readthedocs is still configured > > to clone the bitbucket repository. > > Yeah, definitely makes sense to update this then. > > Florian > > -- > http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) > GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc > I love long mails! | http://email.is-not-s.ms/ > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev -- about me: http://holgerkrekel.net/about-me/ contracting: http://merlinux.eu From nicoddemus at gmail.com Mon Jan 25 05:47:38 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 25 Jan 2016 10:47:38 +0000 Subject: [pytest-dev] pytest docs on readthedocs? In-Reply-To: <20160125103834.GG3793@merlinux.eu> References: <20160125061031.GV533@tonks> <20160125103834.GG3793@merlinux.eu> Message-ID: On Mon, Jan 25, 2016 at 8:38 AM holger krekel wrote: > Hi Bruno, all, > > could you give me your handles on readthedocs so i can add you as > maintainers > to pytest.readthedocs.org? > Mine is nicoddemus. > > If we can maintain the current URL layout of pytest.org and have it served > from rtfd i'd be fine with going for it. There are many references > across the web into pytest.org URLs so i wouldn't want to just change > the hosting to play around and break them. > > > Maybe we could replace pytest.org with a different not so version > dependent start page and have doc.pytest.org be the new home? > We could then make old pytest.org URLs redirect while the web > and google get used to the new doc.pytest.org site served from > RTD. > I think the latter is certainly possible, since that's what fabric does: http://www.fabfile.org/ http://docs.fabfile.org/en/1.10/ Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at ronnypfannschmidt.de Mon Jan 25 06:06:42 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Mon, 25 Jan 2016 12:06:42 +0100 Subject: [pytest-dev] on abolishing the feature branch concept In-Reply-To: References: <56A55EF4.100@ronnypfannschmidt.de> <20160125060335.GT533@tonks> Message-ID: <56A601C2.1010302@ronnypfannschmidt.de> I agree on the link article as well and like the model, i propose a time-frame of either 3 or 4 months for the feature releases. My personal preference is 3 months. I already started with trying to automate regendoc, my first attempt can be classified as failure. I'd like to discuss a new approach at a later point in time. the idea is to have a deploy handler, which will "deploy" a pull request to maser/feature whenever it notices differences after a regen run. -- Ronny Am 25.01.2016 um 11:34 schrieb Bruno Oliveira: > On Mon, Jan 25, 2016 at 4:03 AM Florian Bruhin > wrote: > > I think the right route to go is to make releases easier (I think > Bruno is doing a great job on that!), and then maybe switch to > time-based releases rather than milestone-based releases like gitlab > does? > > > Thanks! :) > > I read that link, thanks for that. It got me interested in trying that > for pytest, seems like a good fit. As you noted, for that to work we > would have to automate the process even further... for example, if we > move the docs over to readthedocs, that would be one less step that > needed to be done. Another point that should be automated is regendoc, > which could follow a similar approach to what has been done in my > devpi-pytest repository experiment, where we use Travis to run > regendoc and open a PR against the pytest repository with the changes. > > All in all I'm really motivated to automate the release process as > much as possible using the existing infrastructure we already have > (Travis and AppVeyor). > > Cheers, > Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Mon Jan 25 06:43:27 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 25 Jan 2016 11:43:27 +0000 Subject: [pytest-dev] on abolishing the feature branch concept In-Reply-To: <56A601C2.1010302@ronnypfannschmidt.de> References: <56A55EF4.100@ronnypfannschmidt.de> <20160125060335.GT533@tonks> <56A601C2.1010302@ronnypfannschmidt.de> Message-ID: On Mon, Jan 25, 2016 at 9:06 AM Ronny Pfannschmidt < opensource at ronnypfannschmidt.de> wrote: > I agree on the link article as well and like the model, > i propose a time-frame of either 3 or 4 months for the feature releases. > > My personal preference is 3 months. > I think that sounds good for the feature releases. For bug fix releases I think a shorter time frame makes more sense, how about every 2 weeks? We could prepare the release PR Thursday and release on Friday. To organize who does the release, we could create a list of volunteers and just cycle into that list every two weeks... if someone won't be able to make a release on their turn due to personal reasons, he/she can ask in the list for someone else to step in. > I'd like to discuss a new approach at a later point in time. > the idea is to have a deploy handler, which will "deploy" a pull request > to maser/feature > whenever it notices differences after a regen run. > Sure, count me in for this discussion. I was thinking of having a manual trigger, where one would make changes to a "regendoc-pytest" repository (like in my devpi-pytest experiment) and push it. This would trigger a regendoc run and PR, which could then be merged as usual. Running this job would then be part of the release process. It is still does require manual intervention, but is less error prone and does not require the person to have everything configured in their local workstation. Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Mon Jan 25 06:49:28 2016 From: me at the-compiler.org (Florian Bruhin) Date: Mon, 25 Jan 2016 12:49:28 +0100 Subject: [pytest-dev] on abolishing the feature branch concept In-Reply-To: References: <56A55EF4.100@ronnypfannschmidt.de> <20160125060335.GT533@tonks> <56A601C2.1010302@ronnypfannschmidt.de> Message-ID: <20160125114928.GA31996@tonks> * Bruno Oliveira [2016-01-25 11:43:27 +0000]: > On Mon, Jan 25, 2016 at 9:06 AM Ronny Pfannschmidt < > opensource at ronnypfannschmidt.de> wrote: > > > I agree on the link article as well and like the model, > > i propose a time-frame of either 3 or 4 months for the feature releases. > > > > My personal preference is 3 months. > > > > I think that sounds good for the feature releases. For bug fix releases I > think a shorter time frame makes more sense, how about every 2 weeks? We > could prepare the release PR Thursday and release on Friday. I don't think it makes sense to do time-based *bugfix* releases. GitLab does those as appropriate (i.e. whenever important enough fixes pile up), and I think it makes more sense to keep the flexibility there. > > I'd like to discuss a new approach at a later point in time. > > the idea is to have a deploy handler, which will "deploy" a pull request > > to maser/feature > > whenever it notices differences after a regen run. > > > > Sure, count me in for this discussion. > > I was thinking of having a manual trigger, where one would make changes to > a "regendoc-pytest" repository (like in my devpi-pytest experiment) and > push it. This would trigger a regendoc run and PR, which could then be > merged as usual. Running this job would then be part of the release > process. It is still does require manual intervention, but is less error > prone and does not require the person to have everything configured in > their local workstation. I think that's what ronny proposed too, no? Doing a regendoc PR from Travis sounds like a good idea IMHO. First maybe it should be more deterministic though, i.e. produce no changes if there was nothing changing the output. Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From opensource at ronnypfannschmidt.de Mon Jan 25 07:00:12 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Mon, 25 Jan 2016 13:00:12 +0100 Subject: [pytest-dev] on abolishing the feature branch concept In-Reply-To: <20160125114928.GA31996@tonks> References: <56A55EF4.100@ronnypfannschmidt.de> <20160125060335.GT533@tonks> <56A601C2.1010302@ronnypfannschmidt.de> <20160125114928.GA31996@tonks> Message-ID: <56A60E4C.2070202@ronnypfannschmidt.de> For bugfix releases i would like to do them as soon as possible (i.e. try to stay within one day of the merge) that would also create more incentives for an better automation -- Ronny Am 25.01.2016 um 12:49 schrieb Florian Bruhin: > * Bruno Oliveira [2016-01-25 11:43:27 +0000]: >> On Mon, Jan 25, 2016 at 9:06 AM Ronny Pfannschmidt < >> opensource at ronnypfannschmidt.de> wrote: >> >>> I agree on the link article as well and like the model, >>> i propose a time-frame of either 3 or 4 months for the feature releases. >>> >>> My personal preference is 3 months. >>> >> I think that sounds good for the feature releases. For bug fix releases I >> think a shorter time frame makes more sense, how about every 2 weeks? We >> could prepare the release PR Thursday and release on Friday. > I don't think it makes sense to do time-based *bugfix* releases. > GitLab does those as appropriate (i.e. whenever important enough fixes > pile up), and I think it makes more sense to keep the flexibility > there. > >>> I'd like to discuss a new approach at a later point in time. >>> the idea is to have a deploy handler, which will "deploy" a pull request >>> to maser/feature >>> whenever it notices differences after a regen run. >>> >> Sure, count me in for this discussion. >> >> I was thinking of having a manual trigger, where one would make changes to >> a "regendoc-pytest" repository (like in my devpi-pytest experiment) and >> push it. This would trigger a regendoc run and PR, which could then be >> merged as usual. Running this job would then be part of the release >> process. It is still does require manual intervention, but is less error >> prone and does not require the person to have everything configured in >> their local workstation. > I think that's what ronny proposed too, no? > > Doing a regendoc PR from Travis sounds like a good idea IMHO. First > maybe it should be more deterministic though, i.e. produce no changes > if there was nothing changing the output. > > Florian > From holger at merlinux.eu Mon Jan 25 07:03:05 2016 From: holger at merlinux.eu (holger krekel) Date: Mon, 25 Jan 2016 12:03:05 +0000 Subject: [pytest-dev] TLS certificate expired In-Reply-To: References: Message-ID: <20160125120305.GJ3793@merlinux.eu> Hi all, i just setup letsencrypt for pytest.org and also auto-renewal per cron. Seems to work fine. Thanks everyone. best, holger On Sat, Jan 23, 2016 at 08:02 +1100, Brianna Laugher wrote: > Hi, > > It was pointed out on Twitter that our tls certificate has expired. > > Cheers > Brianna > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev -- about me: http://holgerkrekel.net/about-me/ contracting: http://merlinux.eu From nicoddemus at gmail.com Mon Jan 25 07:03:06 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 25 Jan 2016 12:03:06 +0000 Subject: [pytest-dev] on abolishing the feature branch concept In-Reply-To: <56A60E4C.2070202@ronnypfannschmidt.de> References: <56A55EF4.100@ronnypfannschmidt.de> <20160125060335.GT533@tonks> <56A601C2.1010302@ronnypfannschmidt.de> <20160125114928.GA31996@tonks> <56A60E4C.2070202@ronnypfannschmidt.de> Message-ID: On Mon, Jan 25, 2016 at 10:00 AM Ronny Pfannschmidt < opensource at ronnypfannschmidt.de> wrote: > For bugfix releases i would like to do them as soon as possible > (i.e. try to stay within one day of the merge) > Hmmm what do you mean Ronny? A release after each bug fix is merged in? that would also create more incentives for an better automation > I agree, that certainly would be a benefit. Thanks, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Mon Jan 25 07:07:16 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 25 Jan 2016 12:07:16 +0000 Subject: [pytest-dev] on abolishing the feature branch concept In-Reply-To: <20160125114928.GA31996@tonks> References: <56A55EF4.100@ronnypfannschmidt.de> <20160125060335.GT533@tonks> <56A601C2.1010302@ronnypfannschmidt.de> <20160125114928.GA31996@tonks> Message-ID: On Mon, Jan 25, 2016 at 9:49 AM Florian Bruhin wrote: > * Bruno Oliveira [2016-01-25 11:43:27 +0000]: > > I think that sounds good for the feature releases. For bug fix releases I > > think a shorter time frame makes more sense, how about every 2 weeks? We > > could prepare the release PR Thursday and release on Friday. > > I don't think it makes sense to do time-based *bugfix* releases. > GitLab does those as appropriate (i.e. whenever important enough fixes > pile up), and I think it makes more sense to keep the flexibility > there. > One benefit I see is that we would have a an answer for the common question "when will be the next bug fix release", which we always respond "as soon as we have some other get bugs fixed"... having a schedule for that also would allow people to prepare and plan themselves. > > > I'd like to discuss a new approach at a later point in time. > > > the idea is to have a deploy handler, which will "deploy" a pull > request > > > to maser/feature > > > whenever it notices differences after a regen run. > > > > > > > Sure, count me in for this discussion. > > > > I was thinking of having a manual trigger, where one would make changes > to > > a "regendoc-pytest" repository (like in my devpi-pytest experiment) and > > push it. This would trigger a regendoc run and PR, which could then be > > merged as usual. Running this job would then be part of the release > > process. It is still does require manual intervention, but is less error > > prone and does not require the person to have everything configured in > > their local workstation. > > I think that's what ronny proposed too, no? > I understood that Ronny's plan was to make regendoc run for every PR. I'm just commenting on what I had in mind to enrich the discussion with an alternate point of view. :) Doing a regendoc PR from Travis sounds like a good idea IMHO. First > maybe it should be more deterministic though, i.e. produce no changes > if there was nothing changing the output. > Certainly, I agree! Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at merlinux.eu Mon Jan 25 07:10:34 2016 From: holger at merlinux.eu (holger krekel) Date: Mon, 25 Jan 2016 12:10:34 +0000 Subject: [pytest-dev] on abolishing the feature branch concept In-Reply-To: References: <56A55EF4.100@ronnypfannschmidt.de> <20160125060335.GT533@tonks> <56A601C2.1010302@ronnypfannschmidt.de> <20160125114928.GA31996@tonks> <56A60E4C.2070202@ronnypfannschmidt.de> Message-ID: <20160125121034.GK3793@merlinux.eu> On Mon, Jan 25, 2016 at 12:03 +0000, Bruno Oliveira wrote: > On Mon, Jan 25, 2016 at 10:00 AM Ronny Pfannschmidt < > opensource at ronnypfannschmidt.de> wrote: > > > For bugfix releases i would like to do them as soon as possible > > (i.e. try to stay within one day of the merge) > > > > Hmmm what do you mean Ronny? A release after each bug fix is merged in? > > that would also create more incentives for an better automation > > > > I agree, that certainly would be a benefit. If we directly release after bugfix merges there is not much chance humans will use it and discover problems. I'd really like bugfix releases to be stable series and i consider that more important than quick releases. So unless we have more thorough testing not only of pytest itself but of the 10-20 most popular plugins and maybe a few example projects let's not increase the pace to "release after bugfix merge". btw, how many people have said that pytest is too slow on releases? In fact i know that several companies are holding back on upgrading, some using much older versions. For them, upgrading is not automatic but a more tedious process involving communication across teams etc. That doesn't mean we need to slow down but just that there are various perceptions on release schedules. holger > Thanks, > Bruno. > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev -- about me: http://holgerkrekel.net/about-me/ contracting: http://merlinux.eu From opensource at ronnypfannschmidt.de Mon Jan 25 08:23:27 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Mon, 25 Jan 2016 14:23:27 +0100 Subject: [pytest-dev] Configurable collection roots and reusable testsuites - Brainstorming In-Reply-To: <20160125103021.GF3793@merlinux.eu> References: <56A56264.9070208@ronnypfannschmidt.de> <20160125103021.GF3793@merlinux.eu> Message-ID: <56A621CF.9060505@ronnypfannschmidt.de> Im aware of that rudimentary mechanism, i would like to elevate a "testsuite" to a set of collected tests in filled with "dependencies" via fixtures that approach would also provide a more clean mechanism that are currently handled with session scoped fixtures that are parametrized one of such examples would be backends for common operations i think its clear that a more detailed approach is needed, a more detailed discussion about the model might be a good idea for a sprint -- Ronny Am 25.01.2016 um 11:30 schrieb holger krekel: > Hi Ronny, Ionel, all, > > On Mon, Jan 25, 2016 at 00:46 +0100, Ronny Pfannschmidt wrote: >> Hi everyone, >> >> a topic thats gripping since quite a while, is wanting to have reusable >> testsuites, >> so plugins/extensions that implement a behaviout, >> can import and use integration tests from a installed package, >> and use them in a different configuration > That's already possible to a degree. > > If you hg-checkout https://bitbucket.org/hpk42/devpi and then look at > > devpi/server/test_devpi_server/functional.py > > which is included from > > devpi/server/test_devpi_server/test_views.py > > and also from the client side (from the installed devpi-server package): > > devpi/client/testing/test_functional.py > > you'll note that the same tests run against different versions of a > fixture, i.e. "mapp" which gives high level access to devpi behaviour. > ASFAIK this pattern is also used by other projects. > > I was sometimes thinking that some way to tell pytest more dynamically > what to collect, i.e. adding something to the test collection would > be nice. You can already do it by hooking into the plugin collection > hooks but that's a bit low-level as you need to tie into the collection > tree carefully. The hard part of "it would be nice" here is to write > down a suggestion in forms of documentation on what API/semantics exactly > we want to add and then go for implementing it. > > best, > holger > > >> another detail that plays into that is certain plugins needing different >> collections as well >> an example is the doctest-module, which should scan for doctests in the >> installed modules >> that where imported, and not the ones in the working directory. >> >> unfortunately its hard to find a good way to express those configured >> roots for collection, >> since the ini format on its own is rather limited, and i would like to >> avoid introducing sub-languagess >> >> -- Ronny >> _______________________________________________ >> pytest-dev mailing list >> pytest-dev at python.org >> https://mail.python.org/mailman/listinfo/pytest-dev >> From opensource at ronnypfannschmidt.de Mon Jan 25 08:36:12 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Mon, 25 Jan 2016 14:36:12 +0100 Subject: [pytest-dev] on abolishing the feature branch concept In-Reply-To: <20160125121034.GK3793@merlinux.eu> References: <56A55EF4.100@ronnypfannschmidt.de> <20160125060335.GT533@tonks> <56A601C2.1010302@ronnypfannschmidt.de> <20160125114928.GA31996@tonks> <56A60E4C.2070202@ronnypfannschmidt.de> <20160125121034.GK3793@merlinux.eu> Message-ID: <56A624CC.8020708@ronnypfannschmidt.de> i think we need to be much more strict on what a bugfix is for example the regression in 2.8.6 was caused by the "feature" of more detailed exceptions from monkeypatch if we go to a __strict__ handling of bugfixes, then much more of what had gone to the 2.8.6 release would have landed in the features branch another more and more apparent issue is, that our current testsuite and style of testing in pytest can't provide sufficient branch coverage in various situations, the regression that happened in 2.8.6 should have been something the testsuite catches before. to that effect it might even be sensible to change from master + features to bugfix + master -- Ronny Am 25.01.2016 um 13:10 schrieb holger krekel: > On Mon, Jan 25, 2016 at 12:03 +0000, Bruno Oliveira wrote: >> On Mon, Jan 25, 2016 at 10:00 AM Ronny Pfannschmidt < >> opensource at ronnypfannschmidt.de> wrote: >> >>> For bugfix releases i would like to do them as soon as possible >>> (i.e. try to stay within one day of the merge) >>> >> Hmmm what do you mean Ronny? A release after each bug fix is merged in? >> >> that would also create more incentives for an better automation >> I agree, that certainly would be a benefit. > If we directly release after bugfix merges there is not much chance > humans will use it and discover problems. I'd really like bugfix > releases to be stable series and i consider that more important than > quick releases. So unless we have more thorough testing > not only of pytest itself but of the 10-20 most popular plugins > and maybe a few example projects let's not increase the pace to > "release after bugfix merge". > > btw, how many people have said that pytest is too slow on releases? > > In fact i know that several companies are holding back on upgrading, > some using much older versions. For them, upgrading is not automatic > but a more tedious process involving communication across teams etc. > That doesn't mean we need to slow down but just that there are various > perceptions on release schedules. > > holger > > > >> Thanks, >> Bruno. >> _______________________________________________ >> pytest-dev mailing list >> pytest-dev at python.org >> https://mail.python.org/mailman/listinfo/pytest-dev > From me at the-compiler.org Mon Jan 25 09:04:10 2016 From: me at the-compiler.org (Florian Bruhin) Date: Mon, 25 Jan 2016 15:04:10 +0100 Subject: [pytest-dev] on abolishing the feature branch concept In-Reply-To: <56A624CC.8020708@ronnypfannschmidt.de> References: <20160125060335.GT533@tonks> <56A601C2.1010302@ronnypfannschmidt.de> <20160125114928.GA31996@tonks> <56A60E4C.2070202@ronnypfannschmidt.de> <20160125121034.GK3793@merlinux.eu> <56A624CC.8020708@ronnypfannschmidt.de> Message-ID: <20160125140410.GE31996@tonks> * Ronny Pfannschmidt [2016-01-25 14:36:12 +0100]: > i think we need to be much more strict on what a bugfix is > for example the regression in 2.8.6 was caused by the "feature" > of more detailed exceptions from monkeypatch I agree this particular PR should've gone to 'features'. IMHO it'd have been the responsibility of Bruno and you to tell the author to reopen it against features. But in general I think it's working pretty well, no? > if we go to a __strict__ handling of bugfixes, > then much more of what had gone to the 2.8.6 release would have landed > in the features branch I reviewed the commits because I was curious about this. Other than the change above and another change which is debatable ("Make monkeypatch calls O(1)") all of those seem like bugfixes or trivial doc changes to me. > another more and more apparent issue is, that our current testsuite > and style of testing in pytest can't provide sufficient branch > coverage in various situations, the regression that happened in > 2.8.6 should have been something the testsuite catches before. I was surprised this wasn't caught as well - then again pytest's coverage is at 93% according to coveralls, which doesn't seem too shabby to me. > to that effect it might even be sensible to change from master + > features to bugfix + master I thought we discussed this to death before already, and ended up with master/features :P Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From flub at devork.be Mon Jan 25 09:18:01 2016 From: flub at devork.be (Floris Bruynooghe) Date: Mon, 25 Jan 2016 14:18:01 +0000 Subject: [pytest-dev] pytest docs on readthedocs? In-Reply-To: References: <20160125061031.GV533@tonks> <20160125103834.GG3793@merlinux.eu> Message-ID: On 25 January 2016 at 10:47, Bruno Oliveira wrote: > > > On Mon, Jan 25, 2016 at 8:38 AM holger krekel wrote: >> >> Hi Bruno, all, >> >> could you give me your handles on readthedocs so i can add you as >> maintainers >> to pytest.readthedocs.org? > > > Mine is nicoddemus. Mine is flub > >> >> >> If we can maintain the current URL layout of pytest.org and have it served >> from rtfd i'd be fine with going for it. There are many references >> across the web into pytest.org URLs so i wouldn't want to just change >> the hosting to play around and break them. > > >> >> >> Maybe we could replace pytest.org with a different not so version >> dependent start page and have doc.pytest.org be the new home? >> We could then make old pytest.org URLs redirect while the web >> and google get used to the new doc.pytest.org site served from >> RTD. > > > I think the latter is certainly possible, since that's what fabric does: > > http://www.fabfile.org/ > http://docs.fabfile.org/en/1.10/ +1 to this layout From nicoddemus at gmail.com Mon Jan 25 09:31:45 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 25 Jan 2016 14:31:45 +0000 Subject: [pytest-dev] on abolishing the feature branch concept In-Reply-To: <20160125140410.GE31996@tonks> References: <20160125060335.GT533@tonks> <56A601C2.1010302@ronnypfannschmidt.de> <20160125114928.GA31996@tonks> <56A60E4C.2070202@ronnypfannschmidt.de> <20160125121034.GK3793@merlinux.eu> <56A624CC.8020708@ronnypfannschmidt.de> <20160125140410.GE31996@tonks> Message-ID: On Mon, Jan 25, 2016 at 12:04 PM Florian Bruhin wrote: > * Ronny Pfannschmidt [2016-01-25 > 14:36:12 +0100]: > > i think we need to be much more strict on what a bugfix is > > for example the regression in 2.8.6 was caused by the "feature" > > of more detailed exceptions from monkeypatch > > I agree this particular PR should've gone to 'features'. IMHO it'd > have been the responsibility of Bruno and you to tell the author to > reopen it against features. > Yes, it seemed like a small fix at the time, that's why it went into master... I agree we should be more strict on what goes to master in the future. But in general I think it's working pretty well, no? > I agree... we just have to adjust to those hiccups. > another more and more apparent issue is, that our current testsuite > > and style of testing in pytest can't provide sufficient branch > > coverage in various situations, the regression that happened in > > 2.8.6 should have been something the testsuite catches before. > > I was surprised this wasn't caught as well - then again pytest's > coverage is at 93% according to coveralls, which doesn't seem too > shabby to me. > I think much of what is missing is because of poor coverage in genscript.py... didn't take a deeper look if it is possible to improve that. > to that effect it might even be sensible to change from master + > > features to bugfix + master > > I thought we discussed this to death before already, and ended up with > master/features :P > I agree, I don't think the reasons for the master/feature division have changed: mainly that most external contributions are bug fixes or doc-changes, so it's natural for contributors to target the master branch. Features are much more rare, so for those we have a different branch other than the default. Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Mon Jan 25 09:39:39 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 25 Jan 2016 14:39:39 +0000 Subject: [pytest-dev] pytest docs on readthedocs? In-Reply-To: References: <20160125061031.GV533@tonks> <20160125103834.GG3793@merlinux.eu> Message-ID: On Mon, Jan 25, 2016 at 12:18 PM Floris Bruynooghe wrote: > > I think the latter is certainly possible, since that's what fabric does: > > > > http://www.fabfile.org/ > > http://docs.fabfile.org/en/1.10/ > > +1 to this layout > I will study how to use this later Today. On a related note: I changed the default URL (http://pytest.readthedocs.org) to point to 2.8.7, and enabled building of the "features" branch so it can now be accessed from: http://pytest.readthedocs.org/en/features/ Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at ronnypfannschmidt.de Mon Jan 25 09:42:16 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Mon, 25 Jan 2016 15:42:16 +0100 Subject: [pytest-dev] on abolishing the feature branch concept In-Reply-To: <20160125140410.GE31996@tonks> References: <20160125060335.GT533@tonks> <56A601C2.1010302@ronnypfannschmidt.de> <20160125114928.GA31996@tonks> <56A60E4C.2070202@ronnypfannschmidt.de> <20160125121034.GK3793@merlinux.eu> <56A624CC.8020708@ronnypfannschmidt.de> <20160125140410.GE31996@tonks> Message-ID: <56A63448.8010600@ronnypfannschmidt.de> Am 25.01.2016 um 15:04 schrieb Florian Bruhin: > * Ronny Pfannschmidt [2016-01-25 14:36:12 +0100]: >> i think we need to be much more strict on what a bugfix is >> for example the regression in 2.8.6 was caused by the "feature" >> of more detailed exceptions from monkeypatch > I agree this particular PR should've gone to 'features'. IMHO it'd > have been the responsibility of Bruno and you to tell the author to > reopen it against features. > > But in general I think it's working pretty well, no? > in general its working well, but i also recall we had similar issues with incremental changes in other releases as well, i don't yet have hard data collected, but i believe we have a pattern there of followup bugs happening too often, and i'd like to see a process to reduce those >> if we go to a __strict__ handling of bugfixes, >> then much more of what had gone to the 2.8.6 release would have landed >> in the features branch > I reviewed the commits because I was curious about this. > Other than the change above and another change which is debatable > ("Make monkeypatch calls O(1)") all of those seem like bugfixes or > trivial doc changes to me. indeed, we have a lot of trivial looking changes, the one that caused the regression in 2.8.6 also looked relatively simple. Which is why i was making the point on more strictness wrt bugfix vs feature :) my impression is, that in the past few months we got a bit too accepting of little "features" in the bugfixing branch >> another more and more apparent issue is, that our current testsuite >> and style of testing in pytest can't provide sufficient branch >> coverage in various situations, the regression that happened in >> 2.8.6 should have been something the testsuite catches before. > I was surprised this wasn't caught as well - then again pytest's > coverage is at 93% according to coveralls, which doesn't seem too > shabby to me. unfortunately code coverage an entirely useless indicator, whats needed is state and branch coverage which is impossible to do with acceptance tests >> to that effect it might even be sensible to change from master + >> features to bugfix + master > I thought we discussed this to death before already, and ended up with > master/features :P i'm aware, i'm bringing it up, because of the little details i noticed over the last few months it's much less problematic to have to backport/cherrypick a bugfix than accidentally slipping in a feature change to a bugfix release im also fine with keeping the branch names as is, the important part is better discipline on our side :) > > Florian > -- Ronny From nicoddemus at gmail.com Mon Jan 25 09:57:40 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 25 Jan 2016 14:57:40 +0000 Subject: [pytest-dev] on abolishing the feature branch concept In-Reply-To: <56A63448.8010600@ronnypfannschmidt.de> References: <20160125060335.GT533@tonks> <56A601C2.1010302@ronnypfannschmidt.de> <20160125114928.GA31996@tonks> <56A60E4C.2070202@ronnypfannschmidt.de> <20160125121034.GK3793@merlinux.eu> <56A624CC.8020708@ronnypfannschmidt.de> <20160125140410.GE31996@tonks> <56A63448.8010600@ronnypfannschmidt.de> Message-ID: On Mon, Jan 25, 2016 at 12:42 PM Ronny Pfannschmidt < opensource at ronnypfannschmidt.de> wrote: > Am 25.01.2016 um 15:04 schrieb Florian Bruhin: > > * Ronny Pfannschmidt [2016-01-25 > 14:36:12 +0100]: > >> to that effect it might even be sensible to change from master + > >> features to bugfix + master > > I thought we discussed this to death before already, and ended up with > > master/features :P > i'm aware, i'm bringing it up, because of the little details i noticed > over the last few months > it's much less problematic to have to backport/cherrypick a bugfix than > accidentally slipping in a feature change to a bugfix release > > im also fine with keeping the branch names as is, > the important part is better discipline on our side :) > IMHO we should keep the naming as it is, and follow your suggestion of being more strict to what goes into master: strictly bug fixes, any change in behavior even if small should go into features. And I agree we should release the features branch more often, following your suggestion of every 3 months or so seems reasonable. Cheers, Bruno. > > > > Florian > > > -- Ronny > -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at ronnypfannschmidt.de Mon Jan 25 09:59:22 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Mon, 25 Jan 2016 15:59:22 +0100 Subject: [pytest-dev] a potential alternative to the py.code merge In-Reply-To: <20160125101740.GD3793@merlinux.eu> References: <56A56079.3070203@ronnypfannschmidt.de> <20160125101740.GD3793@merlinux.eu> Message-ID: <56A6384A.3060100@ronnypfannschmidt.de> i have ideas for replacing/changing it in the back of my head since a while now, so i'd like to have a reasonable/easy testbed also we could avoid the need for api compatibility even if we copy in py.code given that the old api would be available also exception representation is a very low-ganging fruit in various ways, in particular since it kinda works but i think before 3.0 its a very good point in time to reconsider after all for xdist we need a serializable variant, and i think the current api does way too much the harsher we can trim down in future, the better -- Ronny Am 25.01.2016 um 11:17 schrieb holger krekel: > Hi Ronny, > > On Mon, Jan 25, 2016 at 00:38 +0100, Ronny Pfannschmidt wrote: >> Hi everyone, >> >> this is probably a bit late, in particular since Bruno did already spend >> a considerable amount of time, >> >> but instead of merging py.code for the exception repressentation, >> i would like to propose introducing a abstraction layer, >> and allowing to set the exception representation in pytest.ini or via >> plugins >> >> this would allow more free experimentation, and also a really clean >> transition from >> py.code as default * new possible, to py.code the legacy and new code >> the default. > In all the years of pytest/py development no one ever seemed to seriously > want to replace the exception representation so i think going full-scale > flexible here is premature. Also the move of code from py.code to > py.test is kind of orthogonal as Bruno already mentioned. > > best, > holger From holger at merlinux.eu Mon Jan 25 10:06:42 2016 From: holger at merlinux.eu (holger krekel) Date: Mon, 25 Jan 2016 15:06:42 +0000 Subject: [pytest-dev] pytest docs on readthedocs? In-Reply-To: References: <20160125061031.GV533@tonks> <20160125103834.GG3793@merlinux.eu> Message-ID: <20160125150642.GN3793@merlinux.eu> On Mon, Jan 25, 2016 at 14:18 +0000, Floris Bruynooghe wrote: > On 25 January 2016 at 10:47, Bruno Oliveira wrote: > > > > > > On Mon, Jan 25, 2016 at 8:38 AM holger krekel wrote: > >> > >> Hi Bruno, all, > >> > >> could you give me your handles on readthedocs so i can add you as > >> maintainers > >> to pytest.readthedocs.org? > > > > > > Mine is nicoddemus. > > Mine is flub i added both to pytest.readthedocs.org -- anyone else? send me a priv mail. holger > > > >> > >> > >> If we can maintain the current URL layout of pytest.org and have it served > >> from rtfd i'd be fine with going for it. There are many references > >> across the web into pytest.org URLs so i wouldn't want to just change > >> the hosting to play around and break them. > > > > > >> > >> > >> Maybe we could replace pytest.org with a different not so version > >> dependent start page and have doc.pytest.org be the new home? > >> We could then make old pytest.org URLs redirect while the web > >> and google get used to the new doc.pytest.org site served from > >> RTD. > > > > > > I think the latter is certainly possible, since that's what fabric does: > > > > http://www.fabfile.org/ > > http://docs.fabfile.org/en/1.10/ > > +1 to this layout > -- about me: http://holgerkrekel.net/about-me/ contracting: http://merlinux.eu From nicoddemus at gmail.com Mon Jan 25 10:41:48 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 25 Jan 2016 15:41:48 +0000 Subject: [pytest-dev] a potential alternative to the py.code merge In-Reply-To: <56A6384A.3060100@ronnypfannschmidt.de> References: <56A56079.3070203@ronnypfannschmidt.de> <20160125101740.GD3793@merlinux.eu> <56A6384A.3060100@ronnypfannschmidt.de> Message-ID: On Mon, Jan 25, 2016 at 12:59 PM Ronny Pfannschmidt < opensource at ronnypfannschmidt.de> wrote: > i have ideas for replacing/changing it in the back of my head since a > while now, > so i'd like to have a reasonable/easy testbed > > also we could avoid the need for api compatibility even if we copy in > py.code > given that the old api would be available > Just to be clear, what are you proposing? 1. Hold off merging py.code, implementing on top of that branch an alternative exception representation? 2. Merge py.code and work on an alternative exception representation? To be honest I would prefer 2, as this would stop blocking issues which are waiting for py.code to be merged into pytest. Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at ronnypfannschmidt.de Mon Jan 25 11:15:23 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Mon, 25 Jan 2016 17:15:23 +0100 Subject: [pytest-dev] a potential alternative to the py.code merge In-Reply-To: References: <56A56079.3070203@ronnypfannschmidt.de> <20160125101740.GD3793@merlinux.eu> <56A6384A.3060100@ronnypfannschmidt.de> Message-ID: <56A64A1B.8080106@ronnypfannschmidt.de> given the circumstances it might be best to go with 2 after all Am 25.01.2016 um 16:41 schrieb Bruno Oliveira: > > > On Mon, Jan 25, 2016 at 12:59 PM Ronny Pfannschmidt > > wrote: > > i have ideas for replacing/changing it in the back of my head since a > while now, > so i'd like to have a reasonable/easy testbed > > also we could avoid the need for api compatibility even if we copy in > py.code > given that the old api would be available > > > Just to be clear, what are you proposing? > > 1. Hold off merging py.code, implementing on top of that branch an > alternative exception representation? > 2. Merge py.code and work on an alternative exception representation? > > To be honest I would prefer 2, as this would stop blocking issues > which are waiting for py.code to be merged into pytest. > > Cheers, > Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From isaulv at gmail.com Mon Jan 25 14:42:49 2016 From: isaulv at gmail.com (Isaul Vargas) Date: Mon, 25 Jan 2016 14:42:49 -0500 Subject: [pytest-dev] Introduction Message-ID: Hi everyone! My name is Isaul Vargas and I work as a software tester. I have been using py.test since 2013 and I really like the fixture interface of Py.test it's a powerful abstraction! One of the libraries I use to test software is Selenium (and Appium for mobile devices), and one indispensable plug-in I use is pytest-xdist. I love how xdist lets me run tests in parallel, and initially it gave me the impression that tests were distributed among processes in a queue. However to my surprise, test distribution is batched and uneven; this is disappointing because if you're running slow functional, end-to-end tests, it's going to take a long time to run a big batch of tests, if the tests are distributed in an uneven manner. In my own test run of Appium tests, using -n 12, The initial batch of tests runs 12 processes; then when one or two tests finish, another one or two tests are dispatched. However after this initial batch, I only see about 6-8 active processes running. This is very disappointing, and I thought Python had an edge here, compared to other parallel test runners that only batch tests according to the number of processes/threads specified. (like Junit,TestNG on the Java side) So, I've decided to volunteer my time to help improve the Pytest-xdist plugin so that we have a true queue based system of test distribution so that every slot is always busy running tests, and save developers a ton of time! I would like to thank Ronny for taking the time to explain how the current system works, and what changes are needed to make this happen. I am motivated to get this issue fixed; so that we are the first test runner (that I know of) to use a queue based system that doesn't simply batch tests. For those wondering why batching is bad, when you have tests that take 2-3 minutes to complete, plus a few tests that take 5 minutes to complete; if you batch tests such that 1 workers gets all the 5 minutes tests and another workers gets all the short tests then the total run time is almost the same as running all the large tests in serial. I look forward to improving this aspect of pytest-xdist, and I am highly motivated to get this done. I look forward to diving deep into the code and learn the internals of pytest. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Mon Jan 25 19:47:03 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Tue, 26 Jan 2016 00:47:03 +0000 Subject: [pytest-dev] Introduction In-Reply-To: References: Message-ID: Hi Isaul! On Mon, Jan 25, 2016 at 5:42 PM Isaul Vargas wrote: > Hi everyone! My name is Isaul Vargas and I work as a software tester. > I have been using py.test since 2013 and I really like the fixture > interface of > Py.test it's a powerful abstraction! > ... > So, I've decided to volunteer my time to help improve the Pytest-xdist > plugin so that we have a > true queue based system of test distribution so that every slot is always > busy running tests, and save > developers a ton of time! > Excellent, thanks for your enthusiasm and willingness to contribute! It is certainly appreciated. :) I would like to thank Ronny for taking the time to explain how the current > system works, and what > changes are needed to make this happen. I am motivated to get this issue > fixed; so that we are the > first test runner (that I know of) to use a queue based system that > doesn't simply batch tests. > I also wrote an overview here: https://github.com/pytest-dev/pytest-xdist/blob/master/OVERVIEW.md. For those wondering why batching is bad, when you have tests that take 2-3 > minutes to complete, > plus a few tests that take 5 minutes to complete; if you batch tests such > that 1 workers gets all the 5 minutes tests > and another workers gets all the short tests then the total run time is > almost the same as running all the large tests > in serial. > I feel you. We had a similar problem at work as well. I look forward to improving this aspect of pytest-xdist, and I am highly > motivated to get this done. I look forward > to diving deep into the code and learn the internals of pytest. > We had discussed how to avoid distributing tests in batches, and if I remember correctly it was a matter of changing some logic[1] in DSession so it just sends a single test for each node. There is also the restriction that each node must have at least 2 tests to start running them due to how the pytest_runtest_protocol hook works [2]. My suggestion is to hack it into your fork until you get the speed up you want (of course feel free to ask for help), and then we can discuss the best way to implement it and put it as an user option. [1] https://github.com/pytest-dev/pytest-xdist/blob/master/xdist/dsession.py#L311 [2] http://pytest.org/latest/writing_plugins.html#_pytest.hookspec.pytest_runtest_protocol 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 Mon Jan 25 20:42:06 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Tue, 26 Jan 2016 01:42:06 +0000 Subject: [pytest-dev] pytest docs on readthedocs? In-Reply-To: References: <20160125061031.GV533@tonks> <20160125103834.GG3793@merlinux.eu> Message-ID: Hi On Mon, Jan 25, 2016 at 12:39 PM Bruno Oliveira wrote: > I will study how to use this later Today. > Well, registering a CNAME from http://docs.pytest.org to http://pytest.readthedocs.org is beyond my almost non-existent server-configuration-fu skills. :) Could somebody with more experience give some help here? I'm sure for someone who knows his stuff this is a piece of cake. I'm more than willing to help in any way I can. Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From flub at devork.be Tue Jan 26 05:37:51 2016 From: flub at devork.be (Floris Bruynooghe) Date: Tue, 26 Jan 2016 10:37:51 +0000 Subject: [pytest-dev] pytest docs on readthedocs? In-Reply-To: References: <20160125061031.GV533@tonks> <20160125103834.GG3793@merlinux.eu> Message-ID: That requires access to the DNS registrar (which seems to be godaddy), I assume only Holger can do this. Floris On 26 January 2016 at 01:42, Bruno Oliveira wrote: > Hi > > On Mon, Jan 25, 2016 at 12:39 PM Bruno Oliveira > wrote: >> >> I will study how to use this later Today. > > > Well, registering a CNAME from http://docs.pytest.org to > http://pytest.readthedocs.org is beyond my almost non-existent > server-configuration-fu skills. :) > > Could somebody with more experience give some help here? I'm sure for > someone who knows his stuff this is a piece of cake. I'm more than willing > to help in any way I can. > > Cheers, > Bruno. From nicoddemus at gmail.com Tue Jan 26 05:46:12 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Tue, 26 Jan 2016 10:46:12 +0000 Subject: [pytest-dev] pytest docs on readthedocs? In-Reply-To: References: <20160125061031.GV533@tonks> <20160125103834.GG3793@merlinux.eu> Message-ID: On Tue, Jan 26, 2016 at 8:37 AM Floris Bruynooghe wrote: > That requires access to the DNS registrar (which seems to be godaddy), > I assume only Holger can do this. > Thanks. If Holger registers a CNAME from http://docs.pytest.org to http://pytest.readthedocs.org, do you guys foresee any problems in the short term? My understanding is just that we would have two versions of the documentation, one at pytest.org and another at docs.pytest.org, but both are pointing to the 2.8.7 version of the docs so I guess that's OK. After this I think we can configure the server to use a 301 redirect response when accessing the old location? Cheers, Bruno. > > > Floris > > On 26 January 2016 at 01:42, Bruno Oliveira wrote: > > Hi > > > > On Mon, Jan 25, 2016 at 12:39 PM Bruno Oliveira > > wrote: > >> > >> I will study how to use this later Today. > > > > > > Well, registering a CNAME from http://docs.pytest.org to > > http://pytest.readthedocs.org is beyond my almost non-existent > > server-configuration-fu skills. :) > > > > Could somebody with more experience give some help here? I'm sure for > > someone who knows his stuff this is a piece of cake. I'm more than > willing > > to help in any way I can. > > > > Cheers, > > Bruno. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From flub at devork.be Tue Jan 26 06:04:02 2016 From: flub at devork.be (Floris Bruynooghe) Date: Tue, 26 Jan 2016 11:04:02 +0000 Subject: [pytest-dev] pytest docs on readthedocs? In-Reply-To: References: <20160125061031.GV533@tonks> <20160125103834.GG3793@merlinux.eu> Message-ID: On 26 January 2016 at 10:46, Bruno Oliveira wrote: > On Tue, Jan 26, 2016 at 8:37 AM Floris Bruynooghe wrote: >> >> That requires access to the DNS registrar (which seems to be godaddy), >> I assume only Holger can do this. > > > Thanks. If Holger registers a CNAME from http://docs.pytest.org to > http://pytest.readthedocs.org, do you guys foresee any problems in the short > term? My understanding is just that we would have two versions of the > documentation, one at pytest.org and another at docs.pytest.org, but both > are pointing to the 2.8.7 version of the docs so I guess that's OK. > > After this I think we can configure the server to use a 301 redirect > response when accessing the old location? Yep, all that sounds about right to me. From holger at merlinux.eu Fri Jan 29 09:01:33 2016 From: holger at merlinux.eu (holger krekel) Date: Fri, 29 Jan 2016 14:01:33 +0000 Subject: [pytest-dev] sprint funding draft for end june 2016 Message-ID: <20160129140133.GI3793@merlinux.eu> Hey all, i made a sprint-funding draft here: https://github.com/pytest-dev/pytest/pull/1346 feel free to also discuss here. best, holger From holger at merlinux.eu Sat Jan 30 15:01:45 2016 From: holger at merlinux.eu (Holger Krekel) Date: Sat, 30 Jan 2016 21:01:45 +0100 Subject: [pytest-dev] sprint funding draft for end june 2016 In-Reply-To: <20160129140133.GI3793@merlinux.eu> References: <20160129140133.GI3793@merlinux.eu> Message-ID: It was commented and merged. Going to try put it up to indiegogo next week if no one suggests otherwise. 45 day so mid March deadline? On January 29, 2016 3:01:33 PM GMT+01:00, holger krekel wrote: > >Hey all, > >i made a sprint-funding draft here: > > https://github.com/pytest-dev/pytest/pull/1346 > >feel free to also discuss here. > >best, >holger >_______________________________________________ >pytest-dev mailing list >pytest-dev at python.org >https://mail.python.org/mailman/listinfo/pytest-dev -- Sent using mobile touch keys, increased chances for errors and misunderstandings. Enjoy! -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at viner.tv Sat Jan 30 16:44:57 2016 From: tom at viner.tv (Tom Viner) Date: Sat, 30 Jan 2016 21:44:57 +0000 Subject: [pytest-dev] sprint funding draft for end june 2016 Message-ID: Hi all, I'd also be interested in attending the sprint. My flight costs look to be about ?100 (?130). Cheers, Tom Viner On 29 January 2016 at 17:00, wrote: > > Date: Fri, 29 Jan 2016 14:01:33 +0000 > From: holger krekel > To: pytest-dev > Subject: [pytest-dev] sprint funding draft for end june 2016 > Message-ID: <20160129140133.GI3793 at merlinux.eu> > Content-Type: text/plain; charset=us-ascii > > > Hey all, > > i made a sprint-funding draft here: > > https://github.com/pytest-dev/pytest/pull/1346 > > feel free to also discuss here. > > best, > holger > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Sun Jan 31 12:46:14 2016 From: me at the-compiler.org (Florian Bruhin) Date: Sun, 31 Jan 2016 18:46:14 +0100 Subject: [pytest-dev] sprint funding draft for end june 2016 In-Reply-To: References: <20160129140133.GI3793@merlinux.eu> Message-ID: <20160131174614.GQ5703@tonks> * Holger Krekel [2016-01-30 21:01:45 +0100]: > It was commented and merged. Going to try put it up to indiegogo > next week if no one suggests otherwise. 45 day so mid March > deadline? Sounds good to me. If possible it'd be nice if it was online until Friday, so I can mention it at the Swiss Python Summit after my pytest talk :) Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: