Re: [pytest-dev] T-Shirt has arrived!

[Tom Viner]

Aha, thanks for explaining!

And what a splendid idea Vasily.

On 4 November 2016 at 13:10,  wrote:

> Yes, indeed the print is supposed to be on the back. It was Brianna's
> suggestion to make it so. The thing is, when a girl is wearing a t-shirt
> with some elaborate writing on the front, it gets awkward when people try
> to read it. I totally sympathise with that. Printing the test results on
> the back, on the other hand, allows anyone to discreetly assure themselves
> that your garment is working correctly ;)
>
> Cheers,
> Vasily
>
> P.S. The disadvantage of the print on the back, though, is that I can't
> see
> your faces in the pictures... perhaps we should have another sprint to take
> care of this.
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

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

[Tom Viner]

Hi Ronny,

Any plans to move detox as well? I've found that along with a local devpi
as a cache it can really speed up tox runs that have many envs.

It currently lives at:
https://bitbucket.org/hpk42/detox

Either way, I note that the PyPi description (
https://pypi.python.org/pypi/detox/ ) is now outdated as it links to the
tox issues on bitbucket, so I've made a PR to fix that:
https://bitbucket.org/hpk42/detox/pull-requests/5/

Cheers,
Tom

Date: Sat, 17 Sep 2016 22:14:09 +0200
> From: Ronny Pfannschmidt 
> 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

Re: [pytest-dev] On-the-ground sprint communication

[Tom Viner]

On 15 June 2016 at 10:45,  wrote:

> Date: Wed, 15 Jun 2016 11:45:25 +0200
> From: Florian Bruhin 
>
> > Signal or WhatsApp group chat? Something else?
>
> For easier written communication at the sprint (i.e. with everyone
> there) I suggest IRC, because many already have that set up and it's
> the lowest common denominator.
>
> As for before that, I know Holger uses Signal, and I use Telegram and
> Threema as well. Or XMPP/IRC. Then again I probably won't find my
> German SIM card anyways so I won't have any internet connection ;)
>
> Florian
>

Ok, let's go with Signal then. I've put my number here:
https://github.com/tomviner/pytest/wiki/On-the-ground-comms-for-sprint-2016

I'll tune into the irc too.
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] On-the-ground sprint communication

[Tom Viner]

Hi all,

I'm arriving in Freiburg Saturday afternoon, and wondering how best to
communicate for arranging meeting up and getting dinner / Sunday activities
etc.

Some app that makes my phone beep upon receiving a message would be handy
:-)

Signal or WhatsApp group chat? Something else?

Looking forward to seeing everyone and some German cuisine!

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

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

[Tom Viner]

>
> > while doing that i'd also like to turn the assertion rewriter into a
> > package exposing a minimal api
> > that way its releases can be done more in lock with python releases
> >
> > also its possible for others to use it and contribute to it
>

Michael Foord (maintainer of unittest) wondered about this possibility when
assertion rewriting was added 5 years ago:

http://pybites.blogspot.co.uk/2011/07/behind-scenes-of-pytests-new-assertion.html?showComment=1310466554325#c8180305815700456332
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Sprint participants writing a blog post?

[Tom Viner]

>
> Date: Sun, 21 Feb 2016 01:24:55 +
> From: Bruno Oliveira <nicodde...@gmail.com>
> Subject: Re: [pytest-dev] Sprint participants writing a blog post?
>
> On Sat, Feb 20, 2016 at 9:16 PM Tom Viner <t...@viner.tv> wrote:
>
> > Date: Sat, 20 Feb 2016 22:41:50 +1100
> >> From: Brianna Laugher <brianna.laug...@gmail.com>
> >
> >
> >>
> >> Who's up next...Raphael? Floris? Florian? Holger? Are you all working on
> >> posts? :P
> >>
> >
> > Me! :-) Here's a draft post introducing myself and explaining why I've
> > signed up. Feedback welcome!
> >
> > http://tomviner.co.uk/drafts/pytest-and-i-time-for-a-sprint.html
> >
>
> Nice post Tom! Good idea mentioning the adopt pytest month, nice touch! :)
>
> Bruno
>

Thanks Bruno. Published:
http://tomviner.co.uk/pytest-and-i-time-for-a-sprint.html
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Enabling viewing of rewritten AST trees as Python

[Tom Viner]

To update on this topic, I've now published a pytest plugin to display the
rewritten AST as Python:
https://github.com/tomviner/pytest-ast-back-to-python

Not sure if it will ever come in handy, but it was interesting to create my
first pytest plugin anyway! Keep it in mind as an option, if we get any
bugs with assertion rewriting.

It works like this:

As an example take a trivial test like:

def test_simple():
a = 1
b = 2
assert 1 + 2 == 3

View the rewritten AST as Python like this:

$ py.test --show-ast-as-python test_simple.py
 test session starts

plugins: ast-back-to-python-0.1.0, cov-2.2.1
collected 1 items

test_simple.py .
 Rewritten AST as Python

import builtins as @py_builtins
import _pytest.assertion.rewrite as @pytest_ar

def test_simple():
a = 1
b = 2
@py_assert0 = 1
@py_assert2 = 2
@py_assert4 = @py_assert0 + @py_assert2
@py_assert6 = 3
@py_assert5 = @py_assert4 == @py_assert6
if not @py_assert5:
@py_format8 = @pytest_ar._call_reprcompare(('==',), (@py_assert5,),
('(%(py1)s + %(py3)s) == %(py7)s',), (@py_assert4, @py_assert6)) % {'py3':
@pytest_ar._saferepr(@py_assert2), 'py1':
@pytest_ar._saferepr(@py_assert0), 'py7': @pytest_ar._saferepr(@py_assert6)}
@py_format10 = ('' + 'assert %(py9)s') % {'py9': @py_format8}
raise AssertionError(@pytest_ar._format_explanation(@py_format10))
@py_assert0 = @py_assert2 = @py_assert4 = @py_assert5 = @py_assert6 =
None

On 2 March 2015 at 09:06, Tom Viner <t...@viner.tv> wrote:

> One extra note:
>
> `py.test -s` is required to see rewritten AST output, even for failing
> tests, because the output comes while
> tests are being collected and rewritten, not during the execution of a
> test. So pytest's "show output upon
> fail" cannot help here.
>
> If anyone knows how to tie the output to particular tests, that would be
> great.
>
>
> On 1 March 2015 at 23:01, Tom Viner <t...@viner.tv> wrote:
>
>> Thanks for your ideas Floris, I've managed to get it working with
>> your pytest_configure suggestion.
>>
>> The only extra bit was having to disable reading the cached pyc files
>> that pytest writes, as these skip my monkeypatch.
>>
>> Take a look, it's simple to use:
>> https://gist.github.com/tomviner/c3537c2f2b2b8172f83e
>>
>> If there's any demand, I could easily make this a pip installable pytest
>> plugin.
>>
>> On 13 November 2014 at 23:34, Floris Bruynooghe <f...@devork.be> wrote:
>>
>>> Hi Tom,
>>>
>>> On 9 November 2014 19:18, Tom Viner <t...@viner.tv> wrote:
>>> > The four options I can think of to gain access to this variable:
>>> > - monkey patch rewrite.rewrite_asserts
>>> > - edit rewrite_asserts and paste in the logging code above:
>>> > -- temporarily, by each developer, on each occasion required
>>> > -- permanently, but only running when a certain debug flag is
>>> active
>>> > - expose the rewritten AST via a new hook
>>> >
>>> > monkey patch is my preferred option, because if I can make it work, a
>>> plugin
>>> > could be written. I just need some help to find an appropriate hook to
>>> do
>>> > the monkey patching before pytest gets going with the
>>> AssertionRewritingHook
>>> > and calls rewrite_asserts. Without knowledge of an early-running hook,
>>> I
>>> > could only get this working by patching rewrite_asserts then calling
>>> > pytest.main myself, see
>>> > https://gist.github.com/tomviner/13c95cdb1e159028fc0b
>>>
>>> Would this work by using monkeypatching, but using a method on
>>> _pytest.pytester.TmpTestDir which wraps around inline_run or
>>> inline_runsource?  That would seem like a fairly reasonable approach.
>>> It could simply skip with an appropriate message if the meta lib is
>>> importable and print the reversed python code to stdout for capsys to
>>> collect.
>>>
>>> If you would like to go the full plugin way I believe you just need to
>>> hook in before collection happens.  I imagine pytest_configure would
>>> be a reasonable hook for that, but have to admit I haven't tried it.
>>>
>>>
>>> Regards,
>>> Floris
>>>
>>
>>
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Sprint participants writing a blog post?

[Tom Viner]

>
> Date: Sat, 20 Feb 2016 22:41:50 +1100
> From: Brianna Laugher 
>
> Who's up next...Raphael? Floris? Florian? Holger? Are you all working on
> posts? :P
>

Me! :-) Here's a draft post introducing myself and explaining why I've
signed up. Feedback welcome!

http://tomviner.co.uk/drafts/pytest-and-i-time-for-a-sprint.html
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Google Summer Of Code

[Tom Viner]

Hi Florian,

I've seen some amazing things achieved with GSOCs. Take Django's Meta API
by Daniel Pyrathon [1] as a good example.

See here how Django GSOC devs/mentors wrote some really nice ideas for
students to pick from (including the Meta API idea) [2] [3].

[1]
https://www.google-melange.com/gsoc/project/details/google/gsoc2014/pirosb3/5649050225344512
[2] https://code.djangoproject.com/wiki/SummerOfCode2014
[3] https://code.djangoproject.com/wiki/SummerOfCode2015

Tom

On 10 February 2016 at 17:00,  wrote:

> Date: Wed, 10 Feb 2016 13:59:42 +0100
> From: Florian Bruhin 
> To: pytest-dev@python.org
> Subject: [pytest-dev] Google Summer Of Code
> Message-ID: <20160210125942.GJ10579@tonks>
> Content-Type: text/plain; charset="us-ascii"
>
> Hey,
>
> I was asked by qutebrowser users if I want to participate as an
> organization for Google's Summer Of Code - while I don't think it
> makes sense for a "smaller" project like qutebrowser, I think it'd
> make a lot of sense for pytest!
>
> The idea of GSoC is that opensource projects apply for it, then
> students apply to a given project, then contribute a significant
> amount of work (being mentored by project members) and in exchange get
> a stipend (~USD 5000) from Google.
>
> Applications are open until Feburary 19th (Friday in a week...) - what
> about trying with pytest?
>
> What we'd need are two (or more) administrative organisators (I'd
> volunteer) and mentors.
>
> The PSF is also available as an umbrella organization:
> https://wiki.python.org/moin/SummerOfCode/2016
>
> What do you think?
>
> Florian
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] re-running pytest on file changes

[Tom Viner]

I find it really helps TDD to have my tests run automatically whenever I
change either a test or the code itself. I set my editor (Sublime Text 3)
to auto save upon defocus, so it's actually impossible to avoid a test
rerun whenever I alter a file and move on or hit save.

For this, I regularly use Jonathan Hartley's rerun Python library[0] which
gives the ability to wrap my py.test or tox command like so:

rerun --ignore sqlite.db py.test tests/

The --ignore part is very important, as different test suites end up
altering various working directory files, and if you can't select
files/folders (file patterns would be even better) to ignore, you end up in
an un-pausing loop of test reruns.

I hadn't heard of looponchange can it ignore certain files/folders?

[0] https://pypi.python.org/pypi/rerun



 --

 Message: 1
 Date: Fri, 27 Mar 2015 14:55:31 +
 From: Tibor Arpas tibor.ar...@infinit.sk
 To: pytest-dev@python.org pytest-dev@python.org
 Subject: [pytest-dev] re-running pytest on file changes
 Message-ID:
 
 cadi_wy3cbdaofds8+ov5irof6qzvjsx+_psmcbk-ss1uobg...@mail.gmail.com
 Content-Type: text/plain; charset=utf-8

 Hi,

 I'm trying to wrap my head around this subject.

 Is there a strong reason why the -f looponfail option is inside a plug-in?
 My hunch would be to do it as a separate, flexible, command, but that's
 just feelings without any experience.

 Poll: Do you guys use looponfail? Has it been working good? Does it play
 nice with other tasks you might want to do on file changes? What other
 tools do you use for repeated tasks on source code changes?

 What's the situation at the moment with --looponfail and --looponchange? Is
 it going to be inside pytest_cache which will go into core? Or it will be a
 different plug-in?

 I've seen
 https://bitbucket.org/pytest-dev/pytest/commits/b5727cc6632c/

 and the take in cache PR.


 Tibor
 P.S. some more thoughts about the same functionality are here:
 https://github.com/tarpas/testmon/issues/4
 and a script whith callbacks for every success and failure:
 https://github.com/blueyed/testmon/blob/tmon-improvements/testmon/tmon.py
 -- next part --
 An HTML attachment was scrubbed...
 URL: 
 http://mail.python.org/pipermail/pytest-dev/attachments/20150327/a09d699c/attachment-0001.html
 

 --

 Subject: Digest Footer

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


 --

 End of pytest-dev Digest, Vol 28, Issue 22
 **

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