Re: [pytest-dev] pytest-iam plugin submission to pytest-dev

On Thu 04 Apr 2024 at 16:32 +0200, Éloi Rivard via pytest-dev wrote: > Hi, > I am the maintainer of pytest-iam [1] and its underlying library Canaille [2]. > This is a plugin that spawns a lightweight customizable OpenID Connect server > for test purpose. It can be used to check several behaviors

Re: [pytest-dev] pytest-libfaketime plugin submission to pytest-dev

On Sat 06 Apr 2024 at 23:43 +0300, Ran Benita via pytest-dev wrote: > On Thu, Apr 4, 2024, at 17:47, Éloi Rivard via pytest-dev wrote: >> Hi, >> I am (also) the maintainer of pytest-libfaketime [1]. It brings and hides >> some boilerplate for using python-libfaketime [2] with pytest. >>

Re: [pytest-dev] Enabling 2FA for pytest-dev on PyPI

300, Bruno Oliveira wrote: > Yes that's why the message came to be hehehe. > > It will eventually be mandatory, from my understanding. > > Cheers > > On Sun, Jan 22, 2023 at 6:47 AM Floris Bruynooghe wrote: > >> So why does tidelift keep telling us every week this isn't c

Re: [pytest-dev] Enabling 2FA for pytest-dev on PyPI

So why does tidelift keep telling us every week this isn't completed? On Fri 20 Jan 2023 at 10:47 -0300, Bruno Oliveira wrote: > Sorry for the noise folks, pytest is a critical project and 2FA will be > mandatory anyway: > > 2FA requirement > > Requiring 2FA for this project will require all

Re: [pytest-dev] Submitting pytest-inline plugin

Hello, I'm happy to +1 as well, seems nothing wrong from a plugin acceptance perspective. IIRC we're not vetting the plugins, merely allowing them to be taken over if the bus factor becomes fatally low. Not that I'm saying the feedback isn't useful either though, maybe file it as an issue on

Re: [pytest-dev] Enabling 2FA for pytest-dev

I'd also be +1 on this. Note however that the user in question did have 2FA enabled already and indeed this doesn't help for compromised tokens. I think we can force some limits on what tokens are allowed, I'm not entirely sure here and on how restricting this may turn out to be for people.

[pytest-dev] github compromised account on organisation

Hi folks, Github recently sent an email warning of a member of the pytest-dev org (I'm purposefully not adding identifiable information here) likely having a compromised API token that may have been abused. The member in question only has read access to all but one plugin repository so the

Re: [pytest-dev] Candidate plugin "pytest-tcpclient"

Hello, +1 from me too. Cheers, Floris On Wed 16 Nov 2022 at 08:18 -0300, Bruno Oliveira wrote: > Hello Anders, > > I did take a look at the plugin and it does fit all requirements. > > +1 from me. > > Cheers, > Bruno > > On Tue, Nov 15, 2022 at 9:52 PM Anders Lindstrom > wrote: > >> Hi, >>

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

I totally second this! (despite my total lack of contributing the last years, I still think this would be good for current contributors) I think during warmer summer moths it is entirely possible to create a COVID-responsible sprint. I think the e.g. the Rust conferences have demonstrated it is

[pytest-dev] pytest-timeout maintaintenance

Hi all, As you might be aware I've been doing extremely little with respect to pytest-timeout maintenance. This is mostly fine as it's a very low maintenance package at this point in its lifecycle, but it does give people who do try to contribute valuable things a very suboptimal experience of

Re: [pytest-dev] Digging into pytest's history

On Thu 13 May 2021 at 12:04 +0200, Florian Bruhin wrote: > I've always wondered when pytest actually really was born - the first > commit in the current pytest repository > (5992a8ef21424d7571305a8d7e2a3431ee7e1e23) is > from January 2007, and even that commit alone already tells a lot: This >

Re: [pytest-dev] proposal: plugin metadata

Hi, Previously there was https://plugincompat.herokuapp.com/ for testing versions but eventually that was stopped as too much work to maintain as I understand it. As for further categorising, generally I think this could be nice but you'd need a standard place for plugins to add this. There's

Re: [pytest-dev] Plugin for test suite execution

Hi Sivaram, Hope you are well and nice that you wrote a pytest plugin! As far as I recall pytest by default already executes tests in the order they are defined in the source code though. I guess this was not expressive enough for your needs? As for advertising, it's best to follow the advice

Re: [pytest-dev] Transfer of pytest-html and pytest-molecule under pytest-dev

:54:20PM -0300, Bruno Oliveira wrote: > > On Mon, Aug 17, 2020 at 4:42 PM Floris Bruynooghe > wrote: > > > > > On Mon 17 Aug 2020 at 08:51 -0300, Bruno Oliveira wrote: > > > > On Sat, Aug 15, 2020 at 2:05 PM Sorin Sbarnea > > > wrote: > > >

Re: [pytest-dev] Transfer of pytest-html and pytest-molecule under pytest-dev

On Mon 17 Aug 2020 at 08:51 -0300, Bruno Oliveira wrote: > On Sat, Aug 15, 2020 at 2:05 PM Sorin Sbarnea wrote: >> https://pypi.org/project/pytest-plus/ >> https://pypi.org/project/pytest-molecule/ > > +1 from me. > > I'm assuming Floris also agrees, so feel free to transfer the repositories > to

Re: [pytest-dev] Transfer of pytest-html and pytest-molecule under pytest-dev

On Sat 15 Aug 2020 at 18:02 +0100, Sorin Sbarnea wrote: > I would like to transfer two pytest plugins (MIT) that I wrote and maintain > to pytest-dev organization. Cool! > I may note that the list of requirements is a little bit outdated, but > I think nobody bothered with minor details like

Re: [pytest-dev] Looking for speaker for online conference

Hi Aidis, On Thu 18 Jun 2020 at 08:30 +0300, Aidis Stukas wrote: > I am looking for someone to give a talk/run a sprint on pytest at PyCon > Lithuania *Online* conference > The conference will take place on July 31-August . Could you provide some more details like how what level of talk you are

Re: [pytest-dev] What's the best way of writing tests for terminal width resize behaviour in an assertrepr plugin?

Hi Harry, To the best of my knowledge you stumbled into a hard and dark corner of pytest. IIRC previous attempts at improving this have not gone too well. But like this always goes, it sounds like you've set yourself up to be the expert now and are in a great position to clean this up and make

Re: [pytest-dev] junitxml incremental output writing

On Tue 07 Apr 2020 at 06:46 +0200, Ronny Pfannschmidt wrote: > instead of creating the junitxml report direcly, > one could use the new reportlog plugin, and add report replay to it, > thus collecting the report logs on the first run, then combiningthe > pytest reports to junitxml on the second

[pytest-dev] junitxml incremental output writing

Hello all, One of the most common things users of pytest-timeout struggle with is that they lose Junit XML reporting when a timeout occurs. This never bothered me, it was by design, but that doesn't stop users from being bothered. Which made me wonder, does anyone know if there's a reason that

Re: [pytest-dev] New home and maintainer for pytest-describe?

Hi Christoph, On Fri 03 Apr 2020 at 20:25 +0200, Christoph Zwerschke wrote: > The author of pytest-describe, a pytest plugin for Jasmine-style nesting > of test functions, is currently looking for a new maintainer. > > jacebrowning and I already volunteered. If anybody else is interested in >

Re: [pytest-dev] -k EXPRESSION: How to allow for case-insensitive matching

Using the full test id as shown by -v is what I always use for this case instead of using -k On Wed, 4 Dec 2019, 23:58 Bruno Oliveira, wrote: > Hi Oscar, > > Not right now, the matching is always partial... not sure how we could > signal to `-k` that we want an exact match of the last part of

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

I've created a pytest-forked-developers team, invited untitaker and gave the team write permissions on 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,

Re: [pytest-dev] moving pytest-timeout to github

On Sun 29 Sep 2019 at 11:00 +0200, Ronny Pfannschmidt wrote: > I still have my stuff around, I'll collect the details this evening > and will create a example repository using the user maps we created > before Great to hear this tooling is still around, thank you so much for doing all that work!

[pytest-dev] moving pytest-timeout to github

Hi all, The pytest-timeout still lives on bitbucket under the pytest-dev team, mostly because me as original author still prefer mercurial, not that I'm overly active anymore anyway. However since bitbuket is dropping mercurial support this is a bit annoying. My other personal projects I'll

Re: [pytest-dev] Using pytest_assertrepr_compare() for marked tests only?

Hi Shawn, On Sun 12 May 2019 at 19:44 -0400, Shawn Brown wrote: > I'm playing with the idea of returning a custom explanation for tests with > a particular marker but returning Pytest's standard explanation for tests > without the marker. Interesting, would you mind describing your usecase a

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

On Tue 07 May 2019 at 15:36 -0300, Bruno Oliveira wrote: > On Tue, May 7, 2019 at 3:20 PM Floris Bruynooghe wrote: > >> On Mon 06 May 2019 at 23:58 +0200, Ronny Pfannschmidt wrote: >> >> > we should make a git repo where we track meta level documentation, >&g

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

On Mon 06 May 2019 at 23:58 +0200, Ronny Pfannschmidt wrote: > Am 06.05.19 um 16:03 schrieb Bruno Oliveira: >> Hi Ronny, >> >> On Sun, May 5, 2019 at 11:09 AM Ronny Pfannschmidt >> > > wrote: >> >> i think its a good idea to have this as a opt-in. >>

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

mitting-plugins-to-pytest-dev >>>> >>>> >>>> Mainly, you should transfer ownership of the repository to a pytest-dev >>>> admin (it can be me). From there, we will move the repository under the >>>> pytest-dev organization and then add y

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

Hi Arseniy, Ronny, If you want to maintain your plugin under pytest-dev I think that should be fine as long as [0] is followed. While indeed this doesn't mean you'll magically have other maintainers it doesn't seem like that's what you're after. So as long as the requirements are met this is

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

Hi Bruno, On Wed 01 May 2019 at 17:25 -0300, Bruno Oliveira wrote: > So my question is: how do the core maintainers feel about pytest joining > Tidelift? Thanks for the wait-and-see approach taken, I likewise have shifted my opinion on this from some scepticism to mostly positive. So if there's

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

Hi Ronny, On Thu 29 Nov 2018 at 15:57 +0100, Ronny Pfannschmidt wrote: > 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

Re: [pytest-dev] Advice for writing a failure bisection plugin

On Sun 04 Nov 2018 at 02:47 +0100, Daniel Hahler wrote: > On 03.11.18 08:54, Craig de Stigter wrote: > > However, I note the excellent pytest-xdist plugin is good at > > spawning worker subprocesses and sending tests to them, and rather > > than re-invent the wheel I wondered if I could make my

Re: [pytest-dev] keeping passwords out of code

Hi Derek, On Sat 22 Sep 2018 at 09:19 -0700, Derek Sisson wrote: > I currently use a local yaml file, with passwords keyed to account ids, > along with a data model of users in the codebase keyed to the same IDs. My > conftest queries the yaml file with the ids to grab the passwords, and it's >

Re: [pytest-dev] sorting out broken config initialization - by doing major releases with api breakages

On Tue 21 Aug 2018 at 11:03 -0300, Bruno Oliveira wrote: > Personally my next goal is the task to replace the internal warnings system > to use the standard warnings module, which I should be able to tackle soon > as I have some vacation time coming up, but after that I'm happy to help > with the

Re: [pytest-dev] junitxml update

cular junit version, and adding in any extra >> command line args. Once I have a proof of concept, I'll comeback and share >> what I have before I move forward. >> >> Rusty >> >> >> On Thu, Aug 16, 2018 at 11:56 AM, Floris Bruynooghe >> w

Re: [pytest-dev] junitxml update

On Thu 16 Aug 2018 at 15:10 +0200, RonnyPfannschmidt wrote: > Im fine with any other proposal that sorts out the breakage dimensions > to be expected Is this the problem where junitxml changes slightly in a new jenkins release and fixing it requires an update to the plugin? At this point users

Re: [pytest-dev] junitxml update

Hi Rusty, On Tue 14 Aug 2018 at 12:18 -0600, Rusty Howell wrote: > Hey all, > I am interested in working on junitxml. Great! It would really nice if the default support for junitxml would be up to scratch again. > Ronny mentioned in one of the bugs the idea of Pytest creating a serialized >

Re: [pytest-dev] PEP420, Namespace Packages and Pytest Test Layout

Hi Alexandre, On Thu 02 Aug 2018 at 16:45 +0200, Alexandre Figura wrote: > I recently discovered that it was possible to import test modules from > other test modules without having __init__.py files in my test > directories. I thought it was impossible to do so with Pytest. And > discovered it

Re: [pytest-dev] Partnership possibility with Pytest

Hi, On Mon 30 Jul 2018 at 23:14 -0700, Alex Georgie wrote: [...] > *How it works* > > We provide you a script that you add to the Pytest site. That script makes > a call to our site to create a 'drop' every 2 seconds a user is on your > site. If the user is part of our network, we would have

Re: [pytest-dev] Code of conduct for pytest organisation on GitHub

Hi, I'm agree that we should probably have a code of conduct. We had one for the sprint (we used https://www.python.org/psf/codeofconduct/ + 2 contact details for violations) and I'm surprised it stopped at the sprint. Probably an oversight. I just skimmed through C4 again and didn't spot much

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

On Fri 06 Jul 2018 at 12:13 -0300, Bruno Oliveira wrote: > 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 is > not working correctly either). Oh, this is sad. It's the only way I manage to vaguely

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] 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] 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] Adding plugins to pytest-dev

Hi Ringo, On Fri 20 Apr 2018 at 08:26 +0200, Ringo De Smet wrote: > If you want, I can get you bootstrapped on this Terraform setup. I can say > I almost know Terraform inside out. ;-) Thanks for the offer to help with the project! One downside I see with doing this is that it's a fair amount

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

On Thu 19 Apr 2018 at 16:50 -0500, Nicholas Williams wrote: > The tests work this way: > > - There's a test class that inherits from our specialized test class > (ServicePlanTestCase), which inherits from `unittest.TestCase` (for several > reasons, this detail cannot be altered) > - That test

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

Hi Nick, On Wed 18 Apr 2018 at 13:19 -0500, Nicholas Williams wrote: > Hello, all. This is my first post to the mailing list, FWIW. > > I've been a PyTest user for some years, but now I'm working on writing a > rather complex PyTest plugin to facilitate testing our service oriented >

Re: [pytest-dev] Adding plugins to pytest-dev

On Thu 19 Apr 2018 at 13:28 +0200, Ringo De Smet wrote: > Floris, > > Let me pass on how other communities manage Github teams, repositories and > shared maintenance. Here is the example from the Chef (config management > tool) community: > > https://github.com/sous-chefs/terraform-github-org > >

Re: [pytest-dev] new pytest-dev plugin proposal

Hi Davide, On Thu 19 Apr 2018 at 14:14 +0200, davide moro wrote: > 2018-04-17 22:22 GMT+02:00 Floris Bruynooghe <f...@devork.be>: >> On Thu 12 Apr 2018 at 10:57 +, Bruno Oliveira wrote: >> >> Talking before with Bruno we thought that the following one might be a >

Re: [pytest-dev] Unsubscribing from pytest-dev/pytest notifications

Hey Florian, On Mon 16 Apr 2018 at 07:50 +0200, Florian Bruhin wrote: > this is a difficult step to take, but during three sleepless nights > because of health issues last week (don't worry, it's getting better > now) I realized a lot of things (also see this thread on Twitter: [1]) Thanks for

[pytest-dev] Adding plugins to pytest-dev

Hi all, While just looking at https://github.com/pytest-dev/pytest/blob/master/CONTRIBUTING.rst#submitting-plugins-to-pytest-dev I had some observations: 1. It says one of the objectives of having plugins under pytest-dev is "Sharing some of the maintenance responsibility (in case a

Re: [pytest-dev] new pytest-dev plugin proposal

Hello, On Thu 12 Apr 2018 at 10:57 +, Bruno Oliveira wrote: > Hi Davide, > > +1 to both. > > Now we need another +1 from some other core dev to start the transferring > process. :) > > Cheers, > Bruno. > > On Thu, Apr 12, 2018 at 4:46 AM davide moro wrote: > >> Hi, >>

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

Hi Ronny, On Sun 08 Apr 2018 at 12:28 +0200, RonnyPfannschmidt wrote: > i wold like to get started with a long needed spring cleaning of things > that are unfixable stange/broken since dozens of years > > * removal of yield tests, ever since collection and test running are no > longer connected,

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

Hi Ronny, On Sun 08 Apr 2018 at 12:28 +0200, RonnyPfannschmidt wrote: > i wold like to get started with a long needed spring cleaning of things > that are unfixable stange/broken since dozens of years > > * removal of yield tests, ever since collection and test running are no > longer connected,

Re: [pytest-dev] Printing plugin help and skip tests

Hi Ringo, On Wed, Apr 04 2018, Ringo De Smet wrote: > I was thinking of implementing an option in my plugin, e.g. > `--show-our-superduper-help`. > This could go out to the server, fetch it's config and print the abilities > which can be used in the test suite for that server. > > I looked at how

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

On Fri, Mar 23 2018, Shawn Brown wrote: > The dual behavior was an implementation detail of the hacked experiment I > was playing with. My interest was in having something like > pytest_assertrepr_compare() but for single-values rather than just > comparisons. Cool, I think the equivalent of the

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

On Thu, Mar 22 2018, Shawn Brown wrote: > Would a return value helper--as you are thinking about it--be able to > handle cases like test_3passing()? > > def test_3passing(): > with pytest.raises(AssertionError) as excinfo: > assert myfunc(41) > assert 'custom

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

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 did deprecate markinfo attributes, >> > so everyone using them will get deprecation warni

Re: [pytest-dev] Fixture ordering and scopes

On Tue, Mar 20 2018, Bruno Oliveira wrote: > On Sat, Mar 17, 2018 at 6:38 PM Floris Bruynooghe <f...@devork.be> wrote: > >> >> I'm still not following this, I'm probably being silly. You have 4 >> autouse session-scoped fixtures but with a dependecy chain as >

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

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 aslo consistently use it (this fixed a few bugs pytest > dragged along since years) I've spent a while reading the PR but to

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

On Sun, Mar 18 2018, Shawn Brown wrote: > Unfortunately, this does not solve my usecase. I'm trying to handle cases > where the following statement would pass: > > assert myfunc(failing_input) == False > > But where this next statement would fail using my custom report: > > assert

Re: [pytest-dev] Parametrized autouse fixtures

Thomas De Schampheleire writes: > Hi, > > I now prepared the following PR for Kallithea to use these > parametrized fixtures: > https://bitbucket.org/conservancy/kallithea/pull-requests/389/tests-vcs-automatic-parametrization/diff > but I have a question: > > The

Re: [pytest-dev] Fixture ordering and scopes

Bruno Oliveira <nicodde...@gmail.com> writes: > On Fri, Mar 16, 2018 at 2:36 PM Floris Bruynooghe <f...@devork.be> wrote: > >> Bruno Oliveira <nicodde...@gmail.com> writes: >> >> > So the order is important here, and leaving it undefined w

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

Hi Shawn, Shawn Brown <03sjbr...@gmail.com> writes: > I understand how to use pytest_assertrepr_compare() to return custom > assertion reports--but this interface requires a comparison operator. I'm > hoping to write a plugin that makes custom reports for statements like: > > assert

Re: [pytest-dev] pytest-commit emails

Bruno Oliveira writes: > Oh OK, thanks Floris. > > Weird, I don't receive emails from Ronny it seems, he merged some PRs this > week but I didn't receive anything. Neither did I... ___ pytest-dev mailing list

Re: [pytest-dev] License for pytest-dev/pytest-design

Bruno Oliveira writes: > Hi folks, > > pytest-design is the repository used to store logo and t-shirt designs from > our 2016 sprint, but it currently it isn't under any LICENSE. Whoops, that's pretty terrible! > I've been > asked if it was OK to use the logos to make a

Re: [pytest-dev] pytest-commit emails

Bruno Oliveira <nicodde...@gmail.com> writes: > On Fri, Mar 16, 2018 at 5:23 AM Floris Bruynooghe <f...@devork.be> wrote: > >> Bruno Oliveira <nicodde...@gmail.com> writes: >> >> > Hi everyone, >> > >> > I receive an em

Re: [pytest-dev] Fixture ordering and scopes

Bruno Oliveira <nicodde...@gmail.com> writes: > > On Fri, Mar 16, 2018 at 5:42 AM Floris Bruynooghe <f...@devork.be> wrote: > >> Bruno Oliveira <nicodde...@gmail.com> writes: >> > For example suppose you have two session scoped fixtures from different >

Re: [pytest-dev] Fixture ordering and scopes

Brian Okken writes: > I get numerous questions about it, and I always tell people to create > artificial dependencies between fixtures that need to run in a certain > order. I'm not sure I follow why you consider them to be *artificial* dependencies. If a

Re: [pytest-dev] pytest-commit emails

Bruno Oliveira writes: > Hi everyone, > > I receive an email from pytest-com...@python.org whenever new merges happen > on a branch of the pytest repository, but it seems it happens only for my > own merges. It was my understanding I should receive for any merge, not > just

[pytest-dev] Adding intro talk/slides to pytest-dev repos and licensing

Hi all, Ronny was interested in updating/adapting a pytest-intro talk I've given at a meetup sometime before [0]. He suggested to add it in a repo under the pytest-dev organisation, which seems like a fine idea. Why not all re-use slides if they're useful. However this also raises the question

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

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

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] 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] 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] 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] 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] [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] [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

[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] 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

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

  1   2   >