Mailman 3 April 2017 - pytest-dev

Suggestion: EuroPython pytest/tox/devpi helpdesk
by Oliver Bestwalter July 4, 2017

July 4, 2017

Hi all, EuroPython is on the horizon and they have a new thing (or at least new for me) called "helpdesk" > Helpdesk / 10 slots > Helpdesks are a great way to share your experience on a technology, by offering to help people answering their questions and solving their practical problems. You can run a helpdesk by yourself or with colleagues and friends. Each helpdesk will be open for 3 hours in total, 1.5 hours in the morning and 1.5 hours in the afternoon. People looking for help will sign up for a 30 minute slot and talk to you. There is no specific preparation needed; you just need to be proficient in the technology you run the helpdesk for. see: https://ep2017.europython.eu/en/call-for-proposals/ I would be interested to try this and volunteer to help with questions about tox mainly. Would anybody else interested in that kind of thing? If we find a handful of people that would want to do that, we could have a tox/pytest/devpi helpdesk :) Cheers, Oliver

4 13

Re: [pytest-dev] [proposal] introducing attrs to the codebase
by Floris Bruynooghe June 24, 2017

June 24, 2017

Hi, Personally I also don't mind the dependency. Though I know in the past we've had a policy of keeping dependencies to a minimum as well as licenses. Attrs uses MIT as well so that should not be a problem. One thing which does stand out is that attrs is at v16, suggesting they break their API a lot. Since you work with it already I guess you have an idea on whether they've stabilised by now or the changes are not so bad? As an aside, if we're happy to introduce more libraries then maybe we should also consider the standard six package instead of doing our own stuff, mostly because I'd make it easier for new contributors. Regards, Floris On 6 Dec 2016 11:16, "Bruno Oliveira" <nicoddemus(a)gmail.com> wrote: Oh good point Raphael. Here's the link for the discussion about pip dropping Python 2.6: https://github.com/pypa/pip/issues/3955 Cheers, Bruno On Tue, Dec 6, 2016 at 8:57 AM Raphael Pierzina <raphael(a)hackebrot.de> wrote: > Hey there, > > I don’t mind adding a dependency as long as there is a need for it. +1 > > The problem I see with ‘attrs’ as it stands today, is that it does not > support Python 2.6 whereas pytest does. So we probably want to get > https://github.com/pytest-dev/pytest/issues/1273 in before adding ‘attrs’ > as a dependency. I’m not up-to-date with how things are in pip as to > dropping Python 2.6 compatibility. I can’t seem to find a ticket on the pip > issue tracker. > > Best, > Raphael > > On 06 Dec 2016, at 09:52, Bruno Oliveira <nicoddemus(a)gmail.com> wrote: > > Hi Ronny, > > Could you list the classes which you think would be changed to use > 'attrs'? I'm not against adding another dependency if it can help us > maintain the codebase. Also, introducing a new dependency should be done in > `3.1.0`, not in a patch release. > > Cheers, > Bruno. > > On Tue, Dec 6, 2016 at 5:44 AM Ronny Pfannschmidt < > opensource(a)ronnypfannschmidt.de> wrote: > > Hi all, > > i'd like to introduce https://pypi.python.org/pypi/attrs as a > dependency, > > its a fairly usefull library that takes away quite some boilerplate and > common error cause while automatically adding repr, comparators and > similar small details to python classes. > > I have used it in a number of personal projects, and dont want to miss > it by now. > > -- Ronny > _______________________________________________ > pytest-dev mailing list > pytest-dev(a)python.org > https://mail.python.org/mailman/listinfo/pytest-dev > > _______________________________________________ > pytest-dev mailing list > pytest-dev(a)python.org > https://mail.python.org/mailman/listinfo/pytest-dev > > > _______________________________________________ pytest-dev mailing list pytest-dev(a)python.org https://mail.python.org/mailman/listinfo/pytest-dev

4 4

[proposal] abolishing the features branch
by Ronny Pfannschmidt May 23, 2017

May 23, 2017

Hi everyone, since quite a while now we keep a lot of code away from users by leaving it in the features branch, more recent detail https://github.com/pytest-dev/pytest/issues/2365 where even i didn't realize we had a fix since half a year. >From my point of view it has been demonstrated that we don't deliver well from the features branch, and it has been a massive pain to keep merged with master over and over. As such i would like to stop using a features branch at all and return to having only master. -- Ronny

5 9

[proposal] using towncrier for merge-friendly changelog management
by Ronny Pfannschmidt May 4, 2017

May 4, 2017

Hi all, today i noticed how pip manages its change-logs in a pretty interesting way, they manage the fragments to be composed before a release in the folder "news" in files named like "$ticketnumber.$changetype" before a release those files get take out and composed into the change-log. The fabulous tool behind that is https://github.com/hawkowl/towncrier/ - after taking a first look at it, i believe it should be a massive enhancement compared to what we put ourselves trough right now. i also would be delighted, if we used it in more projects ^^ cheers, Ronny

3 7

[3.1 feature] "assert not raise exception" helper: opinions about the name
by Bruno Oliveira April 26, 2017

April 26, 2017

Hi all, We are about to land on the features branch an implementation of the proposal outlined by Florian Bruhin ( https://github.com/pytest-dev/pytest/issues/1830) where we introduce a small helper to facilitate writing parametrized tests that sometimes raise an error for an input parameter and sometimes don’t: @pytest.mark.parametrize('inp, expectation', [ (-1, pytest.raises(ValueError)), (3.5, pytest.raises(TypeError)), (5, pytest.does_not_raise), (10, pytest.does_not_raise), ])def test_bar(inp, expectation): with expectation: validate_positive_integer(inp) The pytest.does_not_raise helper actually does nothing, is meant solely to help writing this type of parametrized test. The PR is at https://github.com/pytest-dev/pytest/pull/2339 and is ready for merging, but this email is about *how to name it* since we had some debate about it. We have this proposals so far: - pytest.does_not_raise; - pytest.not_raises; - pytest.wont_raise; So we would like to ask for opinions here because nailing down the name is important. *Another question* is if someone sees a problem in making it a singleton like in the example above, or if we should force users instantiate it each time: pytest.does_not_raise(). Cheers,

12 34

Help available
by Robert Kuska April 25, 2017

April 25, 2017

Hello everyone, my employer (kiwi.com) decided to hire a bunch of interns to work on open source projects we actively use in our company. Each intern has its own mentor and each mentor picks his open source projects he wants to overlook. I am one of the mentors and, as you probably already guessed, I picked pytest to be my project (it was one of the first modules I ever used in python). My current plan is to pick some documentation issues firstly afterwards continue with some bugs fixing and as a final step implement some medium-sized feature. There are basically no rules from my employer about scope of work and therefore I've decided to ask you whether you have some lists of features you would like to have implemented but don't have a time to. I would appreciate any ideas. Regards, Robert Kuska rkuska(a)gmail.com

2 1

Need access to parameter IDs during pytest_collection_modifyitems
by Pete Savage April 6, 2017

April 6, 2017

Hi all, Forgive this seemingly useless requirement. We have the requirement to collect the parameters which are used in a parametrized test to pass to a test case results system. Currently I am pulling out the parameters using the item.callspec.params except there are issues where the parameter is an object and has a differing repr than that id that was used in the idlist. To keep things consistent, I would like to tell the test case result system the ID of the parameter that was used for the test, if one is available and if not to fall back to the object. This is basically being used to describe a whole set of tests during a --collect-only that _should_ run based on parametrization and passing those into the results system, so that they can be populated across multiple smaller runs with the actual results. The problem is this information is not available on the item object. Here is what IS available: Consider the following contrived test --- import pytest @pytest.mark.parametrize('num', [1, 2, 3], ids=["one", "two", "three"]) @pytest.mark.parametrize('letter', ['a', 'b', 'c'], ids=["A", "B", "C"]) def test_something(num, letter): print num, letter --- During the modifyitems hook I can access the following: * item.callspec.params * gives me a dict {'num': 1, 'letter': 'a'}) - but this doesn't give me IDs * item.callspec.indices * gives me a dict {'num': 0, 'letter': 0}) - this is great that if I had the ID list for each param I could look up the right one * item.callspec._idlist * gives me a list ['A', 'one']) - this is great except I don't know which ID is for which parameter * item._getobj().parametrize * gives me <MarkInfo 'parametrize' args=('letter', ['a', 'b', 'c'], 'num', [1, 2, 3]) kwargs={'ids': ['one', 'two', 'three']}> - which unfortunately is missing the kwargs entry for the IDs for the second parameter) Seems like a problem with the MarkInfo item? Is there any way I can construct this information? Thanks, -- Pete Savage Principal Quality Engineer Red Hat UK psavage(a)redhat.com IM: psav redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted Twitter: @redhatway | Instagram: @redhatinc | Snapchat: @redhatsnaps

2 1