[pytest-dev] pytest 7.2.0 released

Hrončok * Nate Meyvis * Neil Girdhar * Nhieuvu1802 * Nipunn Koorapati * Ofek Lev * Paul Müller * Paul Reece * Pax * Pete Baughman * Peyman Salehi * Philipp A * Ran Benita * Robert O'Shea * Ronny Pfannschmidt * Rowin * Ruth Comer * Samuel Colvin * Samuel Gaist * Sandro Tosi * Shantanu * Simon K

[pytest-dev] preparing a pytest-dev/core social video meetup and preparing ideas for a online/offline sprint in 2023

Hi everyone, with the pandemic ensuring lack of safe conferences/sprints since a while now, i think its very helpful to create some type of semi-regular interaction to get the team closer and to foster progress. The last pytest sprint is already an awful long while ago, and with the lack

[pytest-dev] introducing collection boundaries to support expanding fixtures to non-python and testsuites as python packages

Hi everyone, i would like to break open a number of limitations we have in the collection system. 1. parametrize is tied painfully into Python Items I want to finish my experiment for function definitions and generalize them This would mean that instead of multiple python collectors

[pytest-dev] assessing hatch/hatching for python package management

Hi everyone, in https://github.com/pytest-dev/pluggy/pull/362 i prepared to move pluggy to hatch. I hope to eventually move most if not all of pytest-dev over to it. Hatch is a new and modern tool for python package creation. it follows the relevant peps, and has a superset of tox features

[pytest-dev] On ensuring sustainable maintenance of pytest-dev projects

Hi everyone, Please read with the caveat that this stems from a gut feeling that's not yet quantitative verified. As pytest-dev is growing, so is the number of projects that suffer bus-factor and/or non-maintenance. I believe a more active approach to ensuring maintenance /maintainer influx

[pytest-dev] looking for additional maintainers for pytest-asyncio

Hi everyone, unfortunatelyTin Tvrtković, the maintainer of pytest-asyncio is currently not in a position to do more than the bare minimum for pytest-asyncio. As such PRs and PR review stalled. Pytest-core want to help the project, however neither me, nor a good part of pytest-core is that

Re: [pytest-dev] pytest-parallel submission

Based on the fact that pytest-parallel massively monkey-patches the internals of pytest , Im -1 on adding it to pytest-dev code like https://github.com/browsertron/pytest-parallel/blob/master/pytest_parallel/__init__.py#L222-L231 gets me pretty nervous about hopefully upcoming major changes.

Re: [pytest-dev] How can I suppress cleanups when a test fails

, unfortunately. Topher Eliot *From:* Ronny Pfannschmidt Hi Christopher, if you use the tmpdir/tmp_path fixtures pytest provides, just don't do additional cleanup, pytest keeps the last 3 basetemps around precisely for that use-case and drops older ones -- Ronny Am 15.04.21 um 21:56 schrieb

Re: [pytest-dev] How can I suppress cleanups when a test fails

Hi Christopher, if you use the tmpdir/tmp_path fixtures pytest provides, just don't do additional cleanup, pytest keeps the last 3 basetemps around precisely for that use-case and drops older ones -- Ronny Am 15.04.21 um 21:56 schrieb Eliot, Christopher: My test suit generates some

Re: [pytest-dev] pytest documentation

I second Ran, its great to finally see someone someone do this with care. -- Ronny Am 14.03.21 um 08:53 schrieb Ran Benita via pytest-dev: On Sun, Mar 14, 2021, at 01:27, Daniele Procida wrote: Hello pytest team, now that I have been at this a few days, I wanted to check in to see how you

Re: [pytest-dev] Transfer of pyfakefs to pytest-dev?

Hi, i'm not sure if this should go under pytest-dev, if i had found the time to make https://github.com/cogs-of-testing be actually practical/known yet, i'd sugest it for there. -- Ronny Am 05.03.21 um 19:59 schrieb mrbean-bremen via pytest-dev: After the successful transfer of pytest-order

[pytest-dev] my limited/reduced availability until at least mid-september/october

Hi everyone, i just wanted to inform everyone, that due to corona and my specific family situation, we are still in a mitigation situation. This is one of the key factors of my reduced engagement with pytest and the community. By September we will move into into a new flat and get daycare

Re: [pytest-dev] hardcode 4.x mid-2020 EOL

Hi Bruno, Thomas, given that thanks to the release automation work Bruno and the others did put in, the effort for doing releases after community contributions is very sustainable. I believe its fair to leave it open for until there was about a full year without a new contribution/release.

[pytest-dev] A Short Personal Post Morten for the pytest exodus

Hello everyone, ** This was originally intended to be send out mid April but got intentionally delayed to ensure Holger could do the communication for the resolution, i finally picked it up again to send it out ** After failing a number of times to sit down and actually throw together a

Re: [pytest-dev] How to duplicate pytest.Item inside function 'pytest_collection_modifyitems'?

the closest you can get is creating a new item that is reasonably equivalent. The Details of that would depend on what the actual Item subtype is. -- Ronny Am 15.04.20 um 07:45 schrieb Ronny Pfannschmidt: Hi Shiban, its not safely possible to clone a item in general. A) you need to make a new

Re: [pytest-dev] also leaving pytest-dev for now

world already. Best, Dinu On 10. Apr 2020, at 23:05, Ronny Pfannschmidt wrote: Hi everyone, after contemplaing a while i decided to join Bruno and Anthony. When i returned from my hiatus i declared that joy will be important, currently that joy i

[pytest-dev] also leaving pytest-dev for now

Hi everyone, after contemplaing a while i decided to join Bruno and Anthony. When i returned from my hiatus i declared that joy will be important, currently that joy is absent. -- Ronny ___ pytest-dev mailing list pytest-dev@python.org

Re: [pytest-dev] junitxml incremental output writing

Am 06.04.20 um 21:45 schrieb Floris Bruynooghe: Hey Ronny, On Mon 06 Apr 2020 at 09:24 +0200, Ronny Pfannschmidt wrote: an incremental writer has to continuously update either the pre-overstretched xml header of the report or continuously rewrite the file at once. Cool. Thanks for putting

Re: [pytest-dev] junitxml incremental output writing

**re-sent with correct sender mail** Hi Floris, an incremental writer has to continuously update either the pre-overstretched xml header of the report or continuously rewrite the file at once. An implementation would be tricky and need someone to dedicate to it to weed out the detail

[pytest-dev] pytest 5.4.0 released

Loose * Ran Benita * Ronny Pfannschmidt * Stefan Scherfke * Stefano Mazzucco * TWood67 * Tobias Schmidt * Tomáš Gavenčiak * Vinay Calastry * Vladyslav Rachek * Zac Hatfield-Dodds * captainCapitalism * cmachalo * gftea * kpinc * rebecca-palmer * sdementen Happy testing, The pytest Development Team

[pytest-dev] Proposal: Elevating Ran Benita/@bluetech from Contributor to Core

Hi everyone, over the last few months Ran demonstrated both excellent communication and contribution. I believe Ran would make a great addition to the Core team. So after reaching out to Ran to check if that's ok, I'm asking the rest us to formalize addition.. -- Ronny

[pytest-dev] [RFC] experimenting with using matrix as chat/community platform for potentially superseding irc

Hi Everyone, since a while now i have stopped using irc directly/controlled and instead switched to a setup using matrix that i like much better. Matrix enables a few features that i really like, for example * multiple synced clients (on my computers and my mobile) * server side persistent

Re: [pytest-dev] [proposal] global and per item data stashes

the stashes not to be torn down, in > opposition to the original Ronny's idea. > > Le mer. 16 oct. 2019 à 15:42, Ronny Pfannschmidt a > écrit : > >> a little side note as i was just having a little discussion about this >> with a native speaker, >> the word stash isn`t qui

Re: [pytest-dev] [proposal] global and per item data stashes

Oct 2019 at 09:45, Ronny Pfannschmidt wrote: > > > On Wed, 16 Oct 2019 at 01:23, Bruno Oliveira wrote: > >> Hi Ronny, >> >> As you have shared this before in chat, at first glance it sounds like a >> good idea! >> >> Some questions that we can prob

Re: [pytest-dev] [proposal] global and per item data stashes

er, or somewhere else? > i'd like some more iteration on the basics, then perhaps a quick video conference to solidify the thinking, then set up a github project. -- Ronny > > Cheers, > Bruno. > > > On Tue, Oct 15, 2019 at 10:03 AM Ronny Pfannschmidt > wrote: > >>

[pytest-dev] [proposal] global and per item data stashes

Problem: for the storage of helper objects that either tackle certain global tracking details or that track information over the testprotocol lifecycle of test items, we use monkeypatchs and generally just munge around in either the pytest config object or item objects. I would like to propose a

Re: [pytest-dev] Maintenance of pytest-forked

I'll ask for forgiveness >and undo if that was undesired ;) > >Cheers, >Floris > > >On Wed 02 Oct 2019 at 17:41 +0200, Ronny Pfannschmidt wrote: > >> +1 >> >> On Wed, 2 Oct 2019 at 16:26, Markus Unterwaditzer > >> wrote: >> >>>

Re: [pytest-dev] Maintenance of pytest-forked

+1 On Wed, 2 Oct 2019 at 16:26, Markus Unterwaditzer wrote: > Hi, > > I use pytest-forked and would like to add a few more features to it > revolving around gradually opting in or out of forking before testing. > Since it it unmaintained I volunteer to help out with that. What are your >

Re: [pytest-dev] [core] Tidelift Funding

Am 06.05.19 um 16:03 schrieb Bruno Oliveira: Hi Ronny, On Sun, May 5, 2019 at 11:09 AM Ronny Pfannschmidt <mailto:opensou...@ronnypfannschmidt.de>> wrote: i think its a good idea to have this as a opt-in. Currently a Fair Share Mechanism on a opt in basis seems fair, i

Re: [pytest-dev] pytest slack reporting plugin proposal

Hi Arseniy, thanks for your proposal, this is definitively useful for pytest users, which use slack. However pytest itself does not. If pytest-dev takes this on, there is a need of slack aware/using maintainers that move this along (else its just going to painfully and slowly degrade) I

[pytest-dev] enhancing the assertion rewriting experience with custom integration/workflows

Hi everyone, at a project at work which integrates pytest we did build a custom workflow around invoking tests and pytest. This in turn triggers a lot of warnings from the assertion rewriter about things that have been already imported. at first glance fixing this seems rather problematic, as

[pytest-dev] another "i have had it moment" and a stern request ro review our interaction with backward compatibility

Hi everyone, a few days i was trying to replicate an issue in the python shell, and quickly realized, that outside of actually doing a complete pytest.main invocation there is simply no practical and sane way to get a config object that is not in a utterly broken unusable state to begin with.

[pytest-dev] breaking releases required - sorting out FunctionDefinition and Compatproperties

Hi everyone, introducing FunctionDefinition to the collectiontree will trigger indirect api breaches for the compat property setup we have in place to support node.CollectorClass im unwilling to spend a hard to estimate amount of time on a feature that is indeed deprecated since years and will

Re: [pytest-dev] Results of the "drop python 3" poll and what i envision to do about it

Hi Bruno, Am Montag, den 01.10.2018, 08:13 -0300 schrieb Bruno Oliveira: > Hi Ronny, > > On Mon, Oct 1, 2018 at 5:01 AM RonnyPfannschmidt < > opensou...@ronnypfannschmidt.de> wrote: > > Hi Everyone, > > > > > > > > the python3 support poll has run its on > > > >

Re: [pytest-dev] branch proposals - python2 support and pytest 4.0 preps

Am Mo., 24. Sep. 2018 um 16:22 Uhr schrieb Bruno Oliveira < nicodde...@gmail.com>: > Hi Ronny, > > On Mon, Sep 24, 2018 at 10:29 AM Ronny Pfannschmidt < > opensou...@ronnypfannschmidt.de> wrote: > >> >> a) maintenance-python2 : this will be the branch

[pytest-dev] branch proposals - python2 support and pytest 4.0 preps

hi everyone, in face of the pending larger changes for a pytest 4.0 removing various things and for the support branching of python2 id like to propose 2 extra branches a) maintenance-python2 : this will be the branch where bugfixes for the last python2 suporting versions will happen i intend

Re: [pytest-dev] [TIP] pytest Python 2.7 support (poll) (re-sent)

(re-sending since i used the wrong mail first) I refuse since its a pain to sort out GDPR compliance when self- hosting that way. public is easy, public and law abiding is a pain. -- Ronny Am Sonntag, den 23.09.2018, 18:57 +0200 schrieb Daniel Knüttel: > Am Sonntag, den 23.09.2018, 08:20

Re: [pytest-dev] Accessing markers in pytest_generate_tests

Am Freitag, den 21.09.2018, 12:44 +0100 schrieb Nikolaus Rath: > Hello, > > I am currently using code like this: > > def pytest_generate_tests(metafunc, _info_cache=[]): > # [...] > > fn = metafunc.function > > do_something(fn.with_backend.kwargs) > for spec in

Re: [pytest-dev] Disable pushing directly to features and master branches

+1 Am 6. Juli 2018 17:15:16 MESZ schrieb Nicholas Williams : >+1 > >On Fri, Jul 6, 2018 at 10:13 AM, Bruno Oliveira >wrote: > >> Hi everyone, >> >> GitHub has started issue warnings that the email service we use to >notify >> pushes to master and features will be discontinued (and we suspect it

Re: [pytest-dev] preparing a set of breaking changes

in 2010 yield tests where likely still working correctly they where fundamentally broken ever since pytest introduced the collection phase -- Ronny 2018-04-11 12:46 GMT+02:00 Chris Dent : > On Sun, 8 Apr 2018, RonnyPfannschmidt wrote: > > * removal of yield tests, ever

Re: [pytest-dev] Custom reporting for asserts without comparison operators?

xpect False, instead of a Falsey alternative). Also, if I were going to > use AST manipulation like this, I would probably reference assert_myfunc() > by attaching it as a private attribute to myfunc() itself -- and then > reference it with ast.Attribute() node instead of an ast.Name(). But

Re: [pytest-dev] mark fix-up major milestone, please review

again - please show me those changes! -- Ronny 2018-03-20 19:33 GMT+01:00 Florian Schulze <florian.schu...@gmx.net>: > On 20 Mar 2018, at 16:11, Ronny Pfannschmidt wrote: > > just a quick note - the markers pr as far as i understood it does not >> qualify for a 4.0

Re: [pytest-dev] mark fix-up major milestone, please review

net>: > On 20 Mar 2018, at 15:07, Floris Bruynooghe wrote: > > On Tue, Mar 20 2018, Ronny Pfannschmidt wrote: >> >> 2018-03-20 9:18 GMT+01:00 Floris Bruynooghe <f...@devork.be>: >>> >>>> On Mon, Mar 19 2018, Ronny Pfannschmidt wrote: >>>>

Re: [pytest-dev] mark fix-up major milestone, please review

2018-03-20 15:07 GMT+01:00 Floris Bruynooghe <f...@devork.be>: > On Tue, Mar 20 2018, Ronny Pfannschmidt wrote: > > > 2018-03-20 9:18 GMT+01:00 Floris Bruynooghe <f...@devork.be>: > >> On Mon, Mar 19 2018, Ronny Pfannschmidt wrote: > >> > I also

Re: [pytest-dev] mark fix-up major milestone, please review

2018-03-20 9:18 GMT+01:00 Floris Bruynooghe <f...@devork.be>: > Hi Ronny, > > On Mon, Mar 19 2018, Ronny Pfannschmidt wrote: > > > Hi everyone, > > > > in https://github.com/pytest-dev/pytest/pull/3317 i introduced a new > way to > > store marks and as

[pytest-dev] mark fix-up major milestone, please review

Hi everyone, in https://github.com/pytest-dev/pytest/pull/3317 i introduced a new way to store marks and aslo consistently use it (this fixed a few bugs pytest dragged along since years) some of the things i had to do is introduce a internal FunctionDefinition node that's currently just being

Re: [pytest-dev] pytest 3.5 soon?

Am Donnerstag, den 15.03.2018, 19:30 + schrieb Bruno Oliveira: > On Thu, Mar 15, 2018 at 4:26 PM RonnyPfannschmidt annschmidt.de> wrote: > > > > > > > > > > +1 > > > > the next big things i will try to work on are > > > > > > > > * a new

Re: [pytest-dev] Alias to parametrize

HI, i also like apply_params, it well in place with my desire of a more complete rename instead of just cutting it short. +1 for eternal old api's i would like to introduce a warning which is per default filtered (like a future-warning), simply so plugin authors can have a advised way of

Re: [pytest-dev] Alias to parametrize

the alt_spellings is actually a list of wrong spellings that triggers errors - the reason being that the word as different spellings in british and american English if we actually change the word i would like to see something completely different, not just some short-cutting -- Ronny

Re: [pytest-dev] Parametrizing dependent fixtures

Hi, my understanding is, that the direct parametrization replaces the fixture lookup for the involved tests, which is not a planned "feature" per se, but still a neat tool to have -- Ronny 2018-01-08 14:07 GMT+01:00 Bruno Oliveira : > Hi Edgar, > > On Mon, Jan 8, 2018 at

Re: [pytest-dev] Proposal: use milestones again for features/deprecations/removals

+1 from me 2018-01-05 2:12 GMT+01:00 Bruno Oliveira : > Hi, > > We used milestones in the past to track what would go in each release, > including bugs and new features, but we have not been using them anymore > and I think the reason is because we never usually kept that

Re: [pytest-dev] [proposal] experiment with adapting gitmate.io for automating issue maintenance/triaging tasks

i propose that unless someone vetos, i'll take a look into activating it for pytest-dev/pytest on monday. -- Ronny Am Freitag, den 08.12.2017, 18:12 + schrieb Bruno Oliveira: > Howdy Ronny, > > On Fri, Dec 8, 2017 at 2:36 PM Ronny Pfannschmidt <opensource@ronnypf > annsc

[pytest-dev] [proposal] experiment with adapting gitmate.io for automating issue maintenance/triaging tasks

Hi Everyone, a while back the people behind gitmate.io did interview me to expand their perspective with focus on how pytest does things as well as how i do certain things at work, they also provided me with a basic example on what i would have done for pytest:

Re: [pytest-dev] pytest _pytest/mark.MarkMapping behavior

Am Montag, den 04.12.2017, 20:29 +0300 schrieb Yury Krasouski: > Hi Ronny, > > Many thanks for explanation! > > Got this idea. > > I am not sure that you are right person for this question. But could > you do a favor and suggest a prefirable way for extraction test > marks? right now there is

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

Hi Brian, good call, i should extend this writing to it makes sens what i imagine is an api like this: node.find_marks() -> iterates over all marks of all nodes node.find_marks('name') -> iterates over all marks that have a name node.find_marks(SomeType) -> iterates over all marks that are

Re: [pytest-dev] Doing pre-releases (was: Re: Help testing 3.2.0 release (part 2))

we should mirror borgbackup in that regard https://borgbackup.readthedocs.io/en/stable/changes.html#changelog materializes releases candidates we can do a automation around that as well i wanted to propose adding a travis deploy that uploads release proposals with materialized changelogs anyway

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

(sending again due to prior sender typo) 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, since as things as

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

Personally ID strongly prefer a major release because we do change an api that is consumed, IMHO we should do one on any case where we know beforehand, But as we don't implement strict semver, I opened this discussion to generate a consensus. My general impression is that the majority agrees

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

Hi, i'd like to move execnet under pytest-dev on github, the author-map was completed a while ago, all that's missing is to move the history and converting the issues. i'm asking of there are any objections, else i'll tackle it later this week. -- Ronny

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

Hi everyone, with the recent discovery of https://github.com/pytest-dev/pytest/issues/2398 which was a result of accidentally introducing object as base class in pytest-2.9.1 via https://github.com/pytest-dev/pytest/pull/1486 since https://github.com/pytest-dev/pytest/pull/2179 , which will

[pytest-dev] [proposal] abolishing the features branch

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

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

Apr 05, 2017 at 18:19 +, Bruno Oliveira wrote: >> Hi Ronny, Holger, all, >> >> On Wed, Apr 5, 2017 at 1:31 PM holger krekel <hol...@merlinux.eu> >wrote: >> >> > On Wed, Apr 05, 2017 at 17:25 +0200, Ronny Pfannschmidt wrote: >> > > while expe

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

I just wanted to point out a quirk, that i stumbled upon while checking for symmetry with the python language -- Ronny On 05.04.2017 17:58, Florian Bruhin wrote: > On Wed, Apr 05, 2017 at 05:49:24PM +0200, Ronny Pfannschmidt wrote: >> i meant the except clause > I know, I was just

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

Hi all, my own stance is still to give it a different name, while experimenting i learned of the fun fact that None is a "valid exception type" for except clauses on at least python 2.7 however on python3 it is invalid and a type error, since the usage patterns of python don't hold such a

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

because fixing finer details gets so much harder when complexity increases) And with a Kid on the way i'm no longer willing to take those kinds of blows in personal time at least. -- Ronny On 30.03.2017 23:36, holger krekel wrote: > On Thu, Mar 30, 2017 at 23:08 +0200, Ronny Pfannschmidt wrote:

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

I do because we make something a "magical god function" again, more of the rant tommorow. Gn8, Ronny Am 30. März 2017 23:03:45 MESZ schrieb Bruno Oliveira : >On Thu, Mar 30, 2017 at 4:32 PM holger krekel >wrote: > >> It's a bit odd to introduce a new

Re: [pytest-dev] doc/docs.pytest.org now proper with https

+1 On 29.03.2017 16:30, holger krekel wrote: > Thanks to Florian Schulze who instantiated an nginx/letsencrypt > proxy on the planet.pytest.org pytest now serves ssl directly > (https://docs.pytest.org ) directly by proxying and reverse-proxying > to readthedocs.org. But we need an email admin

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

e old CHANGELOG entries btw? > > Cheers, > > On Tue, Mar 21, 2017 at 12:29 PM Ronny Pfannschmidt > <opensou...@ronnypfannschmidt.de > <mailto:opensou...@ronnypfannschmidt.de>> wrote: > > Hi Bruno, > > due to its Nature its best suited for intr

[pytest-dev] [proposal] big flake8 cleanup before the 3.1 release

Hi all, before releasing 3.1 i would like to bring pytest up to coding standards while not all agree on the exact rules of flake8, i find it an insult to my eyes to that basically all tools that don't/can't support all kinds of config files pretty much show about half of pytest in violation all

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

gt;> >> 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

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

nst 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 < > opensou...@ronnypfannschmidt.de>

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

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

Re: [pytest-dev] Commit access to pytest

Hi All, i believe that when we do something like this, we should lean in the direction of C 4.1 and focus on enabling more people to merge good pull requests of others (we already started to follow a informal process where we no longer self-merge until approval) With the review Approval system

[pytest-dev] landing pytest.marked

Hi everyone, i'd like to bring https://github.com/pytest-dev/pytest/pull/1921 back to attention it fixes a long-standing issue wrt putting mark on parameter values while properly separating the markers from the parameter value, it has intentionally limited scope of only dealing with marks, and

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

On 20.10.2016 15:14, Bruno Oliveira wrote: > Hey Ronny, > > > On Thu, Oct 20, 2016 at 10:55 AM Ronny Pfannschmidt > <opensou...@ronnypfannschmidt.de > <mailto:opensou...@ronnypfannschmidt.de>> wrote: > >> b) Another suggestion from Ronny: running co

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

HI Bruno On 20.10.2016 14:20, Bruno Oliveira wrote: > On Thu, Oct 20, 2016 at 7:12 AM Ronny Pfannschmidt > <opensou...@ronnypfannschmidt.de > <mailto:opensou...@ronnypfannschmidt.de>> wrote: > > > On 20.10.2016 10:56, holger krekel wrote: > > Hey Ron

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

Hi Holger, On 20.10.2016 10:56, holger krekel wrote: > Hey Ronny, > > i'd like to get back to your original suggestion ... > > On Wed, Sep 07, 2016 at 11:38 +0200, Ronny Pfannschmidt wrote: >> Hi all, >> >> while trying to turn various internal markers of a work

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

On 20.10.2016 09:17, Florian Bruhin wrote: > * Ronny Pfannschmidt <opensou...@ronnypfannschmidt.de> [2016-10-20 09:07:47 > +0200]: >>> Finally, and I only just remembered, Holger has some lingering code >>> somewhere which does something like: >>&g

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

forwarding as i send it with the wrong sender address Forwarded Message Subject:Re: [pytest-dev] ANN: pytest-external-blockers - prototype released Date: Wed, 19 Oct 2016 17:27:42 +0200 From: Ronny Pfannschmidt <i...@ronnypfannschmidt.de> To: Floris Bruy

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

forwarding as i send it with the wrong sender address Forwarded Message Subject:Re: [pytest-dev] Proposal: python namespacign for markings/marker objects Date: Wed, 19 Oct 2016 17:24:32 +0200 From: Ronny Pfannschmidt <i...@ronnypfannschmidt.de> To:

Re: [pytest-dev] creating pytest-boxed and removing boxed from xdist

On 12.10.2016 02:16, oliver wrote: > On Tue, Oct 11, 2016, 18:57 Bruno Oliveira > wrote: > > On Tue, Oct 11, 2016 at 7:46 PM oliver > > > wrote: > > Is there

[pytest-dev] creating pytest-boxed and removing boxed from xdist

Hi everyone, in order to enable refactoring xdist, i took out the boxed code and started to put it into https://github.com/pytest-dev/pytest-boxed the plan is to make the next release of xdist dependent on it, then phase it out as dependency later -- Ronny

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

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 semantic difference between "skipped for a local reason" and "skipped for a external

Re: [pytest-dev] the sorry state of pylib tests and pylib

ably here is py.path.local usage. Maybe > writing a wrapper around pathlib with py.path.local API would be a good not > too cumbersome strategy because it doesn't touch much code. > > best, > holger > > > > On Thu, Sep 22, 2016 at 14:15 +0200, Ronny Pfannschmidt wrote: >

Re: [pytest-dev] the sorry state of pylib tests and pylib

On 27.09.2016 16:25, Bruno Oliveira wrote: > > > On Tue, Sep 27, 2016 at 11:14 AM Ronny Pfannschmidt > <opensou...@ronnypfannschmidt.de > <mailto:opensou...@ronnypfannschmidt.de>> wrote: > > > > On 27.09.2016 15:59, Bruno Oliveira wrote: >&g

Re: [pytest-dev] the sorry state of pylib tests and pylib

y, they can pin it. > > Not sure about the py.path encoding errors you mention though. > > Cheers, > > On Thu, Sep 22, 2016 at 9:16 AM Ronny Pfannschmidt > <opensou...@ronnypfannschmidt.de > <mailto:opensou...@ronnypfannschmidt.de>> wrote: > > Hi everyone, > >

[pytest-dev] the sorry state of pylib tests and pylib

Hi everyone, while fixing up some pylib tests i noticed a set of massive issues a) all py.code related tests are completely broken on pytest 3.0 b) the svn related tests are completely broken and outdated (can we kill it?) c) depending on environment there are massive issues with pylib path

Re: [pytest-dev] pytest-warnings in 3.1

m in test warnings (the > thing pytest-warnings does atm but doesn't separate). > Regards, > Florian Schulze > On 22 Sep 2016, at 10:00, Ronny Pfannschmidt wrote: > > im not aware of anyone signing up for that > as far as i remember there also was no further

Re: [pytest-dev] tox is now on github

expected this to do the right thing on Github now? > > Cheers > Oliver > > On Sat, 17 Sep 2016 at 22:14 Ronny Pfannschmidt > <opensou...@ronnypfannschmidt.de > <mailto:opensou...@ronnypfannschmidt.de>> wrote: > > Hello everyone, > > i am pleas

[pytest-dev] the move of pylib to github is technically finished

Hi all, i finished the move to github and did a few simple fixups in the process i learned various details, and fixed bugs in the migration tool now i feel confident i can do the same for tox in the afternoon. i'll finish up the detail works with pylib and create issues wrt its updating to

Re: [pytest-dev] transfer repo / pypi access / ML announce

random thought - i do wonder if we should just publish a rss feed with the releases 2016-09-14 18:33 GMT+02:00 holger krekel : > On Wed, Sep 14, 2016 at 15:48 +0200, Florian Bruhin wrote: > > Hey, > > > > * holger krekel [2016-09-14 13:58:18 +0200]: > > >

Re: [pytest-dev] transfer repo / pypi access / ML announce

anything that can run deploy scripts works -- Ronny 2016-09-14 16:12 GMT+02:00 Sebastian Rahlf <ba...@redtoad.de>: > Little word of caution: Not all plugins are on github/use git. > Travis will only work with github projects afaik. > > Sebastian > > 2016-09-14 14:01 GMT+

Re: [pytest-dev] transfer repo / pypi access / ML announce

another point, we might want to introduce an pytest-attic org and move unattended pytest-dev repos there based on primary maintainership going away -- Ronny On 14.09.2016 13:58, holger krekel wrote: > I am a bit concerned that people who transfer repos to pytest-dev think that > it receives

Re: [pytest-dev] transfer repo / pypi access / ML announce

sounds good to me, can we up the release automation requirements, so git tag + travis deploys can be used for releasing? best, Ronny On 14.09.2016 13:58, holger krekel wrote: > I am a bit concerned that people who transfer repos to pytest-dev think that > it receives magic maintenance because

[pytest-dev] pylib conversation for review and bb ux mistake

Hi all, i prepared pylib for a move to github the result can be reviewed under https://github.com/RonnyPfannschmidt-migration-tests/pylib while preping pylib for the move i declined a few simple pull requests that where lacking some finishing touches without realizing that on bitbucket, a

Re: [pytest-dev] [wishlist] handling reuse of pytest plugins outside of pytest

you would like to accomplish? At > least to me your email is a little vague and I wouldn't know where to start > discussion about it... > > On Wed, Sep 7, 2016 at 10:47 AM Ronny Pfannschmidt <rpfan...@redhat.com> > wrote: > >> Hi, >> >> recently i am starting to ve

Re: [pytest-dev] [proposal] regendoc automation via travis + pytest-bot on GH

, the approach you propose sounds good as well. Are you planning to > tackle this anytime soon? > > Cheers, > Bruno > > On Wed, Sep 7, 2016 at 8:33 AM Ronny Pfannschmidt <rpfan...@redhat.com> > wrote: > >> hi, >> >> i would like to propose an regendoc autom

[pytest-dev] [wishlist] handling reuse of pytest plugins outside of pytest

Hi, recently i am starting to very painfully hit a massive wall which is trying to use pytest integrated functionality outside of a test run the inability to use them in some way is pretty much actively holding me back from running test helpers in ipython sessions & co at work we work around

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

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 purposes/intents such a flat namespace really doesn't scale as such i would like to propose

[pytest-dev] [proposal] regendoc automation via travis + pytest-bot on GH

hi, i would like to propose an regendoc automation using the pytest-bot the basic idea is, to have travis deploys on master/features that would run regendoc, commit changes as pytest-bot, upload those to pytest-bot/pytest-dev and open pull requests against pytest itself all we would need for

  1   2   >