Re: [pytest-dev] pytest pre-sprint

[Oliver Bestwalter]

Hi,

thanks Florian - that sounds great. I would also appreciate that on the
first sprint day. I will be arriving on the 19th in the afternoon. I a
started working my way into the code base of pytest but I am also very
interested in working on tox.

Cheers
Oliver

On Wed, 1 Jun 2016 at 14:18 holger krekel  wrote:

> On Wed, Jun 01, 2016 at 11:44 +, Bruno Oliveira wrote:
> > On Wed, Jun 1, 2016 at 8:33 AM Steffen Allner  wrote:
> >
> > >
> > > If it does not fit to the schedule in advance and as we are some number
> > > of people with less experience to pytest, it is maybe even usefull if
> we
> > > do something on the first day with the interested part of the
> > > participants.
> > >
> >
> > Good idea. I suppose after a kick-off where we bring up and discuss
> various
> > topics to work on and then split in groups, this might be one of the
> > groups. I suppose it would be brief though.
> >
> > Btw, is there already a loose schedule for the week or will we decide
> > > everything on ground?
> > >
> >
> > I'm not sure, I think Holger might have an idea for that already.
> >
> > When do we reasonably meet then?
> >
> >
> > Good question. 9am to 5pm, with a pub afterwards? :)
>
> Monday-saturday 9am till 6pm is the basic timing with a large lunch
> break each day.  At least one afternoon i suggest going around hiking or
> other outdoor activities.  I guess this will be on wednesday but i'd also
> make it dependent on weather.
>
> holger
>
>
>
>
> > Cheers,
> > Bruno.
>
> > ___
> > pytest-dev mailing list
> > pytest-dev@python.org
> > https://mail.python.org/mailman/listinfo/pytest-dev
>
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] Participation in 2016 Sprint

[Oliver Bestwalter]

Hello,

I would like to participate in the sprint and I won't need any funding.

My name is Oliver Bestwalter and I live in Ravensburg near Lake Constance.
I fell in love with Python in 2006 and work at Avira since 2011. I am part
of a small team that is automating internal build, test and release
processes with Python. We are responsible for the complete life cycle of
our systems including testing, provisioning and deploying them on Linux,
Windows and Mac, so my job description according to the latest buzzwords
would be DevOps I guess.

I am using py.test in all my pet projects and professionally since 2011.
Last year I started using devpi and tox also. I have no experience working
on the code bases yet.

cheers
Oliver
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Participation in 2016 Sprint

[Oliver Bestwalter]

Hello Floris,

thanks for the warm welcome. I already started questioning my own sanity a
bit after making that gut decision that I want to participate, because to
spend a whole week on a sprint for a project I am not actively involved in
yet seems a bit ... weird. But the point is: I really appreciate the whole
pytest/tox/devpi toolchain and the ideas behind it, so I'll have go at
making myself useful while having some fun and learning from the jedi
masters of testing :)

cheers
Oliver

On Sat, 20 Feb 2016 at 15:30 Floris Bruynooghe <f...@devork.be> wrote:

> Hi Oliver,
>
> On 17 February 2016 at 11:08, Oliver Bestwalter <oli...@bestwalter.de>
> wrote:
> > I would like to participate in the sprint and I won't need any funding.
>
> Great that you want to join us!
>
> > I am using py.test in all my pet projects and professionally since 2011.
> > Last year I started using devpi and tox also. I have no experience
> working
> > on the code bases yet.
>
> No worries, it will be a great opportunity to get into the code and
> help will be at hand.
>
> We don't know an exact location yet or where we'll be staying, so keep
> an eye out on the list for more details to start appearing.  I look
> forward to meeting you in Freiburg!
>
> Floris
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Postpone 3.0?

[Oliver Bestwalter]

Hi all,

I just opened a PR adding the docs about our backwards compatibility
policy: https://github.com/pytest-dev/pytest/pull/1736

With that PR all necessary elements are in place as discussed (internal
pytest warnings on by default, possibility to silence these warnings,
documentation explaining the policy).

I created it against the features branch as I am not sure if the
documentation restructuring will make it into 3.0

Cheers
Oliver

On Fri, 15 Jul 2016 at 18:06 Florian Bruhin  wrote:

> * Floris Bruynooghe  [2016-07-15 15:29:18 +0100]:
> > On 14 July 2016 at 23:45, Brianna Laugher 
> wrote:
> > > It's mainly Floris, Oliver and me that are the hold up right? Removing
> > > reinterpret assert and 2x docs.
> >
> > Reinterpret is now removed as of this morning!  I should do one more
> > PR with some doc updates.  Is that fine to do against current docs in
> > the repo for the doc-reorg?
> >
> > The milestone (https://github.com/pytest-dev/pytest/milestone/2) has a
> > lot of things still outstanding.  I'm happy to postpone, we could aim
> > for the end of the EuroPython sprints?  (although I won't be around
> > for that weekend)  Or maybe a week later even as sprints probably
> > introduce some instability.  So I'd say aim for 1st August maybe?
>
> I think I've mentioned it in the past: We should postpone anything
> which is not a breaking change to 3.1, we have more than enough
> awesome stuff for 3.0 already.
>
> I think nobody took a look at the issues - we have simple feature
> proposals from 2012 in there, sho, should they really block 3.0?
>
> Ronny, things like "Support for Python 3.4 unittest subtests" or "drop
> argparse" are marked as "critical" (mostly by you) - what's so
> critical about them? To me, critical would imply we can under no
> circumstances release 3.0 without that. "pytest deletes my project
> files" would be critical. Feature proposals (sometimes years old)
> really aren't...
>
> > Speaking of the EuroPython sprints, is anybody going to be there to
> > organise a py.test sprint?  Raphael might still be (but then he might
> > want to defect to cookiecutter), Florian as well not sure about
> > others?  Anyone want to volunteer leading a sprint?
>
>
> I'll be there on Saturday and maaaybe Sunday morning, but chances are
> I'm going to sprint on pylint again.
>
> Florian
>
> --
> http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
>GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
>  I love long mails! | http://email.is-not-s.ms/
> >
> >
> > Floris
> > ___
> > pytest-dev mailing list
> > pytest-dev@python.org
> > https://mail.python.org/mailman/listinfo/pytest-dev
> >
>
> --
> http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
>GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
>  I love long mails! | http://email.is-not-s.ms/
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] pytest 3.0 release check list

[Oliver Bestwalter]

Hi all,

I created a wiki page containing the checklist for the 3.0 release that
resulted from our discussion during the sprint.

https://github.com/pytest-dev/pytest/wiki/pytest-3.0-checklist

I think that is better than opening an issue, because everybody involved
can update the page directly and if there is still some discussion
necessary regarding concrete topics an issue can be opened for that
concrete topic.

cheers
Oliver
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Google Summer of Code

[Oliver Bestwalter]

Hello,

o.k. sounds all good to me then.

I have a topic in mind already that could nicely be tackled which is what
we started to draft already as part of the sprint:
https://github.com/tox-dev/tox/blob/master/doc/drafts/extend-envs-and-packagebuilds.md
- if we find a dedicated individual who wants to get their feet wet with
this topic, I actually start to get quite enthusiastic about the whole idea
:)

One caveat though: I am quite a catastrophe when it comes to classical
admin things like filling out forms and stuff - so if this would be part of
my work as a mentor, I will have to ask for a mentor myself to learn to
better tackle these things ;)

Cheers
Oliver

On Wed, 25 Jan 2017 at 12:31 Ana Ribeiro 
wrote:

> Hello,
>
> Sorry, when I read the email too quickly and I thought of the browser
> (Tor) instead of Tox (shame)... For sure, I have used Tox on my internship.
>
> About bad experiences, they may happen, but good experiences may happen as
> well... In Mozilla Outreachy program, they had a good application process
> in my opinion, we had to solve a small issue together our mentor, so we
> could see if this partnership would work well. In GSoC we can decide how we
> are going to take the application process, so I think it 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 :
>
> * Bruno Oliveira  [2017-01-25 10:27:09 +]:
> > 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. Perhaps you sent it only to Ana by accident?
>
> I did, and it's in the archive too:
> https://mail.python.org/pipermail/pytest-dev/2017-January/003985.html
>
> Florian
>
> --
> http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
>GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
>  I love long mails! | http://email.is-not-s.ms/
>
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Google Summer of Code

[Oliver Bestwalter]

Hi all,

I had a closer look at the timeline and what is involved and I think I
would overreach myself if I would volunteer as a mentor this year already.
I am basically a newbie to tox myself, so I better buckle down a bit first.
I guess I will feel up to the task next year then.

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 interesting topic to tackle.

Cheers
Oliver

On Wed, 8 Feb 2017 at 15:49 Bruno Oliveira  wrote:

> 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 feel free to add themselves as well.
>
> Cheers,
> Bruno.
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] pytest 3.0.0 released!

[Oliver Bestwalter]

Hi Bruno,

wow, you're fast! Great! I wanted to do some testing over the weekend with
the release candidate. Will do it with 3.0 now instead :)

What I can already say is that I checked the feature branch against my main
projects since the sprint and didn't have any problems.

Cheers
Oliver


On Fri, 19 Aug 2016 at 23:58 Bruno Oliveira  wrote:

>
>
> On Fri, Aug 19, 2016 at 6:24 PM Bruno Oliveira 
> wrote:
>
>> This release contains a lot of bugs and improvements, and ...
>>
>
> Of course I meant "lot of bug *fixes*", sorry for the typo. :)
>
> Cheers,
> Bruno.
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] pytest 3.0.0 released!

[Oliver Bestwalter]

Hi,

I played with the release today and found no major problems.

The deprecation warnings could be more helpful, but I guess that will be
solved as a side effect of fixing
https://github.com/pytest-dev/pytest/issues/1804

A "None" sneaks into the output where a warning number should be if you
pass a string to pytest.main instead of a list. Needs some polishing, I
will hope to get into the next bugfix release.

import pytest; pytest.main('-v')

results in: WC1 None passing a string to pytest.main() is deprecated, pass
a list of arguments instead.


I updated the checklist to reflect the current status as that is the first
hit, if somebody is searchin for pytest 3.0 atm.

https://github.com/pytest-dev/pytest/wiki/pytest-3.0-checklist

Cheers
Oliver


On Sat, 20 Aug 2016 at 11:20 Oliver Bestwalter <oli...@bestwalter.de> wrote:

> Hi Bruno,
>
> wow, you're fast! Great! I wanted to do some testing over the weekend with
> the release candidate. Will do it with 3.0 now instead :)
>
> What I can already say is that I checked the feature branch against my
> main projects since the sprint and didn't have any problems.
>
> Cheers
> Oliver
>
>
> On Fri, 19 Aug 2016 at 23:58 Bruno Oliveira <nicodde...@gmail.com> wrote:
>
>>
>>
>> On Fri, Aug 19, 2016 at 6:24 PM Bruno Oliveira <nicodde...@gmail.com>
>> wrote:
>>
>>> This release contains a lot of bugs and improvements, and ...
>>>
>>
>> Of course I meant "lot of bug *fixes*", sorry for the typo. :)
>>
>> Cheers,
>> Bruno.
>> ___
>> pytest-dev mailing list
>> pytest-dev@python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

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

[Oliver Bestwalter]

Hello Ronny,

thanks a lot for going through the major PITA of doing such a move!

One thing I noticed is that the 4 remaining pull requests have not been
migrated. How can we deal with them?

Also see: https://github.com/tox-dev/tox/issues/352#issuecomment-247791365

The link to the pull request on Bitbucket now links to an unrelated issue
on Github. Is that expected fallout from the move or would you have
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> wrote:

> Hello everyone,
>
> i am pleased to announce that after some setbacks
> we now have finished the repository and
> issue tracker migration for tox to github.
>
> its new home is https://github.com/tox-dev/tox
>
> due to the setbacks i ended up deferring various detail works (like
> travis/readthedocs)
> those will be finished during the next few days.
>
> even before the announcement the new place already started brimming with
> activity
>
>
> -- Ronny
>
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

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

[Oliver Bestwalter]

Hi Florian,

I really appreciate, that you opted for the harder but better quality
route. The quality is really good - this comes from an enthusiastic T-Shirt
wearer since the early 1980s - so thanks for going through all the trouble
:)

Cheers
Oliver


On Tue, 25 Oct 2016 at 15:43 Florian Bruhin  wrote:

> * Ronny Pfannschmidt  [2016-10-25
> 15:15:06 +0200]:
> > Given the funding volumes and used amounts,
> > i wonder if, with the funds that are left, we could have the next
> > sprints sponsored mostly by cooperates
> > next time,
> >
> > I propose that those of us working in a company that could/should
> > participate kick off the
> > "paperwork mill" to see if that idea is viable.
>
> FWIW more than half of the money was already coming from companies.
>
> Florian
>
> --
> http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
>GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
>  I love long mails! | http://email.is-not-s.ms/
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Commit access to pytest

[Oliver Bestwalter]

Hi Floris,

thanks for the clarification.

Cheers
Oliver

On Wed, 16 Nov 2016 at 20:42 Floris Bruynooghe <f...@devork.be> wrote:

> On 15 November 2016 at 23:19, Oliver Bestwalter <oli...@bestwalter.de>
> wrote:
> > Hi,
> >
> > will this be a "sorta kinda C4" then or do we want to implement the whole
> > thing as described in https://rfc.zeromq.org/spec:42/C4/ ?
>
> Probably not, upon re-reading this I'm not actually a massive fan of
> the document in it's entirety despite it having many good intentions,
> e.g. 2.3.1 (must use real names) ranks pretty high on my scale for a
> bad idea.  But I'm not going to dissect the whole thing here.
>
> > I ask because what you describe Floris is an interesting idea but I do
> not
> > see the parallel to C4 as that process clearly has maintainers who merge
> PRs
> > of others, which I think of as a Good Thing. I mean this part of the
> > protocol:
> >
> > A "Contributor" is a person who wishes to provide a patch, being a set of
> > commits that solve some clearly identified problem.
> > A "Maintainer" is a person who merges patches to the project. Maintainers
> > are not developers; their job is to enforce process.
> > Contributors SHALL NOT have commit access to the repository unless they
> are
> > also Maintainers.
> > Maintainers SHALL have commit access to the repository.
>
> So upon re-reading of C4.1 I'm just interested in formalising how one
> gets to be a Maintainer.  C4.1 itself leaves this pretty vague while
> I'd like to give Contributors a clear expectation.
>
> > I also like the whole Problem -> Solution idea as basis for  development
> of
> > the project (section 2.3).
>
> Sure, C4.1 has many good ideas quite a few which we already follow more or
> less.
>
> > Giving everybody commit rights who successfully merged a PR is a
> different
> > idea that could be experimented with, but I would not call it C4.
>
> You're right, there is virtually no overlap between my proposal and
> C4.1.  It had been a very long time since I read C4.1 so honestly I
> didn't really remember what exactly it contained.
>
>
> Floris
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Commit access to pytest

[Oliver Bestwalter]

Hi,

will this be a "sorta kinda C4" then or do we want to implement the whole
thing as described in https://rfc.zeromq.org/spec:42/C4/ ?

I ask because what you describe Floris is an interesting idea but I do not
see the parallel to C4 as that process clearly has maintainers who merge
PRs of others, which I think of as a Good Thing. I mean this part of the
protocol:

- A "Contributor" is a person who wishes to provide a patch, being a set of
commits that solve some clearly identified problem.
- A "Maintainer" is a person who merges patches to the project. Maintainers
are not developers; their job is to enforce process.
- Contributors SHALL NOT have commit access to the repository unless they
are also Maintainers.
- Maintainers SHALL have commit access to the repository.
I also like the whole Problem -> Solution idea as basis for  development of
the project (section 2.3).

Giving everybody commit rights who successfully merged a PR is a different
idea that could be experimented with, but I would not call it C4.

Cheers
Oliver

On Tue, 15 Nov 2016 at 21:18 Floris Bruynooghe  wrote:

> Cool, I'll create a PR against CONTRIBUTING.txt, but I'll re-read C4.1
> again first to incorporate Ronny's comments better.
>
> Floris
>
> On 14 November 2016 at 14:59, Bruno Oliveira  wrote:
> > Hi everyone,
> >
> > I like the idea as well. As Floris mentioned, giving people commit
> access is
> > certainly a good way of motivating new contributors.
> >
> > Anyone up for writing up those guidelines so we can review them and
> decide
> > if we want to move in that direction or not?
> >
> > Cheers
> >
> > On Mon, Nov 14, 2016 at 5:42 AM Ronny Pfannschmidt
> >  wrote:
> >>
> >> 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 that came to github i feel that c4.1 it
> >> not up to date for gh
> >> (i.e. self merge after approval looks like a valid move now)
> >>
> >> I like the idea of slowly iterating towards  a more open and inclusive
> >> process.
> >> Readily offering commit bits to people that Demonstrate
> >> they can honor the Contribution Process is a beautiful first step.
> >>
> >> -- Ronny
> >>
> >> Am 14.11.2016 um 03:52 schrieb Floris Bruynooghe:
> >> > Hi all,
> >> >
> >> > A while ago Ronny proposed to adopt the ZeroMQ C4.1 process.  While
> >> > the discussion there never got very far (and I forgot to pick it up at
> >> > the sprint) I'd like to propose a rather less radical workflow while
> >> > attempting to make it easier for people to get on board.
> >> >
> >> > Basically I'd propose to give commit access to anyone who created a PR
> >> > and followed it through to it being successfully merged (with
> >> > changelog etc etc all done by the new contributor).
> >> >
> >> > The main reason to propose this is because right now we don't really
> >> > have a clear policy on when someone joins the committers.  And it is
> >> > much more inclusive to write down clear rules for this.  Gaining
> >> > commit access is generally empowering and motivating and a good way to
> >> > include new members in the development.
> >> >
> >> > What do other people think?
> >> >
> >> > Floris
> >> > ___
> >> > pytest-dev mailing list
> >> > pytest-dev@python.org
> >> > https://mail.python.org/mailman/listinfo/pytest-dev
> >>
> >> ___
> >> pytest-dev mailing list
> >> pytest-dev@python.org
> >> https://mail.python.org/mailman/listinfo/pytest-dev
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] Suggestion: EuroPython pytest/tox/devpi helpdesk

[Oliver Bestwalter]

Hi all,

EuroPython is on the horizon and they have a new thing (or at least new for
me) called "helpdesk"

> Helpdesk / 10 slots

> Helpdesks are a great way to share your experience on a technology, by
offering to help people answering their questions and solving their
practical problems. You can run a helpdesk by yourself or with colleagues
and friends. Each helpdesk will be open for 3 hours in total, 1.5 hours in
the morning and 1.5 hours in the afternoon. People looking for help will
sign up for a 30 minute slot and talk to you. There is no specific
preparation needed; you just need to be proficient in the technology you
run the helpdesk for.

see: https://ep2017.europython.eu/en/call-for-proposals/

I would be interested to try this and volunteer to help with questions
about tox mainly. Would anybody else interested in that kind of thing? If
we find a handful of people that would want to do that, we could have a
tox/pytest/devpi helpdesk :)

Cheers,
Oliver
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] Sprint this summer?

[Oliver Bestwalter]

Hi all,

just want to get the ball rolling and ask if planning has started already
and how I can help.

This is mainly triggered by a question here:
https://github.com/tox-dev/tox/issues/485

Would it maybe be feasible to coordinate this together with the EuroPython
this year?

Cheers,
Oliver
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Sprint this summer?

[Oliver Bestwalter]

Hello Ronny,

oh wow! congratulations then :)

Cheers
Oliver

On Fri, 17 Mar 2017 at 10:16 Ronny Pfannschmidt <
opensou...@ronnypfannschmidt.de> wrote:

> Hi all,
>
> i'd love to join a sprint in some way, but i do have a kid on the way and
> its due end of july.
> which is also why i can't participate in planning this year and also
> likely can't be there in person.
>
> -- Ronny
>
> On 15.03.2017 13:47, Oliver Bestwalter wrote:
>
> Hi all,
>
> just want to get the ball rolling and ask if planning has started already
> and how I can help.
>
> This is mainly triggered by a question here:
> https://github.com/tox-dev/tox/issues/485
>
> Would it maybe be feasible to coordinate this together with the EuroPython
> this year?
>
> Cheers,
> Oliver
>
>
> ___
> pytest-dev mailing 
> listpytest-dev@python.orghttps://mail.python.org/mailman/listinfo/pytest-dev
>
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

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

[Oliver Bestwalter]

Hi all,

I usually have all flake8 on full throttle and let PyCharm warn me (except
for naming, I am a bit particular there I admit) and I have similar
thoughts when wondering through the tox sources. I will watch how you do it
and then maybe propose the same for tox afterwards.

Good luck,

Cheers
Oliver


On Fri, 17 Mar 2017 at 11:49 Bruno Oliveira  wrote:

> 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 (recently we switched our
> import-order sorting to PEP8 from a custom standard for example) we use a
> fictional persona for the committer of the change as to not assign undue
> "blame" to a person, so I suggest doing the same here. We can use our own
> pytest's bot for that.
>
> Cheers,
> Bruno.
>
> On Fri, Mar 17, 2017 at 6:35 AM Florian Schulze 
> wrote:
>
> Hi!
>
> Personally I disable the line length limit and keep all other warnings.
>
> For old projects I only fix pep8 issues in code I edit in a commit. A
> massive cleanup disrupts history and especially "blame" too much IMHO.
>
> Regards,
> Florian Schulze
>
>
> On 17 Mar 2017, at 10:09, Ronny Pfannschmidt wrote:
>
> > 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 the time
> >
> > what i certainly don't want to do, is start to disable code standard
> > enforcement on random projects,
> > so i want to enforce it - and that means fixing up pytest once and for
> > all.
> >
> > a good point in time would e to do it on the features branch right
> > before doing a release and merging back to master as it would create
> > the
> > smallest merge effort.
> >
> > additionally it would allow us to switch from travis for linting to a
> > dedicated service with better gh integration in future without
> > maintaining yet another massive exclude list
> >
> > -- Ronny
> >
> > ___
> > pytest-dev mailing list
> > pytest-dev@python.org
> > https://mail.python.org/mailman/listinfo/pytest-dev
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [tox-dev] Suggestion: EuroPython pytest/tox/devpi helpdesk

[Oliver Bestwalter]

Hi,

I wrote a mail to ask. I also noticed that the call for proposals is closed
already, I asked anyway - maybe there is still some room for us.

Cheers
Oliver

On Mon, 3 Apr 2017 at 16:51 Ionel Cristian Mărieș <cont...@ionelmc.ro>
wrote:

> I'm interested in this as well (pytest-cov/benchmark and general pytest
> help) but what are the guidelines? I suppose there is no space for a 10
> people "pytest-*" helpdesk. The CFP page is very scarce on information.
> Anyone already asked organizers for more info?
>
>
> Thanks,
> -- Ionel Cristian Mărieș, http://blog.ionelmc.ro
>
> On Mon, Apr 3, 2017 at 5:25 PM, Oliver Bestwalter <oli...@bestwalter.de>
> wrote:
>
> Hi all,
>
> I just got the green light to go to EuroPython, so I volunteer to do the
> proposal and in the worst case I will be helpdesking away on my own, but I
> sincerely hope that a few of you will be there and join me :)
>
> I would also be willing to help organizing/being part of sprints at the
> weekend.
>
> Cheers
> Oliver
>
> On Tue, 28 Mar 2017 at 10:22 Dave Hunt <dh...@mozilla.com> wrote:
>
> I’m thinking of coming to EuroPython, and would be happy to spend some
> time at the helpdesk. My particular area of expertise would be the plugins
> I maintain, but I’m sure I can also answer some pytest/tox/devpi queries
> too.
>
> Cheers,
> Dave
>
> On 27 Mar 2017, at 21:42, Oliver Bestwalter <oli...@bestwalter.de> wrote:
>
> Hi all,
>
> EuroPython is on the horizon and they have a new thing (or at least new
> for me) called "helpdesk"
>
> > Helpdesk / 10 slots
>
> > Helpdesks are a great way to share your experience on a technology, by
> offering to help people answering their questions and solving their
> practical problems. You can run a helpdesk by yourself or with colleagues
> and friends. Each helpdesk will be open for 3 hours in total, 1.5 hours in
> the morning and 1.5 hours in the afternoon. People looking for help will
> sign up for a 30 minute slot and talk to you. There is no specific
> preparation needed; you just need to be proficient in the technology you
> run the helpdesk for.
>
> see: https://ep2017.europython.eu/en/call-for-proposals/
>
> I would be interested to try this and volunteer to help with questions
> about tox mainly. Would anybody else interested in that kind of thing? If
> we find a handful of people that would want to do that, we could have a
> tox/pytest/devpi helpdesk :)
>
> Cheers,
> Oliver
>
> ___
> tox-dev mailing list
> tox-...@python.org
> https://mail.python.org/mm3/mailman3/lists/tox-dev.python.org/
>
>
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [tox-dev] Suggestion: EuroPython pytest/tox/devpi helpdesk

[Oliver Bestwalter]

Hi,

I don't know what I saw yesterday, but the call for proposals ist not
closed, There is time untill the 16th of April ...

Oliver

On Mon, 3 Apr 2017 at 22:57 Oliver Bestwalter <oli...@bestwalter.de> wrote:

> Hi,
>
> I wrote a mail to ask. I also noticed that the call for proposals is
> closed already, I asked anyway - maybe there is still some room for us.
>
> Cheers
> Oliver
>
> On Mon, 3 Apr 2017 at 16:51 Ionel Cristian Mărieș <cont...@ionelmc.ro>
> wrote:
>
> I'm interested in this as well (pytest-cov/benchmark and general pytest
> help) but what are the guidelines? I suppose there is no space for a 10
> people "pytest-*" helpdesk. The CFP page is very scarce on information.
> Anyone already asked organizers for more info?
>
>
> Thanks,
> -- Ionel Cristian Mărieș, http://blog.ionelmc.ro
>
> On Mon, Apr 3, 2017 at 5:25 PM, Oliver Bestwalter <oli...@bestwalter.de>
> wrote:
>
> Hi all,
>
> I just got the green light to go to EuroPython, so I volunteer to do the
> proposal and in the worst case I will be helpdesking away on my own, but I
> sincerely hope that a few of you will be there and join me :)
>
> I would also be willing to help organizing/being part of sprints at the
> weekend.
>
> Cheers
> Oliver
>
> On Tue, 28 Mar 2017 at 10:22 Dave Hunt <dh...@mozilla.com> wrote:
>
> I’m thinking of coming to EuroPython, and would be happy to spend some
> time at the helpdesk. My particular area of expertise would be the plugins
> I maintain, but I’m sure I can also answer some pytest/tox/devpi queries
> too.
>
> Cheers,
> Dave
>
> On 27 Mar 2017, at 21:42, Oliver Bestwalter <oli...@bestwalter.de> wrote:
>
> Hi all,
>
> EuroPython is on the horizon and they have a new thing (or at least new
> for me) called "helpdesk"
>
> > Helpdesk / 10 slots
>
> > Helpdesks are a great way to share your experience on a technology, by
> offering to help people answering their questions and solving their
> practical problems. You can run a helpdesk by yourself or with colleagues
> and friends. Each helpdesk will be open for 3 hours in total, 1.5 hours in
> the morning and 1.5 hours in the afternoon. People looking for help will
> sign up for a 30 minute slot and talk to you. There is no specific
> preparation needed; you just need to be proficient in the technology you
> run the helpdesk for.
>
> see: https://ep2017.europython.eu/en/call-for-proposals/
>
> I would be interested to try this and volunteer to help with questions
> about tox mainly. Would anybody else interested in that kind of thing? If
> we find a handful of people that would want to do that, we could have a
> tox/pytest/devpi helpdesk :)
>
> Cheers,
> Oliver
>
> ___
> tox-dev mailing list
> tox-...@python.org
> https://mail.python.org/mm3/mailman3/lists/tox-dev.python.org/
>
>
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

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

[Oliver Bestwalter]

Hi,

I am reading this thread with growing fascination, because I have the
feeling I am missing something, so can I summarize?

If I had a test, where I don't care about output and only about whther
exceptions are thrown or not I would normally write this:

@pytest.mark.parametrize(
"req, exc", (
('foo', None),
('bar', None),
('BLARF', ValueError),
('PLONK', IndexError),
))
def test_something(self, arg, exc):
if exc:
with pytest.raises(exc):
something(arg)
else:
something(arg)

So the new feature would save me two lines of code:

@pytest.mark.parametrize(
"req, exc", (
('foo', None),
('bar', None),
('BLARF', ValueError),
('PLONK', IndexError),
))
def test_something(arg, exc):
with pytest.raises(exc):
something(arg)

... 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 missing something?

I usually don't write tests like that anyway but rather tests where I
expect either a concrete value of a certain type or I expect an Exception
to be raised. E.g.

@pytest.mark.parametrize(
"req, exp", (
('foo', True),
('bar', False),
('BLARF', ValueError),
('PLONK', IndexError),
))
def test_something(arg, exp):
if not isinstance(exp, bool):
with pytest.raises(exp):
something(arg)
else:
assert something(arg) == exp

And there this feature would not help me anyway or one would have to make a
new bastard context manager like

@pytest.mark.parametrize(
"req, exp", (
('foo', True),
('bar', False),
('BLARF', ValueError),
('PLONK', IndexError),
))
def test_something(arg, exp):
with pytest.raises_or_returns_or_yields_or_whatever(exp):
something(arg)

**shudder**

So I am not sure if this is worth implementing unless I am just not able to
grasp the real benfits.

Cheers,
Oliver
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

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

[Oliver Bestwalter]

Hi,

+1 for making releases easier.

Just a thought on the side: mid to long term we might even be able to
synchronize workflows between projects and do something like jazzband (
https://jazzband.co/) for pytest/tox/devpi and plugins that are maintained
by the community.

Cheers,
Oliver

On Wed, 19 Apr 2017 at 13:42 Bruno Oliveira  wrote:

> 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 +, Bruno Oliveira wrote:
>> >> What if we instead of considering features, we released a new minor
>> version
>> >> periodically, for say every month or two? We could adopt the same for
>> bug
>> >> fix releases, like each two weeks.
>> > FWIW what GitLab[1] does is a monthly feature release, and patch
>> > releases whenever needed. I don't think it's a good idea to have a fixed
>> > release cycle for patches, but it sounds like it could work quite well
>> > for feature releases indeed.
>>
>
> I'm curious, why do you think it is not a good idea to have a fixed or
> semi-fixed release cycle for patches?
>
>
>> https://github.com/pytest-dev/pytest/blob/master/HOWTORELEASE.rst is
>> about 13 steps,
>> most manual mundane and error-prone - it should be at most 1-2 steps
>>
>
> I agree, we should strive to improve that. The steps are not hard, but
> still they are error prone (remember me sending the email for the pytest
> 3.0 release and writing "and this release contains a lot of bugs and new
> features" instead of "... lot of bug **fixes** and..."). Heh.
>
>
>> >> Having only a master branch, I think Ronny was proposing to then
>> figuring
>> >> out if it was a bug fix release or a minor release based on the
>> CHANGELOG.
>> > That means you either need to arbitarily hold back contributions, or you
>> > lose the ability to do bugfix releases and need to do a feature release
>> > (probably with new subtle bugs, looking at our track record) every time.
>> if we make releasing inexpensive and reliable even a botched release an
>> have a quick fix afterwards,
>> i don't see a problem there, as long as we have processes in place that
>> let stuff like "softening of xfail" to happen we'll have botched feature
>> releases anyway,
>> and IMHO that shouldn't stand in the way of removing unnecessary
>> maintenance pain.
>>
>> what i want to remove is time eating and painful processes at releasing,
>>
>
> I appreciate Ronny bringing up this topic, a 3.1 release is long overdue.
>
> We are discussing two things which have some interconnection:
>
> 1. Should we improve our release process, so that releasing a new version
> is a 1 or 2 step process?
> 2. Keep or not a separate branch for ``features``.
>
> I think we can all agree that 1) would be great and we want that.
>
> Regarding 2), there's a few sub-points:
> 2.1) Periodically have to merge master into ``features``; Ronny believes
> this is a pain, IMHO it's not a big deal;
> 2.2) How often should we release bug fixes and feature releases? This is
> impacted directly by question 1: the easier to make a new release, more
> often we will do it (just pushing a tag every Thursday for a new bug fix
> release for example).
>
> I definitely agree that we should have more frequent feature releases than
> what we have now; I was under the mentality that we wanted all feature
> releases with 2 or 3 major themes and new additions, but given that we
> can't really guarantee time to implement these new features it might make
> more sense to just make new feature releases with just minor improvements
> and changes.
>
> Having said that, I think it is still worthwhile to keep the features
> branch so we can issue bug-fixes quickly and periodically. But for that to
> work, we need to improve the release process so that it takes one or two
> steps at most; we have excellent CI at our service to help us accomplish
> that.
>
> I really would like for us to reach a consensus here. :)
>
> Cheers,
> Bruno.
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [tox-dev] Suggestion: EuroPython pytest/tox/devpi helpdesk

[Oliver Bestwalter]

Hi all,

I almost dropped the ball here as I was on vacation and forgot about this
for a while. I am a lucky guy though, because they extended the time for
CfP until tomorrow so now I started to write a proposal.

I will write a pretty general proposal about offering to help people with
their entry to intermediate level questions and problems regarding pytest,
tox and devpi, because I am confident I can help with that even if I am on
my own. I will offer to help with their problems with configurations or
finding the right testing strategy.

If a problem is unsolvable by me, then it is by definition "advanced" and I
can help formulating their problems/potential bugs as issues or questions
to the TIP mailing list for the gurus to pick up.

I can do the proposal in my name so there is no need for any strict
commitment from anyone but me, but I would obviously be delighted, if you
turn up :)

I'll keep you posted if the proposal was accepted.

Cheers,
Oliver

On Tue, 4 Apr 2017 at 16:16 Oliver Bestwalter <oli...@bestwalter.de> wrote:

> Hi,
>
> I don't know what I saw yesterday, but the call for proposals ist not
> closed, There is time untill the 16th of April ...
>
> Oliver
>
> On Mon, 3 Apr 2017 at 22:57 Oliver Bestwalter <oli...@bestwalter.de>
> wrote:
>
>> Hi,
>>
>> I wrote a mail to ask. I also noticed that the call for proposals is
>> closed already, I asked anyway - maybe there is still some room for us.
>>
>> Cheers
>> Oliver
>>
>> On Mon, 3 Apr 2017 at 16:51 Ionel Cristian Mărieș <cont...@ionelmc.ro>
>> wrote:
>>
>> I'm interested in this as well (pytest-cov/benchmark and general pytest
>> help) but what are the guidelines? I suppose there is no space for a 10
>> people "pytest-*" helpdesk. The CFP page is very scarce on information.
>> Anyone already asked organizers for more info?
>>
>>
>> Thanks,
>> -- Ionel Cristian Mărieș, http://blog.ionelmc.ro
>>
>> On Mon, Apr 3, 2017 at 5:25 PM, Oliver Bestwalter <oli...@bestwalter.de>
>> wrote:
>>
>> Hi all,
>>
>> I just got the green light to go to EuroPython, so I volunteer to do the
>> proposal and in the worst case I will be helpdesking away on my own, but I
>> sincerely hope that a few of you will be there and join me :)
>>
>> I would also be willing to help organizing/being part of sprints at the
>> weekend.
>>
>> Cheers
>> Oliver
>>
>> On Tue, 28 Mar 2017 at 10:22 Dave Hunt <dh...@mozilla.com> wrote:
>>
>> I’m thinking of coming to EuroPython, and would be happy to spend some
>> time at the helpdesk. My particular area of expertise would be the plugins
>> I maintain, but I’m sure I can also answer some pytest/tox/devpi queries
>> too.
>>
>> Cheers,
>> Dave
>>
>> On 27 Mar 2017, at 21:42, Oliver Bestwalter <oli...@bestwalter.de> wrote:
>>
>> Hi all,
>>
>> EuroPython is on the horizon and they have a new thing (or at least new
>> for me) called "helpdesk"
>>
>> > Helpdesk / 10 slots
>>
>> > Helpdesks are a great way to share your experience on a technology, by
>> offering to help people answering their questions and solving their
>> practical problems. You can run a helpdesk by yourself or with colleagues
>> and friends. Each helpdesk will be open for 3 hours in total, 1.5 hours in
>> the morning and 1.5 hours in the afternoon. People looking for help will
>> sign up for a 30 minute slot and talk to you. There is no specific
>> preparation needed; you just need to be proficient in the technology you
>> run the helpdesk for.
>>
>> see: https://ep2017.europython.eu/en/call-for-proposals/
>>
>> I would be interested to try this and volunteer to help with questions
>> about tox mainly. Would anybody else interested in that kind of thing? If
>> we find a handful of people that would want to do that, we could have a
>> tox/pytest/devpi helpdesk :)
>>
>> Cheers,
>> Oliver
>>
>> ___
>> tox-dev mailing list
>> tox-...@python.org
>> https://mail.python.org/mm3/mailman3/lists/tox-dev.python.org/
>>
>>
>> ___
>> pytest-dev mailing list
>> pytest-dev@python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>
>>
>>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Help testing 3.2.0 release

[Oliver Bestwalter]

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 of interest:
https://pastebin.com/xW7KfuuN

Besides from that it works fine with the projects I threw it at (tox and
some private and work projects).

Cheers,
Oliver


On Fri, 14 Jul 2017 at 14:06 Bruno Oliveira  wrote:

> Hi Florian,
>
> I definitely agree with you about making it clear what users have to do to
> replace deprecated functionality, which brings to attention that we could
> improve the bit about markers in parametrize deprecation as it stands now
> in the CHANGELOG.
>
> But the __multicall__ warning was not added to 3.2, it has been in place
> since 2015. Are you seeing this warning just now?
>
> Cheers,
> Bruno.
>
> On Fri, Jul 14, 2017 at 4:51 AM Florian Schulze 
> wrote:
>
>> Works fine with devpi, but ...
>>
>> I got the __multicall__ deprecation warning and had a very hard time to
>> find information on how to actually fix it. In the end I found the PR that
>> changes the docs in pytest which allowed me to change our fixture.
>>
>> So, if you deprecate something, please provide easy to find docs on how
>> to actually fix it, even if the old stuff was undocumented. 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 is available at:
>>
>> https://devpi.net/nicoddemus/dev/pytest/3.2.0
>>
>> And can be installed with:
>>
>> pip install -U
>> https://devpi.net/nicoddemus/dev/+f/aeb/edee851da9e58/pytest-3.2.0-py2.py3-none-any.whl
>>
>> If all goes well I plan to release it during the weekend.
>>
>> Cheers,
>> Bruno.
>>
>> ___
>>
>>
>> pytest-dev mailing list
>> pytest-dev@python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [tox-dev] Suggestion: EuroPython pytest/tox/devpi helpdesk

[Oliver Bestwalter]

Hi all,

the date for the helpdesk is tuesday from 10:30 to 12:00 and again from
14:00 to 15:30.

I am also there on sunday and will stay for the sprints and do some work on
tox, if you are interested to join in.

See you in Rimini
Oliver

On Fri, 12 May 2017 at 21:33 Oliver Bestwalter <oli...@bestwalter.de> wrote:

> Hi all,
>
> I just got a mail that the helpdesk proposal was accepted. The date is not
> scheduled yet. Will keep you posted.
>
> Cheers,
> Oliver
>
>
> On Mon, 24 Apr 2017 at 17:03 Dave Hunt <dh...@mozilla.com> wrote:
>
>> Unfortunately not. Might be able to attend a pytest sprint if one is
>> planned, but otherwise it’ll probably be next year for me.
>>
>>
>> On 24 Apr 2017, at 16:00, Oliver Bestwalter <oli...@bestwalter.de> wrote:
>>
>> Hi Dave,
>>
>> no problem - was looking forward to see you to though. Are you attending
>> Pycon US? I might be there for the sprints.
>>
>> Cheers,
>> Oliver
>>
>> On Mon, 24 Apr 2017 at 15:56 Dave Hunt <dh...@mozilla.com> wrote:
>>
>>> Unfortunately I’ve decided not to attend EuroPython this year, so I’ll
>>> need to revoke my offer to help out. Hopefully next year..!
>>>
>>> On 28 Mar 2017, at 09:21, Dave Hunt <dh...@mozilla.com> wrote:
>>>
>>> I’m thinking of coming to EuroPython, and would be happy to spend some
>>> time at the helpdesk. My particular area of expertise would be the plugins
>>> I maintain, but I’m sure I can also answer some pytest/tox/devpi queries
>>> too.
>>>
>>> Cheers,
>>> Dave
>>>
>>> On 27 Mar 2017, at 21:42, Oliver Bestwalter <oli...@bestwalter.de>
>>> wrote:
>>>
>>> Hi all,
>>>
>>> EuroPython is on the horizon and they have a new thing (or at least new
>>> for me) called "helpdesk"
>>>
>>> > Helpdesk / 10 slots
>>>
>>> > Helpdesks are a great way to share your experience on a technology, by
>>> offering to help people answering their questions and solving their
>>> practical problems. You can run a helpdesk by yourself or with colleagues
>>> and friends. Each helpdesk will be open for 3 hours in total, 1.5 hours in
>>> the morning and 1.5 hours in the afternoon. People looking for help will
>>> sign up for a 30 minute slot and talk to you. There is no specific
>>> preparation needed; you just need to be proficient in the technology you
>>> run the helpdesk for.
>>>
>>> see: https://ep2017.europython.eu/en/call-for-proposals/
>>>
>>> I would be interested to try this and volunteer to help with questions
>>> about tox mainly. Would anybody else interested in that kind of thing? If
>>> we find a handful of people that would want to do that, we could have a
>>> tox/pytest/devpi helpdesk :)
>>>
>>> Cheers,
>>> Oliver
>>> ___
>>> tox-dev mailing list
>>> tox-...@python.org
>>> https://mail.python.org/mm3/mailman3/lists/tox-dev.python.org/
>>>
>>>
>>>
>>>
>>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [tox-dev] Suggestion: EuroPython pytest/tox/devpi helpdesk

[Oliver Bestwalter]

Hi Dave,

no problem - was looking forward to see you to though. Are you attending
Pycon US? I might be there for the sprints.

Cheers,
Oliver

On Mon, 24 Apr 2017 at 15:56 Dave Hunt <dh...@mozilla.com> wrote:

> Unfortunately I’ve decided not to attend EuroPython this year, so I’ll
> need to revoke my offer to help out. Hopefully next year..!
>
> On 28 Mar 2017, at 09:21, Dave Hunt <dh...@mozilla.com> wrote:
>
> I’m thinking of coming to EuroPython, and would be happy to spend some
> time at the helpdesk. My particular area of expertise would be the plugins
> I maintain, but I’m sure I can also answer some pytest/tox/devpi queries
> too.
>
> Cheers,
> Dave
>
> On 27 Mar 2017, at 21:42, Oliver Bestwalter <oli...@bestwalter.de> wrote:
>
> Hi all,
>
> EuroPython is on the horizon and they have a new thing (or at least new
> for me) called "helpdesk"
>
> > Helpdesk / 10 slots
>
> > Helpdesks are a great way to share your experience on a technology, by
> offering to help people answering their questions and solving their
> practical problems. You can run a helpdesk by yourself or with colleagues
> and friends. Each helpdesk will be open for 3 hours in total, 1.5 hours in
> the morning and 1.5 hours in the afternoon. People looking for help will
> sign up for a 30 minute slot and talk to you. There is no specific
> preparation needed; you just need to be proficient in the technology you
> run the helpdesk for.
>
> see: https://ep2017.europython.eu/en/call-for-proposals/
>
> I would be interested to try this and volunteer to help with questions
> about tox mainly. Would anybody else interested in that kind of thing? If
> we find a handful of people that would want to do that, we could have a
> tox/pytest/devpi helpdesk :)
>
> Cheers,
> Oliver
> ___
> tox-dev mailing list
> tox-...@python.org
> https://mail.python.org/mm3/mailman3/lists/tox-dev.python.org/
>
>
>
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

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

[Oliver Bestwalter]

Hi all,

this is a bit meta, as I have not enough insight about the topic at hand (I
did not follow the discussion closely), but as the one who proposed the
policy at the last sprint, I feel obliged to give my two cents about that
aspect of the discussion. I also try to give my perspective as a pytest
user.

At the last sprint I tried to find a solution to a problem that I
repeatedly noticed during conversations at last years' sprint. There were a
lot of corners in the code where things should be tidied up but can't,
because of backwards compatibility concerns. I wanted to start a discussion
how to be able to break backwards compatibility in an acceptable way for
users, by giving them (on by default) deprecation warnings and having a
clear exit strategy. What I did not want is to introduce unnecessary
friction into the development process. So if it turns out that this is the
case and breaking backwards compatibility is better handled on a case by
case basis in pytest, just revoke the policy and declare it a failed
experiment. No harm done. If it is thought that the policy as basically not
a bad thing but needs tweaking, please let's do that, I am happy to help.

As a user of testing tools like pytest, tox, devpi, coverage, flexmock and
whatnot, I personally do not mind if my CI dependencies break now and then
anyway. If I come into the office in the morning and our CI monitor is an
ocean of red nightly builds, I know that a dependency has broken and I can
deal with it accordingly (e.g. pinning the version until I have adapted my
code or the dependency has been fixed). I think that is just a normal
aspect of being part of a vibrant ecosystem.

Also: maybe some internal changes that break backwards compatibility in a
way that you can't even give proper warnings (like it seems to be the case
with this change ... I am not sure though as I did not understand the
change properly). Then the policy doesn't really apply and it has to be
handled differently (a foolish consistency is the hobgoblin of little minds
after all). The users should then be informed why this happens the way it
does (and why a longer lead up and a major release is not justified
although some backwards compatibility might break). This would still be
perfectly o.k. for me as user. We all sometimes make promises, we can't
keep after all ...

As an aside: here is what happened with the last requests release and how
they handled it: https://github.com/kennethreitz/requests/issues/4006).

Last word from a happy FLOSS user: what always outweighs the pain of broken
things for me is my gratitude towards all the voluntary work that flows
into the libraries and tools that I can use in my daily life instead of
being stuck with prorietary cr***. It's not like somebody dies because my
testing framework broke my CI builds, so I always try to keep things in
perspective :)

Cheers,
Oliver

On Sun, 21 May 2017 at 13:28 Floris Bruynooghe  wrote:

> 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 our policy is saying in our documentation
> and announcements: in two releases time we'll break this backwards
> compatibility thing (whether that's new-style classes or marks).  Then
> two releases later bump the major version and do it.  It slows breakage
> a little bit down and I thought that was the reason for the current
> deprecation policy.  Yes it is more annoying as we basically have to
> leave a pull-request or branch lying around for all that time and deal
> with the merging breakage resulting from this.
>
> Having said that, I'm happy to re-evaluate the policy if enough people
> think this is a bad idea.  But I'd like some user feedback as well
> before changing it.
>
>
> Floris
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [rant] introduction of the new mark api will be deferred further - due to bad rotten spaghetti code

[Oliver Bestwalter]

Hi all,

maybe focussing all eforts on improving code and test quality for a while
would be a good idea before attempting any big refactorings? Obviously you
can't force anybody, but if that is a clearly stated intent of the pytest
team combined with the warning that new features, etc. will be on the
backburner for a while, might help?

Also : How about organizing a dedicated code quality and test quality
sprint next year? I would love to help and have the chance of getting into
the pytest code base a bit more.

And just because the timing seems right: I could also offer to add coverage
to the project, as I just did that for tox and it would be relatively
straight forward for me to also do that for pytest now:
https://codecov.io/gh/tox-dev/tox

Cheers,
Oliver

On Wed, 6 Sep 2017 at 12:20 RonnyPfannschmidt <
opensou...@ronnypfannschmidt.de> wrote:

> Hi everyone,
>
> due pretty much damn bad code quality and complete lack of tests in a
> manageable granularity
> i am unable to move many internals to a new api anytime soon (things
> just fall apart sprinkled all over the place)
>
> additionally with the current state of tests its feels pretty much
> impossible to show what i need in a granular manageable and
> comprehensible manner (all the tests in the domain that i need to
> tighten/correct are end2end test which means they have zero value now
> that i need to change things)
>
> my current main problem is, that i cannot demonstrate the correct
> interaction of mark evaluation with nodes in a code amount that could
> fit a my head
>
> this is pretty much the results of years of neglecting to write fine
> granular tests while also not cleaning up
>
> so the effort to fix this will require weeks of work and likely
> introduce accidental internal api breaks en mass as i try to get more
> granular tests working.
>
> I feel pretty much helpless  and betrayed in front of such a task, i'm
> not sure if i want to even start anymore.
>
> I'm pretty pissed off and angry that the code is at such a state to
> begin with.
>
> -- Ronny
>
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [rant] introduction of the new mark api will be deferred further - due to bad rotten spaghetti code

[Oliver Bestwalter]

sorry, brain fart: I did not mean refactorings ... I actually meant the
opposite: first refactor the code and tests to make it more maintainable
and malleable before attempting to large scale functionality changes.

On Wed, 6 Sep 2017 at 18:29 Oliver Bestwalter <oli...@bestwalter.de> wrote:

> Hi all,
>
> maybe focussing all eforts on improving code and test quality for a while
> would be a good idea before attempting any big refactorings? Obviously you
> can't force anybody, but if that is a clearly stated intent of the pytest
> team combined with the warning that new features, etc. will be on the
> backburner for a while, might help?
>
> Also : How about organizing a dedicated code quality and test quality
> sprint next year? I would love to help and have the chance of getting into
> the pytest code base a bit more.
>
> And just because the timing seems right: I could also offer to add
> coverage to the project, as I just did that for tox and it would be
> relatively straight forward for me to also do that for pytest now:
> https://codecov.io/gh/tox-dev/tox
>
> Cheers,
> Oliver
>
> On Wed, 6 Sep 2017 at 12:20 RonnyPfannschmidt <
> opensou...@ronnypfannschmidt.de> wrote:
>
>> Hi everyone,
>>
>> due pretty much damn bad code quality and complete lack of tests in a
>> manageable granularity
>> i am unable to move many internals to a new api anytime soon (things
>> just fall apart sprinkled all over the place)
>>
>> additionally with the current state of tests its feels pretty much
>> impossible to show what i need in a granular manageable and
>> comprehensible manner (all the tests in the domain that i need to
>> tighten/correct are end2end test which means they have zero value now
>> that i need to change things)
>>
>> my current main problem is, that i cannot demonstrate the correct
>> interaction of mark evaluation with nodes in a code amount that could
>> fit a my head
>>
>> this is pretty much the results of years of neglecting to write fine
>> granular tests while also not cleaning up
>>
>> so the effort to fix this will require weeks of work and likely
>> introduce accidental internal api breaks en mass as i try to get more
>> granular tests working.
>>
>> I feel pretty much helpless  and betrayed in front of such a task, i'm
>> not sure if i want to even start anymore.
>>
>> I'm pretty pissed off and angry that the code is at such a state to
>> begin with.
>>
>> -- Ronny
>>
>> ___
>> pytest-dev mailing list
>> pytest-dev@python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [rant] introduction of the new mark api will be deferred further - due to bad rotten spaghetti code

[Oliver Bestwalter]

Hi,

and I just saw that pytest added coverage long ago - should have known :)

Cheers,
Oliver
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] EuroPython 2018: help desk

[Oliver Bestwalter]

Hi,

I will be attending the EuroPython and just submitted the same proposal
like last year to run a pytest/tox/devpi helpdesk. Last year was fun and
most people who came had not much experience with the tools yet and were
looking for some help introducing automated testing in their projects.

If any of you are also there and would like to hang out with me and help
some folks to get their questions answered, I would be happy.

I will let you know if the proposal was accepted.

Cheers,
Oliver
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [tox-dev] EuroPython 2018: help desk

[Oliver Bestwalter]

Hi Dave,

great! Looking forward to hang out with you :)

Cheers,
Oliver

On Mon, 21 May 2018 at 15:31 Dave Hunt <dh...@mozilla.com> wrote:

> Hey Oliver,
>
> I’m there Monday-Saturday and would be happy to help out where I can!
>
> Cheers,
> Dave
>
> > On 20 May 2018, at 15:47, Oliver Bestwalter <oli...@bestwalter.de>
> wrote:
> >
> > Hi,
> >
> > I will be attending the EuroPython and just submitted the same proposal
> like last year to run a pytest/tox/devpi helpdesk. Last year was fun and
> most people who came had not much experience with the tools yet and were
> looking for some help introducing automated testing in their projects.
> >
> > If any of you are also there and would like to hang out with me and help
> some folks to get their questions answered, I would be happy.
> >
> > I will let you know if the proposal was accepted.
> >
> > Cheers,
> > Oliver
> > ___
> > tox-dev mailing list
> > tox-...@python.org
> > https://mail.python.org/mm3/mailman3/lists/tox-dev.python.org/
>
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [tox-dev] EuroPython 2018: help desk

[Oliver Bestwalter]

Hello all,

I just got confirmation that the help desk proposal was accepted. See you
in Scotland then :)

Cheers,
Oliver

On Mon, 21 May 2018 at 15:52 Oliver Bestwalter  wrote:

> Hi Dave,
>
> great! Looking forward to hang out with you :)
>
> Cheers,
> Oliver
>
> On Mon, 21 May 2018 at 15:31 Dave Hunt  wrote:
>
>> Hey Oliver,
>>
>> I’m there Monday-Saturday and would be happy to help out where I can!
>>
>> Cheers,
>> Dave
>>
>> > On 20 May 2018, at 15:47, Oliver Bestwalter 
>> wrote:
>> >
>> > Hi,
>> >
>> > I will be attending the EuroPython and just submitted the same proposal
>> like last year to run a pytest/tox/devpi helpdesk. Last year was fun and
>> most people who came had not much experience with the tools yet and were
>> looking for some help introducing automated testing in their projects.
>> >
>> > If any of you are also there and would like to hang out with me and
>> help some folks to get their questions answered, I would be happy.
>> >
>> > I will let you know if the proposal was accepted.
>> >
>> > Cheers,
>> > Oliver
>> > ___
>> > tox-dev mailing list
>> > tox-...@python.org
>> > https://mail.python.org/mm3/mailman3/lists/tox-dev.python.org/
>>
>>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

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

[Oliver Bestwalter]

Hi,

I was following along and will propose the same for tox where I will also
volunteer as a contact, so might as well volunteer here.

Would be great though if there also was a female person available for
contact (if possible then also for tox, if we do thr same there).

Cheers,
Oliver
On Sat 4. Aug 2018 at 15:00, Bruno Oliveira  wrote:

> Feel free to add me as well Florian.
>
> []s
>
> On Sat, Aug 4, 2018 at 8:58 AM RonnyPfannschmidt <
> opensou...@ronnypfannschmidt.de> wrote:
>
>> Hi,
>>
>> pytest+...@ronnypfannschmidt.de
>>
>> -- Ronny
>>
>> Am 04.08.2018 um 10:50 schrieb Florian Bruhin:
>>
>> On Tue, Jul 31, 2018 at 12:53:51PM +0100, Dave Hunt wrote:
>>
>> I’d like to add a code of conduct for my pytest plugins, and as
>> they’re mostly under the pytest organisation on GitHub I thought it
>> would make sense to use the same as the pytest project. I was
>> surprised to find that the pytest project does not currently have a
>> code of conduct according tohttps://github.com/pytest-dev/pytest/community. 
>> Is there one
>> documented elsewhere? If not, which should we adopt?
>>
>> So I wanted to open a PR proposing the Contributor Covenant. However, I
>> noticed we don't have a suitable (non-public!) way of contacting us if
>> there's a need to.
>>
>> I'd propose we instead list mail addresses of some maintainers who'd be
>> interested and we feel like could handle potential conflicts in a fair
>> way.
>>
>> I'd gladly volunteer, but it'd be nice if some more people step up -
>> especially those who've been involved in pytest more from the community
>> rather than the technical side :)
>>
>> Florian
>>
>>
>>
>>
>> ___
>> pytest-dev mailing 
>> listpytest-dev@python.orghttps://mail.python.org/mailman/listinfo/pytest-dev
>>
>> ___
>> pytest-dev mailing list
>> pytest-dev@python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] pytest Quick Start Guide

[Oliver Bestwalter]

H Bruno,

congratulations! Bought it right away - coming from you it has to be good :)

Cheers,
Oliver

On Thu, 30 Aug 2018 at 17:09 Bruno Oliveira  wrote:

> Hi everyone,
>
> I'm pleased to announce the release of my book about pytest:
>
> https://www.packtpub.com/web-development/pytest-quick-start-guide
>
> I cover how to get started quickly to use pytest in your daily work, and
> some more niche topics like techniques to convert unittest-based suites to
> pytest.
>
> Cheers,
> Bruno.
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

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

[Oliver Bestwalter]

sounds good.
On Fri 6. Jul 2018 at 20:43, Floris Bruynooghe  wrote:

> 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 keep track of
> activity in pytest.  I'll even less know what's going on now.
>
> > To prevent changes to "master" and "features" branches to go unnoticed
> when
> > the email service gets discontinued, I propose to disable direct pushes
> to
> > those branches (using the GitHub option for that).
> >
> > Opinions?
>
> Sure, +1 on this part
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

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

[Oliver Bestwalter]

Thank you Ringo,

I have no immediate plans to implement something like this but I would
definitely appreciate some further docs/explanations/blog that unravels how
it is accomplished.

Cheers,
Oliver
On Fri 20. Apr 2018 at 08:26, Ringo De Smet <ringo.de.s...@ontoforce.com>
wrote:

> Floris, Oliver,
>
> If you want, I can get you bootstrapped on this Terraform setup. I can say
> I almost know Terraform inside out. ;-)
>
> Ringo
>
> On Thu, Apr 19, 2018 at 9:17 PM, Oliver Bestwalter <oli...@bestwalter.de>
> wrote:
>
>> Hi,
>>
>> Floris wrote:
>> > That's a nice bit of automation.
>>
>> I like the idea that it works somehow, but after looking at the README it
>> is still undistinguishable from magic to me.
>>
>> Floris wrote:
>> > [0] Bonus points for whoever contributes a teams functionality to
>> warehouse!
>>
>> This is why I think that this the definite way forward. Or ... if that
>> won't happen just having a shared account sharing the secrets through
>> keybase.io
>>
>> Cheers,
>> Oliver
>>
>
>
>
> --
> *Ringo De Smet*
> ringo.de.s...@ontoforce.com
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

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

[Oliver Bestwalter]

Hi,

Floris wrote:
> That's a nice bit of automation.

I like the idea that it works somehow, but after looking at the README it
is still undistinguishable from magic to me.

Floris wrote:
> [0] Bonus points for whoever contributes a teams functionality to
warehouse!

This is why I think that this the definite way forward. Or ... if that
won't happen just having a shared account sharing the secrets through
keybase.io

Cheers,
Oliver
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

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

[Oliver Bestwalter]

Hi Ronny,

I'd like to add my 2 cents from the perspective of an enthusiastic pytest
user, who dabbles in a lot of projects using pytest and who occasionally
teaches it:

I use pytest since 2010 and can still remember a time when I was able to
trigger the dreaded  quite regularly and it was often really
hard for me to figure out what went wrong, leading to arcane workarounds in
my test suites.

Since I am a bit involved in the project and pay more attention, I remember

* one incident where I triggered an INTERNAL error during normal usage in a
fresh release and the problem was easy to spot and fix (
https://github.com/pytest-dev/pytest/issues/2788).
* one breaking change that was also easy to fix: the change in the logging
behaviour and that was also perfectly o.k. because bottom line is that the
logging behaviour overall now is far better because of this
* one hard to reproduce race condition due to the introduction of tmp_path
(thanks for that btw), which also was fixed faster than I was even able to
find some time to have a closer look (
https://github.com/pytest-dev/pytest/issues/4181).

All in all pretty painless and easy to work around and usually fixed really
quickly.

In my experience the subset of functionality/plugins that by far the most
test suites use are rock solid, have a good API and hardly ever break.
Also: the quality of the "user experience" and the documentation has
improved vastly in the last few years.

Just today I had the chance to pair program some tests to introduce a
colleague to pytest. Seeing the expression of delight in their face, when
they realized how easy it is to get started and when they started to
comprehend the power of fixtures and parametrization is priceless.

Long story short: you folks are amazing and pytest is something to be
extremely proud of despite all the pain that is always involved when trying
to pay off technical debt without breaking the word.

The release automation that is in place now makes more frequent releases
easier and from my own experience I agree with Brunos suggestion to make
even more frequent releases that contain smaller changesets and also to not
shy away from more frequent major releases, if that makes the transition
easier.

Thanks that you care and thanks for all your work
Oliver

On Wed, 7 Nov 2018 at 20:56 Bruno Oliveira  wrote:

> Hi Ronny,
>
> On Wed, Nov 7, 2018 at 7:12 AM Ronny Pfannschmidt <
> opensou...@ronnypfannschmidt.de> wrote:
>
>>
>> ...
>
>
>>
>> This is an accumulative cost in many ways - in particular for a project
>> driven primarily by volunteers - every hour we sacrafice to this altar
>> of technical debt is an hour lost for improving the project and/or
>> working on actual features.
>>
>
> I feel your frustration. I agree that the pytest codebase needs some
> refactorings in order for it to be maintainable and allow us to move
> forward.
>
> From my perspective this issue directly grows out of driving a large
>> part of pytests development by examples and tests, but precluding
>> stepping back and doing actual design.
>>
>> The history of marks makes a perfect example of such an horror storry.
>> Each iteration adding a new minimal element while adding a huge factor
>> to the structural error as it grew.
>>
>
> What I think often happens is that we can't foresee that a minimal
> increment might lead to a large technical debt in the future. Once we put
> something in the open, we try very hard to not change that behavior (even
> if considered incorrect now), which is the main point of your email.
>
>
>> I really want to hammer down there that "minimal" is very different
>> from "minimal viable" - leaving design uncontested for too long is an
>> ramp up for unsustainable technical debt.
>>
>> Its aslo critical to note that for **me** there is a inherent
>> dishonesty in trying to stay backward compatible and not putting
>> forward a design and development process that deeply supports it -
>> right now we can observe a state of fragility from pytest where it
>> feels like every feature release triggers some regression - while at
>> the same time we keep and keep shipping features that are structurally
>> and fundamentally broken since years (yield tests, config init, ...).
>>
>
> I agree about the fact that every feature release we end up breaking
> something unintentionally. Of course that sometimes will happen, but I feel
> that happens more often in the murky areas of the code which have grown
> organically over the years.
>
> This setup, which gives me the impression it is "designed" to make the
>> project fail its user (aka its broken to begin with and now it will
>> break some more), is a massive emotional drain. It painfully twists
>> around the sense of responsibility simply due to the perceived inherent
>> base-level of failure - and **I** want to do and feel better.
>>
>> However with the current flow of releases and with our backward
>> compatibility policies in place i am under a very general impression

Re: [pytest-dev] Improving pytest internal errors and messages

[Oliver Bestwalter]

Glad to help Oliveira ;)

On Thu, 4 Oct 2018 at 21:28 Bruno Oliveira  wrote:

> Hi Walter ;)
>
> On Thu, Oct 4, 2018 at 4:21 PM Oliver Bestwalter 
> wrote:
>
>> About the naming things problem: I don't know if this is overkill, but
>> how about having an exception like e.g. ReportableError or KnownError that
>> errors like using an invalid scope in your example can inherit from (e.g.
>> InvalidScope) can inherit from. All errors inheriting from that
>> ReportableError or KnownError could then be caught at the top level and be
>> reported differently without a noisy traceback (e.g. only printing out the
>> place where it occured and the error type and message).
>>
>
> I think ReportableError is a good name, as I'm having a hard time coming
> up with a good name that isn't similar to UsageError/UserError. :)
>
> Cheers,
> Bruno.
>
>
>>
>>
>> On Thu, 4 Oct 2018 at 15:51 Florian Bruhin  wrote:
>>
>>> Hey,
>>>
>>> On Thu, Oct 04, 2018 at 10:19:21AM -0300, Bruno Oliveira wrote:
>>> > This new exception type (I've used UsageError on my PR just for proof
>>> of
>>> > concept) should be part of the public API so plugins can also use it.
>>> >
>>> > I'm writing to the ML because it would be beneficial to get feedback
>>> from a
>>> > larger audience about what the *name* of the exception should be.
>>> >
>>> > UserError? InternalError?
>>>
>>> I dislike both, but without having a better idea (sorry :D). Here's why:
>>>
>>> UsageError is dangerously close to UsageError. It's also not clear
>>> from the name why they differ.
>>>
>>> InternalError sounds like the exceptions prefixed with INTERNALERROR>,
>>> (i.e. unhandled exceptions inside pytest), which seems like the exact
>>> opposite of what this is.
>>>
>>> Maybe we should rename UsageError to CliUsageError, or make sure
>>> UsageError is usable for this purpose?
>>>
>>> Florian
>>>
>>> --
>>> https://www.qutebrowser.org | m...@the-compiler.org (Mail/XMPP)
>>>GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
>>>  I love long mails! | https://email.is-not-s.ms/
>>>
>> ___
>>> pytest-dev mailing list
>>> pytest-dev@python.org
>>> https://mail.python.org/mailman/listinfo/pytest-dev
>>>
>>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Improving pytest internal errors and messages

[Oliver Bestwalter]

Hi,

I think this is a great idea.

About the naming things problem: I don't know if this is overkill, but how
about having an exception like e.g. ReportableError or KnownError that
errors like using an invalid scope in your example can inherit from (e.g.
InvalidScope) can inherit from. All errors inheriting from that
ReportableError or KnownError could then be caught at the top level and be
reported differently without a noisy traceback (e.g. only printing out the
place where it occured and the error type and message).

Cheers,
Oliver


On Thu, 4 Oct 2018 at 15:51 Florian Bruhin  wrote:

> Hey,
>
> On Thu, Oct 04, 2018 at 10:19:21AM -0300, Bruno Oliveira wrote:
> > This new exception type (I've used UsageError on my PR just for proof of
> > concept) should be part of the public API so plugins can also use it.
> >
> > I'm writing to the ML because it would be beneficial to get feedback
> from a
> > larger audience about what the *name* of the exception should be.
> >
> > UserError? InternalError?
>
> I dislike both, but without having a better idea (sorry :D). Here's why:
>
> UsageError is dangerously close to UsageError. It's also not clear
> from the name why they differ.
>
> InternalError sounds like the exceptions prefixed with INTERNALERROR>,
> (i.e. unhandled exceptions inside pytest), which seems like the exact
> opposite of what this is.
>
> Maybe we should rename UsageError to CliUsageError, or make sure
> UsageError is usable for this purpose?
>
> Florian
>
> --
> https://www.qutebrowser.org | m...@the-compiler.org (Mail/XMPP)
>GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
>  I love long mails! | https://email.is-not-s.ms/
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Plans for Europython 2019?

[Oliver Bestwalter]

Hey,


On 4/24/19 9:44 PM, Florian Bruhin wrote:>
> Any other pytest-related plans? Oliver, do you plan to host another 
helpdesk

> like in 2017/2018?

Yes, I will propose doing a pytest/tox/devpi helpdesk again.

I would also love to assist you with your training (like helping 
participants during the exercises).


Last year I had to leave early, but the two years before I organized a 
sprint (tox). This time I would also like to do that again but we could 
broaden the scope to pytest, tox [and pluggy] if there are also folks 
who are more into pytest that like to help. From my former experiences I 
am usually pretty depleted after a full conference week but still have 
enough juice to hang out at the sprint venue and help with onboarding 
new contributors, answering questions, etc.


Cheers.
Oliver

P.S. good luck for your last tests!

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Plans for Europython 2019?

[Oliver Bestwalter]

Hi Florian,

On Thu, 25 Apr 2019 at 11:22, Florian Bruhin  wrote:
> Yay! Feel free to add me there as well if you want:

Great. Will do.

> I'll definitely need some helpers again, thanks for the offer! Apparently the
> training rooms have a capacity of 100 seats, and at least 2015/2016 there were
> quite a few participants.

That's what I thought. I could imagine, you'll might fill the room
with the growing interest around testing nowadays.

> Good idea! If there are some qutebrowser users visiting the conference I might
> do a sprint on that, but if not, I'm happy to help out with pytest and 
> friends!

ok, sounds good :)

Cheers,
Oliver
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev