Re: [pytest-dev] Not running standard pytest collector for file spec/*_spec.py

Hi Ringo, On Tue, Mar 13, 2018 at 4:40 AM Ringo De Smet <ringo.de.s...@ontoforce.com> wrote: > Ronny, Bruno, > > On Mon, Mar 12, 2018 at 8:10 PM, Bruno Oliveira <nicodde...@gmail.com> > wrote: > >> Hi Ringo, >> >> It is as Ronny said, you can see th

Re: [pytest-dev] Not running standard pytest collector for file spec/*_spec.py

Hi Ringo, It is as Ronny said, you can see the code responsible for that here: https://github.com/pytest-dev/pytest/blob/master/_pytest/python.py#L162 When the file has a `.py` extension and is one of the "inipaths" (paths given explicitly in the command line), then the `python` plugin will

[pytest-dev] Use fixtures for parametrization discussion

Hi everyone, A coworker has once again asked me the age old question "how can I use a fixture to parametrize a test?" and this motivated me to write https://github.com/pytest-dev/pytest/issues/3244 in order to find a solution to this. It would be great if people can participate in that

[pytest-dev] pytest 3.4.1 released

: * Aaron * Alan Velasco * Andy Freeland * Brian Maissy * Bruno Oliveira * Florian Bruhin * Jason R. Coombs * Marcin Bachry * Pedro Algarvio * Ronny Pfannschmidt Happy testing, The pytest Development Team ___ pytest-dev mailing list pytest-dev@python.org https

[pytest-dev] pytest 3.4.0 released!

to this release, among them: * Aaron * Alan Velasco * Anders Hovmöller * Andrew Toolan * Anthony Sottile * Aron Coyle * Brian Maissy * Bruno Oliveira * Cyrus Maden * Florian Bruhin * Henk-Jaap Wagenaar * Ian Lesperance * Jon Dufresne * Jurko Gospodnetić * Kate * Kimberly * Per A. Brodtkorb * Pierre

[pytest-dev] Alias to parametrize

Hi all, 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 reduces consistency across test suites. I'm sending an

Re: [pytest-dev] codespeak.net down

On Sun, Jan 21, 2018 at 3:58 AM holger krekel <hol...@merlinux.eu> wrote: > Hi Bruno, > > On Sat, Jan 20, 2018 at 15:51 +, Bruno Oliveira wrote: > > Hi everyone, > > > > From https://github.com/pytest-dev/pytest-xdist/issues/258, > codespeak.net > &

[pytest-dev] codespeak.net down

Hi everyone, >From https://github.com/pytest-dev/pytest-xdist/issues/258, codespeak.net is down. Can anybody with access bring it back up? Alternatively we might consider moving its documentation to ReadTheDocs. Cheers, Bruno. ___ pytest-dev mailing

Re: [pytest-dev] Custom test collection with fixtures

Hi Sterling, Looking at pytest’s code , it seems it also needs a fixtureinfo object: yield Function(name, parent=self, fixtureinfo=fixtureinfo) This feels a little more complicate than it should to me, but I guess that’s

Re: [pytest-dev] Parametrizing dependent fixtures

Hi Edgar, On Mon, Jan 8, 2018 at 10:32 AM Edgar Ostrowski wrote: > Anyway I would like to confirm that this is valid way of using the > parametrize marker. > I did not look at the video yet, but fixture parametrization only works by using @pytest.fixture(params=...).

Re: [pytest-dev] Proposal: Move adamchainz/pytest-randomly to pytest-dev/pytest-randomly

+1 here too! :) Adam, please transfer the repository to me and I will complete the transfer! []s, On Sat, Dec 16, 2017 at 8:55 AM Florian Bruhin wrote: > Hey, > > (Yay, someone else with a me@ address!) > > On Sat, Dec 16, 2017 at 05:56:18AM +, Adam Johnson wrote: >

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

Sounds good, thanks. On Fri, Dec 8, 2017 at 5:52 PM Ronny Pfannschmidt < opensou...@ronnypfannschmidt.de> wrote: > 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, 1

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

Howdy Ronny, On Fri, Dec 8, 2017 at 2:36 PM Ronny Pfannschmidt < opensou...@ronnypfannschmidt.de> wrote: > 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,

[pytest-dev] pytest 3.3.1 released!

them: * Bruno Oliveira * Daniel Hahler * Eugene Prikazchikov * Florian Bruhin * Roland Puntaier * Ronny Pfannschmidt * Sebastian Rahlf * Tom Viner Happy testing, The pytest Development Team ___ pytest-dev mailing list pytest-dev@python.org https

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

Hi Keith, Both approaches are valid and identical; I personally prefer using yield because to me it feels more natural. Cheers, On Mon, Dec 4, 2017 at 9:49 AM Dr Keith M Franklin wrote: > > Good morning/afternoon, > > I hope this is the right place to post this.

Re: [pytest-dev] Proposal: Move davehunt/pytest-metadata to pytest-dev/metadata

Dave, All done, let me know if anything is amiss! Cheers On Mon, Dec 4, 2017 at 7:44 AM Dave Hunt <dh...@mozilla.com> wrote: > Thanks everyone! Bruno, I’ve initiated the transfer. > > Dave > > > On 1 Dec 2017, at 18:11, Bruno Oliveira <nicodde...@gmail.com> wro

Re: [pytest-dev] Proposal: Move davehunt/pytest-metadata to pytest-dev/metadata

Great, thanks everyone! Dave, feel free to transfer to me when you have the chance and I will follow with the procedure. :) On Fri, Dec 1, 2017 at 2:32 PM Florian Bruhin wrote: > On Fri, Dec 01, 2017 at 10:06:51AM -0300, Ana Ribeiro wrote: > > I don't know if my +1 means

Re: [pytest-dev] Proposal: Move davehunt/pytest-metadata to pytest-dev/metadata

On Thu, Nov 30, 2017 at 2:16 PM Dave Hunt wrote: > I’d like to propose moving the pytest-metadata plugin to pytest-dev. > Definitely +1! Cheers, Bruno. It’s a dependency for pytest-html, which is already in the pytest-dev > organisation, so I believe this makes sense. I

Re: [pytest-dev] Blog down?

pendency fix helps and submit a PR. > > You should also see this when locally testing via > > make clean && make html && make serve > > > Best, > > Maik. > > On 29.11.2017 20:38, Bruno Oliveira wrote: > > Thanks Florian! > > The site is ba

Re: [pytest-dev] Blog down?

Thanks Florian! The site is back up, but the layout looks incorrect to me (seems it's rendering without CSS). Anybody else seeing this? Cheers, On Wed, Nov 29, 2017 at 5:34 PM Floris Bruynooghe wrote: > "Florian Schulze" writes: > > > The missing

[pytest-dev] Blog down?

Hi everyone, Just realized that the blog seems to be down (http://blog.pytest.org/). Who can verify what's happening? Cheers, Bruno. ___ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] pytest 3.3.0

at the CHANGELOG: http://doc.pytest.org/en/latest/changelog.html For complete documentation, please visit: http://docs.pytest.org As usual, you can upgrade from pypi via: pip install -U pytest Thanks to all who contributed to this release, among them: * Anthony Sottile * Bruno

[pytest-dev] pytest 3.2.5 hot-fix released

pytest 3.2.5 has just been released to PyPI. This is a hot-fix release: pytest-3.2.4 imposed a restriction of "py<1.5" because py-1.5.0 has dropped py26 and py33 support, but this can cause problems on some installations due to pip's dependency resolver. For more details see this issue:

[pytest-dev] pytest 3.2.4 released!

: * Bruno Oliveira * Christian Boelsen * Christoph Buchner * Daw-Ran Liou * Florian Bruhin * Franck Michea * Leonard Lausen * Matty G * Owen Tuz * Pavel Karateev * Pierre GIRAUD * Ronny Pfannschmidt * Stephen Finucane * Sviatoslav Abakumov * Thomas Hisch * Tom Dalton * Xuan Luong * Yorgos Pagles * Семён

Re: [pytest-dev] proposal - type-keyed storage for extension objects/metadata in config/items

Hi Ronny, Can you provide a use case for this storage? Perhaps we can use existing cases and see how they would like with the new API. For example, pytest-html currently attaches an "extra" dictionary to items. How could pytest-html make use of the new API? Another example is the core junitxml

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

On Wed, Oct 25, 2017 at 6:01 PM Floris Bruynooghe wrote: > > as such i propose deprecating them and warning users about the problems > > with regard to when and how to warn we need to take a look in detail as > > there are many reasonably valid setups with exactly one non initial

[pytest-dev] Pytest 3.2.3 released

, among them: * Bruno Oliveira * Evan * Joe Hamman * Oliver Bestwalter * Ronny Pfannschmidt * Xuan Luong Happy testing, The pytest Development Team ___ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] pytest 3.2.2 released

them: * Andreas Pelme * Antonio Hidalgo * Bruno Oliveira * Felipe Dau * Fernando Macedo * Jesús Espino * Joan Massich * Joe Talbott * Kirill Pinchuk * Ronny Pfannschmidt * Xuan Luong Happy testing, The pytest Development Team ___ pytest-dev mailing

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

Hi guys, Sorry for not answering earlier. On Sun, Aug 27, 2017 at 4:04 AM Ronny Pfannschmidt < opensou...@ronnypfannschmidt.de> wrote: > 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

Re: [pytest-dev] [proposal] deprecate magic constant scopes in favour of the node types

Hi Ronny, On Tue, Aug 29, 2017 at 4:48 AM RonnyPfannschmidt < opensou...@ronnypfannschmidt.de> wrote: > Hi all, > > since quite a while now we have used magic constants for scope names, > while we have something perfectly fitting already at hand - namely the > Node classes we actually use and

Re: [pytest-dev] Documentation proposal

using pytest-bdd/splinter/Xvfb > on Windows and OSX), but I am still in recovery mode from the conference > itself so it will take me a little longer to write that up. > > cheers > Brianna > > > On 8 August 2017 at 02:07, Bruno Oliveira <nicodde...@gmail.com> wro

[pytest-dev] pytest 3.2.1 released

Gaynor * Bruno Oliveira * Florian Bruhin * Ronny Pfannschmidt * Srinivas Reddy Thatiparthy Happy testing, The pytest Development Team ___ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Documentation proposal

Hi Daniele, Thanks a lot for following up on this! I've pushed your branch up to pytest's repository and enabled building it on RTD so people can more easily take a look at it: https://docs.pytest.org/en/documentation-restructure/ I did a quick glance and I like what I see so far. Having

[pytest-dev] pytest 3.2.0 released

* Bruno Oliveira * Daniel Hahler * Florian Bruhin * Floris Bruynooghe * John Still * Jordan Moldow * Kale Kundert * Lawrence Mitchell * Llandy Riveron Del Risco * Maik Figura * Martin Altmayer * Mihai Capotă * Nathaniel Waisbrot * Nguyễn Hồng Quân * Pauli Virtanen * Raphael Pierzina * Ronny

Re: [pytest-dev] Help testing 3.2.0 release (part 2)

On Mon, Jul 31, 2017 at 10:40 AM Florian Schulze wrote: > > I had to do: > > > > pip install --no-cache-dir -U > > > https://devpi.net/nicoddemus/dev/+f/e50/b5a054e0007ca/pytest-3.2.0-py2.py3-none-any.whl > > This works with devpi tests as well. > Thanks Florian!

Re: [pytest-dev] Help testing 3.2.0 release (part 2)

On Mon, Jul 31, 2017 at 8:44 AM Florian Bruhin wrote: > Thanks! Seems to work fine with qutebrowser this time :) > Glad to know, thanks! > > > The package is available at: > > > > https://devpi.net/nicoddemus/dev/pytest/3.2.0 > > > > And can be installed with: > > >

[pytest-dev] Help testing 3.2.0 release (part 2)

Hi everyone, I have prepared another package for the 3.2.0 release and again it would be great if people could help test it. The package is available at: https://devpi.net/nicoddemus/dev/pytest/3.2.0 And can be installed with: pip install -U

Re: [pytest-dev] xdist: removing boxed with degraded backward compat

> > Am 28.07.2017 um 17:59 schrieb Bruno Oliveira: > > Hey Ronny, > > > > Does this new "pytest-boxed"(?) plugin depends on pytest-xdist? If it > > does I think it is just a matter of pinning that dependency as requiring > > a minimum of pytest-xdist &

Re: [pytest-dev] How to deal with setup.py/setup.cfg ?

Hi Bastien, I suggest to try to use the `testpaths`[1] option instead, which is tailored for just that purpose. Cheers, Bruno [1] https://docs.pytest.org/en/latest/customize.html?highlight=testpath#confval-testpaths On Wed, Jul 19, 2017 at 11:02 AM Bastien Sevajol

Re: [pytest-dev] Help testing 3.2.0 release

On Fri, Jul 14, 2017 at 10:34 AM Oliver Bestwalter wrote: > Hi Bruno, > > I tried to install it into an existing Python 3.6 virtualenv and it > stumbled over setuptools - running it again in the same env worked then. I > pasted the call and a pip freeze here in case it is

Re: [pytest-dev] Help testing 3.2.0 release

On Fri, Jul 14, 2017 at 10:02 AM Florian Schulze <florian.schu...@gmx.net> wrote: > On 14 Jul 2017, at 14:04, Bruno Oliveira wrote: > > > But the __multicall__ warning was not added to 3.2, it has been in > > place > > since 2015. Are you seeing this warning jus

Re: [pytest-dev] Help testing 3.2.0 release

ed. An example diff is > often enough. > > Regards, > Florian Schulze > > On 14 Jul 2017, at 0:45, Bruno Oliveira wrote: > > Hi everyone, > > I have prepared a package for the 3.2.0 release and it would be great if > people could help test it. > > The package i

Re: [pytest-dev] Help testing 3.2.0 release

On Thu, Jul 13, 2017 at 7:45 PM Bruno Oliveira <nicodde...@gmail.com> wrote: > I have prepared a package for the 3.2.0 release and it would be great if > people could help test it. > To take a look at the changes, please take a look at the CHANGELOG on the release branch: htt

[pytest-dev] Help testing 3.2.0 release

Hi everyone, I have prepared a package for the 3.2.0 release and it would be great if people could help test it. The package is available at: https://devpi.net/nicoddemus/dev/pytest/3.2.0 And can be installed with: pip install -U

Re: [pytest-dev] Deprecation Roadmap Wiki

a fashion that allows us to cancel bad > things instead of keeping them "forever" > > -- Ronny > > Am 10.07.2017 um 18:30 schrieb Bruno Oliveira: > > Hey Tyler, > > Hmmm my initial gut feeling is to keep them separate. > > Also I'm not sure if it makes sense for pl

Re: [pytest-dev] Deprecation Roadmap Wiki

Hey Tyler, Hmmm my initial gut feeling is to keep them separate. Also I'm not sure if it makes sense for pluggy given that it is not even in 1.0 yet. What do others think? Cheers, Bruno. On Mon, Jul 10, 2017 at 12:34 PM Tyler Goodlet wrote: > Hey Bruno, > > Is it ok if I

[pytest-dev] Deprecation Roadmap Wiki

Hi everyone, I just created a page to track deprecations in our wiki: https://github.com/pytest-dev/pytest/wiki/Deprecation-Roadmap The idea is to make it clear for ourselves when we intend to remove certain features. Cheers, Bruno. ___ pytest-dev

Re: [pytest-dev] removing py.path.svn* - since its unmaintained and broken since years

s why i'd like to remove it > > Am 24.06.2017 um 21:38 schrieb Bruno Oliveira: > > Giving that, we could just announce that it is unsupported, leave all > > tests out (or mark them as xfail). > > > > I agree that there's no point having it around if it is giving us >

Re: [pytest-dev] removing py.path.svn* - since its unmaintained and broken since years

RonnyPfannschmidt < opensou...@ronnypfannschmidt.de> wrote: > its dead code nobody wants to fix, as such its about the same as a > unpaid debt incurring interests > > Am 24.06.2017 um 20:27 schrieb Bruno Oliveira: > > Is it giving maintenance problems? > > >

Re: [pytest-dev] removing py.path.svn* - since its unmaintained and broken since years

Is it giving maintenance problems? On Sat, Jun 24, 2017 at 3:26 PM RonnyPfannschmidt < opensou...@ronnypfannschmidt.de> wrote: > hi all, > > i'd like to remove that code - its broken since years and im not aware > of anyone wanting to fix/maintain it > as it is now a deadweight i'd like to see

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

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 removing/changing them. > That has happened several times and i think it's a good

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

'd make it easier for new contributors. > > Regards, > Floris > > On 6 Dec 2016 11:16, "Bruno Oliveira" <nicodde...@gmail.com> wrote: > > Oh good point Raphael. > > Here's the link for the discussion about pip dropping Python 2.6: > https://github.com/py

Re: [pytest-dev] want to work in #2206

Hi Rajib, Sure, thanks for your interest in tackling this! Ronny asked to be contacted about this in #2206; since he is the OP of that issue I suspect he has some general idea of which areas to focus on. Cheers, Bruno. On Tue, Jun 20, 2017 at 7:16 AM Rajib Mitra wrote:

[pytest-dev] pytest 3.1.2

: * Andreas Pelme * ApaDoctor * Bruno Oliveira * Florian Bruhin * Ronny Pfannschmidt * Segev Finer Happy testing, The pytest Development Team ___ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] pytest.org redirect request (#2453)

Hi everyone, An issue has been raised in the bug tracker asking to redirect docs.pytest.org/latest/* to docs.pytest.org/en/latest/*: https://github.com/pytest-dev/pytest/issues/2453 Whoever has powers to that change the redirect rules could take a look please? Thanks! Cheers, Bruno.

[pytest-dev] pytest 3.1.1 released!

: * Bruno Oliveira * Florian Bruhin * Floris Bruynooghe * Jason R. Coombs * Ronny Pfannschmidt * wanghui Happy testing, The pytest Development Team ___ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev

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

On Tue, May 30, 2017 at 6:41 AM RonnyPfannschmidt < opensou...@ronnypfannschmidt.de> wrote: > > > I'd still be in favour of turning them on by default, if that's possible > > without clashing with existing filters. I don't think it's the job of > > libraries to modify warning filters - they

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

need to install a custom filter but we are not sure which filter to install at the moment. Thoughts? Bruno. On Mon, May 29, 2017 at 9:20 AM Bruno Oliveira <nicodde...@gmail.com> wrote: > Thanks everyone. > > If it is alright then, I will prepare a 3.2.0 release later today. >

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

s fine to mark 3.1 as botched > > we should have a proper discussion about feature lifetimes in future, > just deprecation is simply not enough - and it seems we repeat mishaps > around releasing "complete" features > -- Ronny > > Am 29.05.2017 um 14:06 schrieb Bruno Oliv

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

Hi Floris and Brian, thanks for joining. On Mon, May 29, 2017 at 8:44 AM Floris Bruynooghe wrote: > 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.

[pytest-dev] pytest 3.1 warning capture woes

Hi everyone, Unfortunately pytest's 3.1 warning capture being active by default has caused grief on some test suites and there's been a lengthy discussion about it on this thread: https://github.com/pytest-dev/pytest/issues/2430 I'm pointing this out here so others can join the discussion and

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

On Tue, May 23, 2017 at 1:18 PM RonnyPfannschmidt < opensou...@ronnypfannschmidt.de> wrote: > https://github.com/pytest-dev/pytest/issues/2430 is a perfect example of > why we need *more* and *faster* feedback > > we keep doing things like that and i think we should reexamine on how we > want to

[pytest-dev] pytest 3.1.0 has been released!

* Bruno Oliveira * David Giese * David Szotten * Dmitri Pribysh * Florian Bruhin * Florian Schulze * Floris Bruynooghe * John Towler * Jonas Obrist * Katerina Koukiou * Kodi Arfer * Krzysztof Szularz * Lev Maximov * Loïc Estève * Luke Murphy * Manuel Krebber * Matthew Duck * Matthias Bussonnier

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

On Thu, May 18, 2017 at 2:25 PM Floris Bruynooghe wrote: > > My main objection was purely on the fact that we basically disobey the > deprecation policy right after introducing it by doing this. Hmm you are right, I think this is the central point: introducing this change is

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

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, are you guys OK with that? I'm fine either way. Bruno

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

On Thu, May 18, 2017 at 1:13 AM Ronny Pfannschmidt wrote: > I'd prefer if we do not undo the change. > Do you mean the change to the TerminalRepr in 3.0.5, or the complete PR which changes all classes to new style classes? Bruno

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

On Wed, May 17, 2017 at 2:18 PM Floris Bruynooghe wrote: > 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 That's true, we won't

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

On Tue, May 16, 2017 at 4:31 PM Brian Okken wrote: > I don't get the "broke the API" part of this issue. > What used to work and doesn't now? > We changed all classes to new-style classes in order to remove the subtle differences between old style and new style, which

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

Hi everyone, On Fri, May 12, 2017 at 7:03 PM Ronny Pfannschmidt < opensou...@ronnypfannschmidt.de> wrote: > 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 >

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

On Tue, May 16, 2017 at 10:56 AM Ronny Pfannschmidt < opensou...@ronnypfannschmidt.de> wrote: > Hi, > > i'd like to move execnet under pytest-dev on github, > > +1, definitely. Thanks Ronny! []s, ___ pytest-dev mailing list pytest-dev@python.org

Re: [pytest-dev] Remove AUTHORS file?

Hi everyone, On Thu, May 4, 2017 at 2:47 PM Bruno Oliveira <nicodde...@gmail.com> wrote: > On Thu, May 4, 2017 at 2:42 PM Florian Bruhin <m...@the-compiler.org> wrote: > >> On Thu, May 04, 2017 at 02:24:36PM +, Bruno Oliveira wrote: >> > In light o

Re: [pytest-dev] Remove AUTHORS file?

On Thu, May 4, 2017 at 2:42 PM Florian Bruhin <m...@the-compiler.org> wrote: > On Thu, May 04, 2017 at 02:24:36PM +0000, Bruno Oliveira wrote: > > In light of that, I propose to change it so it is generated automatically > > from git, would that be acceptable? >

Re: [pytest-dev] Remove AUTHORS file?

On Thu, May 4, 2017 at 11:07 AM Floris Bruynooghe wrote: > What's nice is that AUTHORS is just an alphabetical list of people while > the github page ranks people implicitly by some random metric. It's > also possible for packagers to install this file, currently Debian does >

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

For reference: https://github.com/pytest-dev/pytest/issues/2390 On Tue, Mar 28, 2017 at 3:45 AM Floris Bruynooghe wrote: > 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" < >

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

Hi guys, On Fri, Apr 7, 2017 at 4:31 PM Bruno Oliveira <nicodde...@gmail.com> wrote: > > On Thu, Apr 6, 2017 at 3:30 AM holger krekel <hol...@merlinux.eu> wrote: > >> >> I am fine to have user-tests guide the decision ... so now for me it's >> only between

Re: [pytest-dev] Help available

Hi Robert, On Tue, Apr 25, 2017 at 5:03 AM Robert Kuska wrote: > my employer (kiwi.com) decided to hire a bunch of interns to work on > open source projects we actively use in our company. Each intern has its > own mentor and each mentor picks his open source projects he wants

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

On Mon, Apr 17, 2017 at 3:49 PM Ronny Pfannschmidt < opensou...@ronnypfannschmidt.de> wrote: > > On 14.04.2017 14:17, Florian Bruhin wrote: > > On Thu, Apr 13, 2017 at 05:51:34PM +0000, Bruno Oliveira wrote: > >> What if we instead of considering features, we rel

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

On Thu, Apr 13, 2017 at 1:35 PM Florian Bruhin wrote: > Hi, > > On Thu, Apr 13, 2017 at 06:25:22PM +0200, Ronny Pfannschmidt wrote: > > since quite a while now we keep a lot of code away from users by leaving > > it in the features branch, > > more recent detail

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

Hi Holger, everyone, On Thu, Apr 6, 2017 at 3:30 AM holger krekel wrote: > > I am fine to have user-tests guide the decision ... so now for me it's > only between offering a context manager or offering a special > "NoExceptionRaised" object which you can give to

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

Hi Walter! On Wed, Apr 5, 2017 at 7:00 PM Oliver Bestwalter wrote: > ... and this would be a bit harder to understand, because as Bruno found > out already, there are quite different expectations about what is supposed > to happen if I write pytest.raises(None). > > Am I

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

of pytest.raises(None) would be obvious, but it seems that's not the case (at least in my small poll of around the office). Given all that I'm now leaning towards going through the safe route of being more explicit albeit more verbose. What do others think? Cheers, Bruno. > > holger > &g

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

On Fri, Mar 31, 2017 at 8:24 AM Bruno Oliveira <nicodde...@gmail.com> wrote: > Hi all, > > On Fri, Mar 31, 2017 at 7:13 AM Vasily Kuznetsov <kvas...@gmail.com> > wrote: > > Hi Holger and Ronny, > > I see merit in both of your points. All those "is

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

On Thu, Mar 30, 2017 at 4:32 PM holger krekel wrote: > It's a bit odd to introduce a new helper just for this particular case. > After skimming https://github.com/pytest-dev/pytest/issues/1830 > i'd prefer the mentioned pytest.raises(None) solution which lets through > all

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

Hi all, We are about to land on the features branch an implementation of the proposal outlined by Florian Bruhin ( https://github.com/pytest-dev/pytest/issues/1830) where we introduce a small helper to facilitate writing parametrized tests that sometimes raise an error for an input parameter and

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

Sounds good! On Wed, Mar 29, 2017 at 12:27 PM Ronny Pfannschmidt < opensou...@ronnypfannschmidt.de> wrote: > +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 >

Re: [pytest-dev] Mozilla Open Source Support

Hi all, Has any work on creating a "pytest" like organization moved forward? That would be great in terms of making it easy to get sponsorship from any number of means. Cheers, Bruno. On Mon, Feb 27, 2017 at 6:43 AM Thomas Lotze wrote: > Hi Raphael, > > thank you for

[pytest-dev] Travis auto-cancellation enabled

Hi everyone, Travis introduced "auto-cancellation", meaning that if a new commit is pushed to a branch or PR, any queued builds for the previous commit in that branch or PR is cancelled automatically. I think this is a great idea as it avoids building older commits which are probably no longer

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

line > > -- Ronny > > On 21.03.2017 16:32, Bruno Oliveira wrote: > > Hey Ronny, > > Oh you are absolutely right. > > Do you know what happens with the old CHANGELOG entries btw? > > Cheers, > > On Tue, Mar 21, 2017 at 12:29 PM Ronny Pfannschmidt < > opensou..

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

right after 3.1 > > after all the before bits are already in place > > -- Ronny > > On 21.03.2017 14:41, Bruno Oliveira wrote: > > Hi Ronny, > > > > I definitely like the idea! I agree our current CHANGELOG maintenance > > could use some improvement. :) &

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

Hi Ronny, I definitely like the idea! I agree our current CHANGELOG maintenance could use some improvement. :) We could introduce it for `3.1`, what do you think? On Tue, Mar 21, 2017 at 5:54 AM Ronny Pfannschmidt < opensou...@ronnypfannschmidt.de> wrote: > Hi all, > > today i noticed how pip

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

Hi, While this kind of change is a little disruptive regarding history and might generate conflicts in PRs, it is the kind of change that is a little pain for a short time but brings tangible benefits in the long term, so I'm +1 on the idea. An idea: when doing something similar at work

Re: [pytest-dev] Sprint this summer?

On Wed, Mar 15, 2017 at 10:16 AM Oliver Bestwalter wrote: > just want to get the ball rolling and ask if planning has started already > and how I can help. > AFAIK there's no planning yet. I imagine that managing a sprint is quite some work as Holger can attest to, so it

Re: [pytest-dev] Google Summer of Code

Hi Walter, :) On Fri, Feb 10, 2017 at 11:52 AM Oliver Bestwalter wrote: > If students want to work explicitly on tox and someone wants to mentor I > would suggest: > > Generalize package builds and virtualenv creation: > https://github.com/tox-dev/tox/issues/338 > > as an

Re: [pytest-dev] Google Summer of Code

On Wed, Feb 8, 2017 at 1:47 AM Ana Ribeiro wrote: > Sorry, wrong link. This one is the correct one: > https://github.com/pytest-dev/pytest/wiki/GSoC-2017 > Thanks Ana. I updated the item 1 with difficulty level and added myself as possible mentor, but others please

Re: [pytest-dev] Google Summer of Code

t is a good way. > > About how to apply as a suborg of python, I may ask them on IRC and come > here with more information. > > Best regards, > Ana > > 2017-01-25 8:04 GMT-03:00 Florian Bruhin <m...@the-compiler.org>: > > * Bruno Oliveira <nicodde...@gmail.com

Re: [pytest-dev] Google Summer of Code

On Wed, Jan 25, 2017 at 9:04 AM Florian Bruhin <m...@the-compiler.org> wrote: > * Bruno Oliveira <nicodde...@gmail.com> [2017-01-25 10:27:09 +]: > > I did, and it's in the archive too: > https://mail.python.org/pipermail/pytest-dev/2017-January/003985.html Th

Re: [pytest-dev] Google Summer of Code

On Wed, Jan 25, 2017 at 6:47 AM holger krekel wrote: > I'll leave the question of if/how to apply as org/suborg to others > as i am not bound to mentor myself (see my other post). > Which post do you mean Holger? I didn't receive any other reply from you to this thread.

Re: [pytest-dev] Google Summer of Code

lt;dh...@mozilla.com>: > > This is a great idea! I blogged about my experiences with mentoring last > year at > http://davehunt.co.uk/mozilla/2016/09/26/lessons-from-mentoring.html and > I’m happy to answer any questions. > > On 20 Jan 2017, at 12:49, Bruno Oliveira <nicodde.

Re: [pytest-dev] Google Summer of Code

Hi Ana, I think that is a great idea, thanks for bringing this to attention of the group! I did take a quick look at the site, and for those who don’t know (myself included) what it means for us (as Pytest organization), here’s an excerpt from their overview

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

On Tue, Dec 6, 2016 at 9:52 AM Floris Bruynooghe wrote: > > As an aside, if we're happy to introduce more libraries then maybe we > should also consider the standard six package instead of doing our own > stuff, mostly because I'd make it easier for new contributors. > I had

<    1   2   3   4   5   >