Re: [pytest-dev] pytest-django

On 21 May 2013 16:52, Mahdi Yusuf yusuf.ma...@gmail.com wrote: I am having issues running pytest-django without inhertiting form Django Testcase You'll have to be a little more specific about what your issue is... I am also pretty sure this is what is causing the issue to do deal with the

Re: [pytest-dev] fixtures and pylint W0621

Hi, On 4 December 2013 15:05, lahwran lahw...@lahwran.net wrote: perhaps pytest.fixture could return a special object that rejects all operations, rather than the decorated function object; such that `theobject == 5` would produce a big flashy error in theobject.__eq__ indicating you need to

Re: [pytest-dev] regarding parametrized ids

Hello Holger, On 16 December 2013 05:31, holger krekel hol...@merlinux.eu wrote: Hi Floris, i think the docstring is wrong: argvalues is not part of @fixture signature. Oops, copied that from MetaFunc.parameterize(). Fixed it to refer to params. Btw, Anatoly suggests even core committers

Re: [pytest-dev] py.test and decorators

Hi Sarah, Apologies for not responding before, I wasn't really following this thread however Holger is away for a month hence the long silence I guess. I've used the zip and followed the instructions. As an example I've started with uncommenting testpoison and indeed as soon as uncommented

Re: [pytest-dev] Setting up tox

On 16 April 2014 22:58, Brianna Laugher brianna.laug...@gmail.com wrote: So, what is the answer? 1) Install multiple pythons in a single virtualenv, somehow The multiple python's need to be on the system, system wide installs are fine. Personally I use the system provided ones plus, on ubuntu,

Re: [pytest-dev] 2.6 / please help with remaining bugs

On 28 April 2014 08:22, holger krekel hol...@merlinux.eu wrote: Could some of you help and assign issues to yourself and see about fixing or discussing them? For the record I'm interested in #507: Assertion breaks with dictionary comprehention but don't quite feel comfortable enough to assign

Re: [pytest-dev] pytest logo previews / please check drafts out

FWIW I quite like #37 which adds black white variations to #31 which already seems popular. On 20 May 2014 18:18, Dj Gilcrease digitalx...@gmail.com wrote: I added #38 as a concept, I am not an artist and I have no interest in the prize money, but if someone wants to take the concept of the Y

Re: [pytest-dev] extended asserts

Hi, On 29 July 2014 09:24, Anatoly Bubenkov bubenk...@gmail.com wrote: what do you think about extending the existing assert representation with this https://pypi.python.org/pypi/datadiff would be nice if we could extend datadiff with what pytest does for string diff So datadiff is not as

Re: [pytest-dev] extended asserts

On 2 August 2014 10:08, Anatoly Bubenkov bubenk...@gmail.com wrote: On 1 August 2014 23:09, Floris Bruynooghe f...@devork.be wrote: * Vendor datadiff, I think the licenses are compatible. by vendoring you mean using it as a dependency? No, vendoring means taking the datadiff source

Re: [pytest-dev] extended asserts

On 4 August 2014 08:35, holger krekel hol...@merlinux.eu wrote: On Fri, Aug 01, 2014 at 22:09 +0100, Floris Bruynooghe wrote: * Re-write what datadiff produces directly inside _pytest/assertion/utils.py. It's not that a crazy task. This is only a bad idea if datadiff keeps evolving a lot

[pytest-dev] Encouraging the use of bookmarks rather then branches

Hi, I was wondering if people would be fine with encouraging contributors to use bookmarks rather then named branches in mercurial for pull requests. Named branches are rather permanent and more suited for things like the 2.6.x release branch or permanent things like that. Bookmarks work really

Re: [pytest-dev] Encouraging the use of bookmarks rather then branches

On 14 August 2014 16:25, Bruno Oliveira nicodde...@gmail.com wrote: I stumbled on the same thing. It's unfortunate that Bitbucket's support for bookmarks in PRs is lacking. :( Yes, that is unfortunate. But note that for a simple contribution, as explained by the CONTRIBUTING.rst guide, this

Re: [pytest-dev] Encouraging the use of bookmarks rather then branches

On 13 August 2014 17:11, Anatoly Bubenkov bubenk...@gmail.com wrote: However, it's important to keep the contributing workflow simple and user friendly. With the need of getting the commit hash on every PR change it makes the process very annoying IMHO. True, it would be nicer if bitbucket did

Re: [pytest-dev] pytest-xdist-1.11: restarting crash nodes, fixture cache fix

[Oops, lost the list on this reply - sorry] On 18 September 2014 21:43, Floris Bruynooghe f...@devork.be wrote: On 18 September 2014 19:51, Anatoly Bubenkov bubenk...@gmail.com wrote: hmm, but that grouping is not important for session scoped fixtures, right? i mean, what's the sense

Re: [pytest-dev] top-level conftest.py not recognized when running tests in sub-directories

So I'll give an alternative opinion and say that I don't mind using classes as namespaces for py.test. The simple migration path away from .setup_method() is to create an autouse fixture in the class instead. On 25 Sep 2014 13:21, Jens Hoffmann j...@solute.de wrote: This gives me a little pain,

Re: [pytest-dev] Pytest fails with the wrong error when unicode_literals is present

Hi, So if I understand all this correctly there are two things going on: 1) There's a bug with re-interpret which does not respect the unicode_literals from the original source. 2) re-interpret is being used instead of rewrite because an assert occurs in a file which is not a test module

Re: [pytest-dev] Move pytest-faulthandler to pytest-dev@github

Sounds good to me On 31 March 2015 at 11:10, Bruno Oliveira nicodde...@gmail.com wrote: Hi all, I would to like to know if there are any objections to moving the pytest-faulthandler (https://github.com/nicoddemus/pytest-faulthandler) plugin to the pytest-dev@github organization? Cheers,

Re: [pytest-dev] release checklist / de-monopolizing release process

On 1 April 2015 at 08:21, holger krekel hol...@merlinux.eu wrote: Hi Floris, thanks for the summary. Comments inline. On Tue, Mar 31, 2015 at 23:55 +0100, Floris Bruynooghe wrote: Hi, I started doing inline replying but I think it got confusing. I mostly agree so far, including

Re: [pytest-dev] release checklist / de-monopolizing release process

Hi, I started doing inline replying but I think it got confusing. I mostly agree so far, including with semantic versioning, but would like to summarise the usage of branches how I think/understand it should work: Each release has a release/maintenance branch: pytest-2.6, pytest-2.7 etc. This

Re: [pytest-dev] EP2015 -- Bilbao CFP ends today

Hi, On 14 April 2015 at 09:24, Brianna Laugher brianna.laug...@gmail.com wrote: I would like to submit something (assuming submissions close at the end of today), about adopt pytest month. But I am not sure if to put more of a technical focus (tidbits in applying pytest to existing projects

[pytest-dev] pytest-2.7.1: bugfix release, wheel support, yield fixtures

install -U pytest Thanks to all who contributed to this release, among them: Bruno Oliveira Holger Krekel Ionel Maries Cristian Floris Bruynooghe Happy testing, The py.test Development Team 2.7.1 (compared to 2.7.0) - - fix issue731: do not get confused

[pytest-dev] Branches and pull request workflow

Hi all, I've just been merging a few pull requests using the new workflow and it seems to work fine: - Accept the PR into pytest-2.7 - Add changelog etc if required - Merge into default I also experimented a bit with squashing commits as discussed at fosdem but I'll leave that for later (needs

Re: [pytest-dev] Failure to create representation with sets having unsortable elements

Hi, Interesting case, but I would say we should treat it as a bug in py.test and manage to handle this or at least fall back gracefully. So could you please create an issue at https://bitbucket.org/pytest-dev/pytest/issues/new and include all the information you provided here directly in the

Re: [pytest-dev] pass a collection of function arguments to Pytest at the command line

Hi, On 2 April 2015 at 22:21, dpb dpb dpb.mediam...@gmail.com wrote: Is there a way to pass a collection of function arguments to Pytest at the command line so as to take the place of parameters being passed by the parametrize decorator? Sometimes one set of parameters, out of a large

Re: [pytest-dev] merging PR freedom

On 3 June 2015 at 22:53, holger krekel hol...@merlinux.eu wrote: Hi Ronny and all other commiters :) i realize that from time to time you only approve a PR but don't merge it. Please feel more free to just merge. I guess it's partially habit, sometimes just giving other people the chance to

Re: [pytest-dev] moving to git / issues?

On 16 June 2015 at 03:20, Anatoly Bubenkov bubenk...@gmail.com wrote: after such a success with pytest move, should we start the same process for other repos under pytest-dev on bb? Not sure if anyone saw my tweet, but I noticed (sadly too late!) that the git repo seems to be ~50Mb to clone

Re: [pytest-dev] github push notification / pytest channel

On 20 June 2015 at 16:37, Anatoly Bubenkov bubenk...@gmail.com wrote: How about slack for notifications and chat? On 15:42, Sat, Jun 20, 2015 Tom Viner t...@viner.tv wrote: +1 for Gitter. Really reduces the barrier to entry for people to engage. Could gitter bridge bi-directionally with IRC

Re: [pytest-dev] 2.8.0 release plan? 2.7.2?

We could also follow how zeromq does things and simply not have branches in the main repos, using forks instead for maintenance releases. It does not help with the fact that we'd be back in charge of cherry picking fixes for bugfix releases though. But I honestly don't mind too much, happy to

Re: [pytest-dev] 2.8.0 release plan? 2.7.2?

On 17 June 2015 at 05:31, Bruno Oliveira nicodde...@gmail.com wrote: Hi, Do we have an idea of when we would like have a 2.8.0 release, or at least what we would like to see in the new version? Nope, maybe the pluggy dependency? But not sure if that was the plan. And about 2.7.2? I think we

Re: [pytest-dev] EP2015 py.test gathering

Hi Tibor, On 17 June 2015 at 01:54, Tibor Arpas tibor.ar...@infinit.sk wrote: I also booked everything yesterday. I'll be presenting MASHING UP PY.TEST, COVERAGE.PY AND AST.PY TO TAKE TDD TO A NEW LEVEL (about pytest-testmon) on Tuesday 15:45 :) Nice, look forward to it. Will the developers

Re: [pytest-dev] Adopt Pytest Month the report (draft)

On 8 June 2015 at 23:12, Brianna Laugher brianna.laug...@gmail.com wrote: Hello! Sorry to keep you all in suspense since April... But finally! here is a draft of the APM report. https://bitbucket.org/pytest-dev/pytest/issue-attachment/676/pytest-dev/pytest/1433801126.73/676/APMreport.pdf

[pytest-dev] Cheeseshop (PyPI) access

Hi all, As discussed at EuroPython I was looking at giving everyone in the pytest-dev groups on bitbucket and github access on the cheeseshop (pypi) to be able to do releases. Currently I only know the following cheeseshop usernames however: hpk ronny flub nicoddemus anatoly So could other

Re: [pytest-dev] Can we get a pytest-timeout release?

-dev team as well. :-) Regards, Floris On 15 August 2015 at 00:20, Floris Bruynooghe f...@devork.be wrote: Hi, Just checking this but I believe the PR you refer too is already released as part of the 0.4 release on https://pypi.python.org/pypi/pytest-timeout/0.4 Am I mistaken somehow? I

Re: [pytest-dev] Can we get a pytest-timeout release?

Hi, Just checking this but I believe the PR you refer too is already released as part of the 0.4 release on https://pypi.python.org/pypi/pytest-timeout/0.4 Am I mistaken somehow? I don't think there's currently any commits that are not released AFAIK, but I could be terribly wrong. Regards,

[pytest-dev] ANN: pytest-logbook

Hi all, To add to the confusion of a whole bunch of py.test plugins related to logging I've just released a very first version of pytest-logbook. This plugin captures log records emitted via logbook and shows them in test reports as well as making them available via some fixtures. pypi:

Re: [pytest-dev] ANN: pytest-logbook

On 12 November 2015 at 13:46, Andreas Pelme <andr...@pelme.se> wrote: >> >> On 12 nov 2015, at 14:34, Floris Bruynooghe <f...@devork.be> wrote: >> >> >> Hopefully you find this useful if you use py.test and logbook. Feel >> free to give any fee

Re: [pytest-dev] [ANN] pytest-travis-fold plugin

On 18 October 2015 at 21:44, Eldar Abusalimov wrote: > > Sorry for spamming the mailing list. It's not spamming, you're more then welcome to use the list to announce and talk about your plugin. Thanks for contributing to the py.test ecosystem! Floris

Re: [pytest-dev] Releases

Hello, On 9 August 2015 at 23:45, Bruno Oliveira nicodde...@gmail.com wrote: Hi, I also think we should release 2.8 directly. Yes, a release which supports python 3.5 would be nice. AFAIK we could just release 2.7.3 without any work so if someone wants to release that I think you should just

Re: [pytest-dev] [proposal] creation of a pytest-dev meta organisation on github

Hi all On 7 December 2015 at 19:42, Ronny Pfannschmidt wrote: > Hi everyone, > > given that pytest-dev is slowly growing, i'm feeling it is necessary to > have a transparent management channel to see > and communicate the details that span more than one project,

Re: [pytest-dev] pytest sprint 2016 / getting started

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 >

Re: [pytest-dev] CFP EuroPython 2016

Hi Raphael! On 11 June 2016 at 16:13, Raphael Pierzina wrote: > The second CFP for EuroPython 2016 is open until tomorrow. It it reserved > for “hot” topics. I am thinking about speaking about the upcoming pytest > developer sprint and what’s in store for pytest 3.0. What

Re: [pytest-dev] My gripes with pytest and tox

On 10 June 2016 at 09:36, Florian Schulze wrote: > >> For the fixtures, I often need to do something like: >> >>@pytest.fixture(params=['one', 'two']) >>def fixt(request): >># ... >>return request.param >> >> I just wonder if there's a slightly

Re: [pytest-dev] Climbing at the sprint

On 14 June 2016 at 08:32, Andreas Pelme wrote: > >> On 14 juni 2016, at 09:17, Florian Bruhin wrote: >> >> Is there something I can join without climbing experience and without >> being too much of a sports guy? If so, count me in, because it *does* >>

[pytest-dev] Climbing at the sprint

Hello py.test sprinters, In the past some of us have been to the local climbing wall at conferences before. So I had a look and Freiburg seems to have 2 bouldering walls and a climbing wall. If anyone else expresses any interest I'd be happy to bring some climbing stuff and go climbing one or

Re: [pytest-dev] Joining the sprint

Hi Stefan, I noticed you've not yet added yourself to the wiki: https://github.com/pytest-dev/pytest/wiki/sprint2016 Could you add yourself please? Looking forward to meeting you in Freiburg, Floris On 19 May 2016 at 15:25, Farmer wrote: > Hello Holger and Floris, > > thank you

Re: [pytest-dev] pytest sprint 2016 / getting started

On 10 Jan 2016 18:59, "Floris Bruynooghe" <floris.bruynoo...@gmail.com> wrote: > > On 8 Jan 2016 09:11, "Floris Bruynooghe" <f...@devork.be> wrote: > > > Date ranges: > > > > > > 20-26th June or > > > > > >

Re: [pytest-dev] pytest docs on readthedocs?

On 26 January 2016 at 10:46, Bruno Oliveira <nicodde...@gmail.com> wrote: > On Tue, Jan 26, 2016 at 8:37 AM Floris Bruynooghe <f...@devork.be> wrote: >> >> That requires access to the DNS registrar (which seems to be godaddy), >> I assume only Holger can do this.

Re: [pytest-dev] RFC: pytest sprint indiegogo page (draft)

please do! On 3 February 2016 at 22:21, Floris Bruynooghe <f...@devork.be> wrote: > On 3 February 2016 at 16:23, holger krekel <hol...@merlinux.eu> wrote: >> Feel free to edit or comment here further. I'd like to publish tomorrow >> european evening and i think pyt

Re: [pytest-dev] pytest docs on readthedocs?

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? > > >

Re: [pytest-dev] Participation in 2016 Sprint

Hi Oliver, On 17 February 2016 at 11:08, Oliver Bestwalter wrote: > I would like to participate in the sprint and I won't need any funding. Great that you want to join us! > I am using py.test in all my pet projects and professionally since 2011. > Last year I started

Re: [pytest-dev] Joining the sprint

Hi Stefan, Great to hear you're interested to help out with py.test development. At this stage we've already worked out the budget the best we can and as far as I know we won't be able to support your travel or accommodation unfortunately (but I may be mistaken). I believe the venue we have can

Re: [pytest-dev] pytest overall execution timeout option

If you need actual interruption then as said you need to use the mechanisms that pytest-timeout uses. But bear in mind that they come with lots of caveats about how they work. Short of an external process supervisor which does `kill -9` nothing is ever guaranteed to stop your test run. But

Re: [pytest-dev] pytest overall execution timeout option

On 20 April 2016 at 17:04, Bruno Oliveira wrote: > On Wed, Apr 20, 2016 at 11:01 AM Shankar Hiremath > wrote: >> >> As part of “pytest_sessionfinish” we are doing few major activities >> (collecting cluster logs, artifacts, screen shots &

Re: [pytest-dev] pytest overall execution timeout option

On 20 April 2016 at 15:07, Shankar Hiremath wrote: > Hi Floris, > > Thank you for the suggestion, can you please give me few pointers or > guidenace to start with (i am relatively new to pytest plugin development) > i will try to implement and send the pull

Re: [pytest-dev] removing assertion reinterpretation and making the assertion rewriter a vendored package

Hello, On 13 April 2016 at 13:44, Ronny Pfannschmidt wrote: > currently we still have a monkey-patch in python that causes interesting > issues in c interaction, > > namely the replacement of the Built-in Assertion error by the rewrite module > > its highly unlikely we can

Re: [pytest-dev] can we remove the deprecated pytest.config variable assignment before 3.0

On 20 July 2016 at 21:50, holger krekel wrote: > On Wed, Jul 20, 2016 at 16:15 +, Bruno Oliveira wrote: >> Hi Ronny, >> >> AFAIK there’s no simple way to workaround it, correct? For example, I >> believe there might be code out there using pytest.config as a conditional >>

Re: [pytest-dev] Postpone 3.0?

On 14 July 2016 at 23:45, Brianna Laugher wrote: > It's mainly Floris, Oliver and me that are the hold up right? Removing > reinterpret assert and 2x docs. Reinterpret is now removed as of this morning! I should do one more PR with some doc updates. Is that fine to

Re: [pytest-dev] Request for additional plugin maintainers on PyPI

Oops, lost the pytest-dev cc. Apologies On 28 Jun 2016 18:13, "Ronny Pfannschmidt" <rpfan...@redhat.com> wrote: > I'd be happy to have that, but Travis is very limited just as our > resources are > Am 28.06.2016 18:04 schrieb "Floris Bruynooghe" <f...

Re: [pytest-dev] Request for additional plugin maintainers on PyPI

Sadly pypi does not have groups so not as easy. My username is flub there, probably want to add a few pytest-dev ppl other then me as well tough On 28 Jun 2016 15:05, "Dave Hunt" wrote: > Good idea - done! I’ll still need at least one maintainer for each plugin > in PyPI. > >

Re: [pytest-dev] EuroPython Talk on pytest 3.0

I'll just sneak in a slide when you leave your laptop unattended... On 8 Jul 2016 23:19, "Raphael Pierzina" wrote: > If only Floris wouldn’t be around :D I reckon he’s not going to approve of > this and might throw rotten tomatoes at me. #DoNotWant > > > On 08 Jul 2016, at

[pytest-dev] py._code

Hi, We did move the py._code library over to pytest._code a little while ago, I wasn't really involved so don't remember the details. But seems it was never removed from the py library itself. Was this on purpose? Do we want to maintain two versions of this code? Reason I'm asking is because

[pytest-dev] rewrite-plugins & AppVeyor

Hello, For the rewrite-plugins PR (https://github.com/pytest-dev/pytest/pull/1641) the AppVeyor build seems to have timed out but has no obvious failures. Is AppVeyor always this unreliable? It means mergable PRs are marked as having issues on the summary, and if you wait long enough they will

[pytest-dev] Blog RSS invalid

Hi blog creation people, I was going to submit blog.pytest.org to planet.python.org, however one of the checks they do is validation and it seems our blog fails to validate: https://validator.w3.org/feed/check.cgi?url=http://blog.pytest.org/feeds/all.rss.xml If anyone knows how to fix these

Re: [pytest-dev] pypy rejecting scrambled mails now, action decission needed - proposing pytest-dev@python.org

Sounds reasonable to me. On 22 Jan 2017 21:03, wrote: Hi all, After input from Holger and Floris i will action in the following order: 1. try to upload without author_email 2. on failure upload with pytest-dev as author_email thanks for the input and enjoy

[pytest-dev] Reviving pytest-commit

Hi all, Those of you subscribed to pytest-commit may have noticed I tried to revive it as it had been dead since the github migration. On an unrelated issue I noticed I actually used this a fair bit when it was working. Sadly github will only send us commit messages instead of full diffs by

Re: [pytest-dev] pytest and Mozilla's Open Source Support program

Hi Sivan, I've had a quick look at this as well and Mozilla's guidance says you need to submit a particular project rather then general maintenance. There probably are a bunch of smaller things which could make up a proposal but I'm struggling of coming up with a few large projects to list right

Re: [pytest-dev] process for replacing yield tests with modern style

On 29 August 2016 at 09:31, Ronny Pfannschmidt wrote: > Hi Chris, > > currently there is no easy/good Replacement for the use-case you outline. > the "correct" way would be a custom py.test specific collector Yeah, a custom collector is the way to go here. I agree that it

Re: [pytest-dev] Proposal: python namespacign for markings/marker objects

On 7 September 2016 at 10:38, Ronny Pfannschmidt wrote: > Hi all, > > while trying to turn various internal markers of a work project > into public plugins, i noticed a very plain problems - different other > plugins used the same generic marker name for different

Re: [pytest-dev] ANN: pytest-external-blockers - prototype released

On 4 October 2016 at 18:18, Ronny Pfannschmidt wrote: > Hi all, > > i'm happy to announce the release of pytest-external-blockers [0] > it was created in order to be able to semantically track for what reasons a > test was skipped > > a normal `pytest.skip` doesn't offer a

Re: [pytest-dev] t-shirts and stickers now out, thanks Florian!

Hi All, On 25 October 2016 at 06:15, Ronny Pfannschmidt wrote: > a) preparing and planning much better connectivity for the next sprint, > the venue was fabulous but i think the bad internet connection > was a tax on productivity while hacking, ensuring

Re: [pytest-dev] Commit access to pytest

Hi all, I've opened https://github.com/pytest-dev/pytest/pull/2068 if you're interested in seeing this move forward. Or if you feel strongly against this of course. Thanks, Floris On 16 November 2016 at 19:42, Floris Bruynooghe <f...@devork.be> wrote: > On 15 November 2016 at 23:1

[pytest-dev] Commit access to pytest

Hi all, A while ago Ronny proposed to adopt the ZeroMQ C4.1 process. While the discussion there never got very far (and I forgot to pick it up at the sprint) I'd like to propose a rather less radical workflow while attempting to make it easier for people to get on board. Basically I'd propose

Re: [pytest-dev] [proposal] introducing attrs to the codebase

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

Re: [pytest-dev] [proposal] using towncrier for merge-friendly changelog management

This gets a big +1 from me, it would be great to have this done more easily. On 21 Mar 2017 8:54 a.m., "Ronny Pfannschmidt" < opensou...@ronnypfannschmidt.de> wrote: > Hi all, > > today i noticed how pip manages its change-logs in a pretty interesting > way, > > they manage the fragments to be

Re: [pytest-dev] [3.1 feature] "assert not raise exception" helper: opinions about the name

Hi all, After this whole thread I'm now starting to lean towards being -1 on the entire concept of the feature. It tries to optimise the Don't Repeat Yourself thing for one rather specific corner case where the cognitive load on pytest itself seems to become higher then what is saved by doing

Re: [pytest-dev] Documentation proposal

Hi Daniele, On 15 July 2017 at 12:32, Daniele Procida wrote: > Dear pytest developers, > > I have been speaking to Raphael Pierzina at EuroPython. > > I propose to restructure the pytest docmentation, according to this scheme > (the

Re: [pytest-dev] on opening up single character options via a registry

RonnyPfannschmidt writes: > as it pains me that we sneakily call private methods to use single > character options in xdist, > i propose to open up single character options to other plugins by means > of a registry, What's wrong with the stance that this was a

Re: [pytest-dev] moving execnet over to gh under pytest-dev

On 16 May 2017 at 14:52, Ronny Pfannschmidt wrote: > Hi, > > i'd like to move execnet under pytest-dev on github, no objections from me. ___ pytest-dev mailing list pytest-dev@python.org

Re: [pytest-dev] the potential need to release 4.0 instead of 3.1, proposal

Hi, We have a deprecation cycle so we can't just break the API and bump to 4.0 as I understand it. So we accidentally broke the API, that sucks but generally I don't think we can fix that anymore because rolling it back will break it again for those who already adjusted. However given the

Re: [pytest-dev] deprecating/removing py.path.local.write due to https://github.com/pytest-dev/py/issues/107

On 24 June 2017 at 20:09, Bruno Oliveira wrote: > > > On Sat, Jun 24, 2017 at 2:31 PM holger krekel wrote: >> >> ... maybe simply documenting the new methods (write_bytes/write_text i >> guess) >> and not mentioning the old methods anymore but not

Re: [pytest-dev] the potential need to release 4.0 instead of 3.1, proposal

On 18 May 2017 at 13:56, Bruno Oliveira wrote: > > > On Thu, May 18, 2017 at 9:47 AM Ronny Pfannschmidt > wrote: >> >> that pr that changes all classes, i'd like to keep it, just communicate >> the changes correctly > > > Floris, Florian, Holger,

Re: [pytest-dev] the potential need to release 4.0 instead of 3.1, proposal

Ronny Pfannschmidt writes: > given the rightfully reasserted constraints that seems a reasonable > course of action, > > i'd prefer to keep it reopened instead of won't fix, > and i'd like to see a revising of the deprecation policy, What we can do according to

Re: [pytest-dev] progressing with fixing mark, a potentially backward compatible path to progression

Seems like a sane approach at first sight. What are the risks to breaking plugins which rely on the collection nodes? I'm guessing fairly small as there are just some new intermediate collection nodes. Thanks for your perseverance in this battle to sort out marks! Floris On 23 May 2017 at

Re: [pytest-dev] pytest-testdirectory fixture

On 29 May 2017 at 13:27, Morten V. Pedersen wrote: > Hi Floris, > Thanks. Did not know that there was an internal similar thing in pytest. I > take a look at that, perhaps some things can be improved based on the ideas > there. It's in _pytest/pytester.py if you're looking.

Re: [pytest-dev] pytest 3.1 warning capture woes

Hi, On 26 May 2017 at 15:51, Brian Okken wrote: > My opinion: > - make 3.1.1 with this feature opt in I'd have agreed with this initially. But I think releasing an un-broken version should probably only be done within the first 24-48h. After that the pain might just

Re: [pytest-dev] pytest-testdirectory fixture

Hi Morten, That looks nice. It's a similar idea as what pytest uses internally to test itself, but without all the messiness there. Good to finally see a simple external version of this. Thanks for publishing it as a plugin! Regards, Floris "Morten V. Pedersen" writes:

Re: [pytest-dev] Sponsored pytest stickers

Hi, Raphael Pierzina writes: > I am planning to order a batch of pytest stickers for PyData Berlin > and EuroPython. The folks over at Sticker Mule would be happy to > sponsor this on condition that we link to their website in our project > README. What’s your opinion on

Re: [pytest-dev] Remove AUTHORS file?

Bruno Oliveira <nicodde...@gmail.com> writes: > On Thu, May 4, 2017 at 11:07 AM Floris Bruynooghe <f...@devork.be> wrote: > >> What's nice is that AUTHORS is just an alphabetical list of people while >> the github page ranks people implicitly by some random

Re: [pytest-dev] Remove AUTHORS file?

Bruno Oliveira writes: > Hi everyone, > > I was wondering what people thought about removing the AUTHORS file from > pytest and point to GH's Contributors link instead? > > https://github.com/pytest-dev/pytest/graphs/contributors > > This is automatically generated from the

Re: [pytest-dev] Garbage collection and pytest fixtures

Hi Dan, On 7 October 2017 at 22:32, Dan Nealschneider wrote: > If I have a fixture like the following, should I expect the object returned > by the fixture to be garbage collected after the tests that use it complete? > Or after all the tests in the module complete?

Re: [pytest-dev] marks - proposals for a new api and a path forward

Hello, RonnyPfannschmidt writes: > Am 29.08.2017 um 15:18 schrieb Bruno Oliveira: >> On Sun, Aug 27, 2017 at 4:04 AM Ronny Pfannschmidt >> > > wrote: >> what i imagine is an api like

Re: [pytest-dev] Blog down?

"Florian Schulze" writes: > The missing trailing dot in the CNAME was the issue, should work again. > TTL is one hour, so some DNS caches might still need to catch up. Thanks! ___ pytest-dev mailing list pytest-dev@python.org

Re: [pytest-dev] Question about fixtures and the use of finalizers vs yield

Another often-overlooked benefit of request.addfinalizer() is that it can also be used in a test directly for one-off finalization: def test_foo(request): # arrange: set some stuff up just for this test request.addfinalizer(lambda: ...) # clean global state of thing setup # act #

Re: [pytest-dev] deprecating `pytest_plugins` in non-initial conftests to prevent unintended smear/spill of plugin configurations

On 25 October 2017 at 09:54, RonnyPfannschmidt wrote: > hi everyone, > > while reviewing the codebase i noticed, that the code that is ensuring > we don't use conftests from other folders don't take into account > `pytest_plugins` declared in such a conftest >

Re: [pytest-dev] Creating a complex PyTest program, wondering about the best way to handle collection errors, etc.

Hi Nick, On Tue 24 Apr 2018 at 07:03 -0500, Nicholas Williams wrote: > Wow. After carefully reading the pytest-cov plugin (only) code and the > PyTest code that powers loading plugins, I figured it out. The plugin was > getting loaded before pytest-cov started the Coverage analyzer. Since the >

Re: [pytest-dev] Creating a complex PyTest program, wondering about the best way to handle collection errors, etc.

On Fri 27 Apr 2018 at 15:15 -0500, Nicholas Williams wrote: > One thing that concerned me in this whole process is that the vast majority > of PyTest code appears to be behind a private API named `_pytest`. I was > unable to implement this plugin without accessing these APIs. I could find > no

Re: [pytest-dev] hook to obtain parameters for parametrized test

Hi Ilya, On Wed 16 May 2018 at 01:15 +0300, Ilya Kazakevich wrote: > I write plugin for pytest, and I need to obtain parameters > for test decorated with @parametrize before this test is actually called. Could you describe a bit more what your use-case is? Why do you need to obtain these

Re: [pytest-dev] request to add pytest-echo to pytest-dev plugins

+1 from me too :) On Sun 29 Apr 2018 at 16:39 +, Bruno Oliveira wrote: > Hi Stefano, > > Yep according to our rules we still need one more +1. > > Cheers, > > On Sun, Apr 29, 2018 at 1:37 PM Stefano wrote: > >> Dear Bruno, >> >> thanks for your reply. >> >> I have to

Re: [pytest-dev] Parametrizing dependent fixtures

Curious. I'm rather reluctant to tell people to use or rely on this however. Which I guess is the actual question that was asked. ;-) To me this seems like an implementation detail of the mark.parametrize decorator. Besides, is it really a good idea to make your parametrisation so indirect? I

Re: [pytest-dev] Alias to parametrize

Hi, Bruno Oliveira writes: > A PR[1] has been submitted which adds `parameterize` as an alias to > `parametrize`. Florian Bruhin and I are not very keen to the idea given > that there is an explicit warning for it already and having different names > to the same thing

  1   2   >