From tetsuya.morimoto at gmail.com  Sat Jun  2 13:15:33 2012
From: tetsuya.morimoto at gmail.com (Tetsuya Morimoto)
Date: Sat, 2 Jun 2012 20:15:33 +0900
Subject: [py-dev] pytest documents with Japanese translation
In-Reply-To: <CAGBzy2rxp8YdMBzu6+ABbJ9_DsKfiFLXXhd6gL4EaoPx8iVwsA@mail.gmail.com>
References: <CAGBzy2pGt6BYo41G9Vui5FmQaLCOGe2RveJhp6KEky6hn+VPMw@mail.gmail.com>
	<20120420034520.GG10174@merlinux.eu>
	<CAGBzy2p9Y7y9HPF56orDRM_mSC5NEW7YZew_HZ9+ODKjExgd2g@mail.gmail.com>
	<20120529141351.GE10174@merlinux.eu>
	<CAGBzy2rxp8YdMBzu6+ABbJ9_DsKfiFLXXhd6gL4EaoPx8iVwsA@mail.gmail.com>
Message-ID: <CAGBzy2qToPaOAMS738XN9Rtwus7W4ErzzN7ncp=h_0-JccjskA@mail.gmail.com>

Hi Holger,

I merged the changes of 2.2.4 into my translation repository. I mean
it's available to send a pull request.
https://bitbucket.org/t2y/pytest-ja

I think it's better to send a pull request from me after you
reorganize the docs directory in your repository. Maybe, I re-fork
pytest repository to drop the named branch for translation, anyway, I
will follow your way.

thanks,
Tetsuya

On Wed, May 30, 2012 at 12:07 AM, Tetsuya Morimoto
<tetsuya.morimoto at gmail.com> wrote:
> Hi Holger,
>
> Thanks for remembering the translation! :)
>
>> Does this also make sense to you? ?If so, it'd be great if you could
>> submit a pull request that reorganises pytest's docs accordingly,
>> preferably starting from the current trunk.
> Yes, it makes sense for me. I have experienced a similar work for
> virtualenvwrapper. That might be an informative.
>
> http://www.doughellmann.com/docs/virtualenvwrapper/index.html
> http://www.doughellmann.com/docs/virtualenvwrapper/ja/index.html
> https://bitbucket.org/dhellmann/virtualenvwrapper/src/e1a05e751a56/docs
>
>> There weren't much changes
>> between 2.2.3 and 2.2.4 in the doc directory, anyway.
> OK! I will update the Japanese translation and submit a pull request!
>
>> I'll take care to push the docs to pytest.org - maybe using a scheme like this:
>>
>> ? ?pytest.org/VER/... # for english documentation
>> ? ?pytest.org/en/VER ?# for english documentation
>> ? ?pytest.org/ja/VER ?# for japanese documentation
>>
>> where VER is a version number and "latest" could point to the latest number.
> It looks nice. I agree with you.
>
>> that there is another error i am not sure about at the moment.
>> Maybe Ronny can take a look.
> I see. I will talk to Ronny later.
>
> thanks,
> Tetsuya
>
> On Tue, May 29, 2012 at 11:13 PM, holger krekel <holger at merlinux.eu> wrote:
>> Hi Tetsuya,
>>
>> On Mon, Apr 23, 2012 at 03:43 +0900, Tetsuya Morimoto wrote:
>>> Hi Holger,
>>>
>>> Thanks for thinking about Japanese translation.
>>
>> sorry for taking a while.
>>
>>> > * how do the eventual URLs look like? Maybe pytest.org/latest-jp/...?
>>> > ?instead of pytest.org/latest/ ?
>>> > ?I'd definitely like to keep existing URLs working.
>>> It's good idea and I suggest "latest-ja" is proper than "latest-jp"
>>> since "jp" is the country code.
>>
>> I think the eventual URL is not a big problem. ?We just need to take
>> care that it is compatible with the existing scheme, i.e. allows existing
>> URLs to remain valid.
>>
>>> > * how to organise the repository so that both EN and JP are included
>>> > ?(without the need to have a branch)
>>> I forked original branch for Japanese translation and made named
>>> branch to represent the version, but do you want to manage the
>>> translation in original repository? If so, I know Sphinx has i18n
>>> feature using gettext since 1.1. Is this useful for your purpose?
>>> http://sphinx.pocoo.org/latest/intl.html
>>
>> I think what we need is something along those lines:
>>
>> http://mark-story.com/posts/view/creating-multi-language-documentation-with-sphinx
>>
>> Does this also make sense to you? ?If so, it'd be great if you could
>> submit a pull request that reorganises pytest's docs accordingly,
>> preferably starting from the current trunk. ?There weren't much changes
>> between 2.2.3 and 2.2.4 in the doc directory, anyway.
>>
>> I think we'd end up with something like:
>>
>> ? ?pytest/
>> ? ? ? ?doc/
>> ? ? ? ? ? ?en/
>> ? ? ? ? ? ? ? ?# current english files and dirs
>> ? ? ? ? ? ?ja/
>> ? ? ? ? ? ? ? ?# current japanese files and dirs
>>
>> I'll take care to push the docs to pytest.org - maybe using a scheme like this:
>>
>> ? ?pytest.org/VER/... # for english documentation
>> ? ?pytest.org/en/VER ?# for english documentation
>> ? ?pytest.org/ja/VER ?# for japanese documentation
>>
>> where VER is a version number and "latest" could point to the latest number.
>>
>>> > * do we need to do anything special wrt to the examples and their
>>> > ?generation? (we use a tool called 'regendoc' written by ronny which
>>> > ?regenerates the example outputs)
>>> I used original example code with document, so the example's version
>>> are "pytest-2.2.2"? And then, I tried to run regen (make regen), but I
>>> got an error. It seems regenerating has an encoding issue.
>>>
>>> (sphinx)$ make regen
>>> PYTHONDONTWRITEBYTECODE=1 COLUMNS=76 regendoc --update *.txt */*.txt
>>> ===== checking apiref.txt =====
>>> Traceback (most recent call last):
>>> ? File "/Users/t2y/.virtualenvs/sphinx/bin/regendoc", line 9, in <module>
>>> ? ? load_entry_point('RegenDoc==0.2.dev1', 'console_scripts', 'regendoc')()
>>> ? File "/Users/t2y/work/python/regendoc/regendoc.py", line 201, in main
>>> ? ? return _main(options.files, should_update=options.update)
>>> ? File "/Users/t2y/work/python/regendoc/regendoc.py", line 196, in _main
>>> ? ? path.write(corrected)
>>> ? File "/Users/t2y/.virtualenvs/sphinx/lib/python2.7/site-packages/py/_path/local.py",
>>> line 385, in write
>>> ? ? data = py.builtin._totext(data, sys.getdefaultencoding())
>>> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position
>>> 22: ordinal not in range(128)
>>> make: *** [regen] Error 1
>>
>> One problem is that regendoc.py:196 should call "path.write(corrected,
>> 'wb')" in order to write out bytes and inhibit conversions. But after
>> that there is another error i am not sure about at the moment.
>> Maybe Ronny can take a look.
>>
>> best,
>> holger
>>
>>> thanks,
>>> Tetsuya
>>>
>>> On Fri, Apr 20, 2012 at 12:45 PM, holger krekel <holger at merlinux.eu> wrote:
>>> > Hi Tetsuya,
>>> >
>>> > thanks for your work already!
>>> >
>>> > i guess we need to work a bit to have both language versions
>>> > generated. ?I haven't looked at your branch yet but i guess
>>> > we need to solve a few issues:
>>> >
>>> > * how do the eventual URLs look like? Maybe pytest.org/latest-jp/...?
>>> > ?instead of pytest.org/latest/ ?
>>> > ?I'd definitely like to keep existing URLs working.
>>> >
>>> > * how to organise the repository so that both EN and JP are included
>>> > ?(without the need to have a branch)
>>> >
>>> > * do we need to do anything special wrt to the examples and their
>>> > ?generation? (we use a tool called 'regendoc' written by ronny which
>>> > ?regenerates the example outputs)
>>> >
>>> > best,
>>> > holger
>>> >
>>> >
>>> > On Mon, Apr 16, 2012 at 16:24 +0900, Tetsuya Morimoto wrote:
>>> >> Hi,
>>> >>
>>> >> I finished translating pytest documents English to Japanese. My
>>> >> repository is below and I made the named branch "2.2.3-ja" for
>>> >> translating docs.
>>> >>
>>> >> https://bitbucket.org/t2y/pytest-ja
>>> >>
>>> >> I would like to publish this Japanese translation on pytest.org with
>>> >> some ways. But, I don't know it's possible or not, and how to deploy
>>> >> the current docs. I think putting original and translated docs
>>> >> separately is easy deployment to avoid some conflicts. Of course,
>>> >> other suggestions are welcome.
>>> >>
>>> >> Additionally, I can maintain Japanese docs in the future. So, I can
>>> >> work by myself if you give me needed permission.
>>> >>
>>> >> thanks,
>>> >> Tetsuya
>>> >> _______________________________________________
>>> >> py-dev mailing list
>>> >> py-dev at codespeak.net
>>> >> http://codespeak.net/mailman/listinfo/py-dev
>>> >>
>>> _______________________________________________
>>> py-dev mailing list
>>> py-dev at codespeak.net
>>> http://codespeak.net/mailman/listinfo/py-dev


From holger at merlinux.eu  Sat Jun  2 13:35:11 2012
From: holger at merlinux.eu (holger krekel)
Date: Sat, 2 Jun 2012 11:35:11 +0000
Subject: [py-dev] pytest documents with Japanese translation
In-Reply-To: <CAGBzy2qToPaOAMS738XN9Rtwus7W4ErzzN7ncp=h_0-JccjskA@mail.gmail.com>
References: <CAGBzy2pGt6BYo41G9Vui5FmQaLCOGe2RveJhp6KEky6hn+VPMw@mail.gmail.com>
	<20120420034520.GG10174@merlinux.eu>
	<CAGBzy2p9Y7y9HPF56orDRM_mSC5NEW7YZew_HZ9+ODKjExgd2g@mail.gmail.com>
	<20120529141351.GE10174@merlinux.eu>
	<CAGBzy2rxp8YdMBzu6+ABbJ9_DsKfiFLXXhd6gL4EaoPx8iVwsA@mail.gmail.com>
	<CAGBzy2qToPaOAMS738XN9Rtwus7W4ErzzN7ncp=h_0-JccjskA@mail.gmail.com>
Message-ID: <20120602113511.GC11942@merlinux.eu>

Hi Tetsuya,

On Sat, Jun 02, 2012 at 20:15 +0900, Tetsuya Morimoto wrote:
> Hi Holger,
> 
> I merged the changes of 2.2.4 into my translation repository. I mean
> it's available to send a pull request.
> https://bitbucket.org/t2y/pytest-ja
> 
> I think it's better to send a pull request from me after you
> reorganize the docs directory in your repository. Maybe, I re-fork
> pytest repository to drop the named branch for translation, anyway, I
> will follow your way.

Can you imagine to do the doc reorganisation yourself?  This way there
is no need for a named branch - you could just do the final sub
directory layout as discussed in the last mail.  I would care for the
"push-to-website" bit and the apache side reconfiguration.

best,
holger


> thanks,
> Tetsuya
> 
> On Wed, May 30, 2012 at 12:07 AM, Tetsuya Morimoto
> <tetsuya.morimoto at gmail.com> wrote:
> > Hi Holger,
> >
> > Thanks for remembering the translation! :)
> >
> >> Does this also make sense to you? ?If so, it'd be great if you could
> >> submit a pull request that reorganises pytest's docs accordingly,
> >> preferably starting from the current trunk.
> > Yes, it makes sense for me. I have experienced a similar work for
> > virtualenvwrapper. That might be an informative.
> >
> > http://www.doughellmann.com/docs/virtualenvwrapper/index.html
> > http://www.doughellmann.com/docs/virtualenvwrapper/ja/index.html
> > https://bitbucket.org/dhellmann/virtualenvwrapper/src/e1a05e751a56/docs
> >
> >> There weren't much changes
> >> between 2.2.3 and 2.2.4 in the doc directory, anyway.
> > OK! I will update the Japanese translation and submit a pull request!
> >
> >> I'll take care to push the docs to pytest.org - maybe using a scheme like this:
> >>
> >> ? ?pytest.org/VER/... # for english documentation
> >> ? ?pytest.org/en/VER ?# for english documentation
> >> ? ?pytest.org/ja/VER ?# for japanese documentation
> >>
> >> where VER is a version number and "latest" could point to the latest number.
> > It looks nice. I agree with you.
> >
> >> that there is another error i am not sure about at the moment.
> >> Maybe Ronny can take a look.
> > I see. I will talk to Ronny later.
> >
> > thanks,
> > Tetsuya
> >
> > On Tue, May 29, 2012 at 11:13 PM, holger krekel <holger at merlinux.eu> wrote:
> >> Hi Tetsuya,
> >>
> >> On Mon, Apr 23, 2012 at 03:43 +0900, Tetsuya Morimoto wrote:
> >>> Hi Holger,
> >>>
> >>> Thanks for thinking about Japanese translation.
> >>
> >> sorry for taking a while.
> >>
> >>> > * how do the eventual URLs look like? Maybe pytest.org/latest-jp/...?
> >>> > ?instead of pytest.org/latest/ ?
> >>> > ?I'd definitely like to keep existing URLs working.
> >>> It's good idea and I suggest "latest-ja" is proper than "latest-jp"
> >>> since "jp" is the country code.
> >>
> >> I think the eventual URL is not a big problem. ?We just need to take
> >> care that it is compatible with the existing scheme, i.e. allows existing
> >> URLs to remain valid.
> >>
> >>> > * how to organise the repository so that both EN and JP are included
> >>> > ?(without the need to have a branch)
> >>> I forked original branch for Japanese translation and made named
> >>> branch to represent the version, but do you want to manage the
> >>> translation in original repository? If so, I know Sphinx has i18n
> >>> feature using gettext since 1.1. Is this useful for your purpose?
> >>> http://sphinx.pocoo.org/latest/intl.html
> >>
> >> I think what we need is something along those lines:
> >>
> >> http://mark-story.com/posts/view/creating-multi-language-documentation-with-sphinx
> >>
> >> Does this also make sense to you? ?If so, it'd be great if you could
> >> submit a pull request that reorganises pytest's docs accordingly,
> >> preferably starting from the current trunk. ?There weren't much changes
> >> between 2.2.3 and 2.2.4 in the doc directory, anyway.
> >>
> >> I think we'd end up with something like:
> >>
> >> ? ?pytest/
> >> ? ? ? ?doc/
> >> ? ? ? ? ? ?en/
> >> ? ? ? ? ? ? ? ?# current english files and dirs
> >> ? ? ? ? ? ?ja/
> >> ? ? ? ? ? ? ? ?# current japanese files and dirs
> >>
> >> I'll take care to push the docs to pytest.org - maybe using a scheme like this:
> >>
> >> ? ?pytest.org/VER/... # for english documentation
> >> ? ?pytest.org/en/VER ?# for english documentation
> >> ? ?pytest.org/ja/VER ?# for japanese documentation
> >>
> >> where VER is a version number and "latest" could point to the latest number.
> >>
> >>> > * do we need to do anything special wrt to the examples and their
> >>> > ?generation? (we use a tool called 'regendoc' written by ronny which
> >>> > ?regenerates the example outputs)
> >>> I used original example code with document, so the example's version
> >>> are "pytest-2.2.2"? And then, I tried to run regen (make regen), but I
> >>> got an error. It seems regenerating has an encoding issue.
> >>>
> >>> (sphinx)$ make regen
> >>> PYTHONDONTWRITEBYTECODE=1 COLUMNS=76 regendoc --update *.txt */*.txt
> >>> ===== checking apiref.txt =====
> >>> Traceback (most recent call last):
> >>> ? File "/Users/t2y/.virtualenvs/sphinx/bin/regendoc", line 9, in <module>
> >>> ? ? load_entry_point('RegenDoc==0.2.dev1', 'console_scripts', 'regendoc')()
> >>> ? File "/Users/t2y/work/python/regendoc/regendoc.py", line 201, in main
> >>> ? ? return _main(options.files, should_update=options.update)
> >>> ? File "/Users/t2y/work/python/regendoc/regendoc.py", line 196, in _main
> >>> ? ? path.write(corrected)
> >>> ? File "/Users/t2y/.virtualenvs/sphinx/lib/python2.7/site-packages/py/_path/local.py",
> >>> line 385, in write
> >>> ? ? data = py.builtin._totext(data, sys.getdefaultencoding())
> >>> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position
> >>> 22: ordinal not in range(128)
> >>> make: *** [regen] Error 1
> >>
> >> One problem is that regendoc.py:196 should call "path.write(corrected,
> >> 'wb')" in order to write out bytes and inhibit conversions. But after
> >> that there is another error i am not sure about at the moment.
> >> Maybe Ronny can take a look.
> >>
> >> best,
> >> holger
> >>
> >>> thanks,
> >>> Tetsuya
> >>>
> >>> On Fri, Apr 20, 2012 at 12:45 PM, holger krekel <holger at merlinux.eu> wrote:
> >>> > Hi Tetsuya,
> >>> >
> >>> > thanks for your work already!
> >>> >
> >>> > i guess we need to work a bit to have both language versions
> >>> > generated. ?I haven't looked at your branch yet but i guess
> >>> > we need to solve a few issues:
> >>> >
> >>> > * how do the eventual URLs look like? Maybe pytest.org/latest-jp/...?
> >>> > ?instead of pytest.org/latest/ ?
> >>> > ?I'd definitely like to keep existing URLs working.
> >>> >
> >>> > * how to organise the repository so that both EN and JP are included
> >>> > ?(without the need to have a branch)
> >>> >
> >>> > * do we need to do anything special wrt to the examples and their
> >>> > ?generation? (we use a tool called 'regendoc' written by ronny which
> >>> > ?regenerates the example outputs)
> >>> >
> >>> > best,
> >>> > holger
> >>> >
> >>> >
> >>> > On Mon, Apr 16, 2012 at 16:24 +0900, Tetsuya Morimoto wrote:
> >>> >> Hi,
> >>> >>
> >>> >> I finished translating pytest documents English to Japanese. My
> >>> >> repository is below and I made the named branch "2.2.3-ja" for
> >>> >> translating docs.
> >>> >>
> >>> >> https://bitbucket.org/t2y/pytest-ja
> >>> >>
> >>> >> I would like to publish this Japanese translation on pytest.org with
> >>> >> some ways. But, I don't know it's possible or not, and how to deploy
> >>> >> the current docs. I think putting original and translated docs
> >>> >> separately is easy deployment to avoid some conflicts. Of course,
> >>> >> other suggestions are welcome.
> >>> >>
> >>> >> Additionally, I can maintain Japanese docs in the future. So, I can
> >>> >> work by myself if you give me needed permission.
> >>> >>
> >>> >> thanks,
> >>> >> Tetsuya
> >>> >> _______________________________________________
> >>> >> py-dev mailing list
> >>> >> py-dev at codespeak.net
> >>> >> http://codespeak.net/mailman/listinfo/py-dev
> >>> >>
> >>> _______________________________________________
> >>> py-dev mailing list
> >>> py-dev at codespeak.net
> >>> http://codespeak.net/mailman/listinfo/py-dev
> 


From holger at merlinux.eu  Mon Jun  4 11:10:55 2012
From: holger at merlinux.eu (holger krekel)
Date: Mon, 4 Jun 2012 09:10:55 +0000
Subject: [py-dev] Performance tests with py.test
In-Reply-To: <CAFHN2SM=GwcRO1unZwQPL5pV5=kMPnFdt_-8x4ptzRGhkRwHcQ@mail.gmail.com>
References: <CAFHN2SOkDfn+nQ-30JydGKOWwWC8VwFxB9wWURVu=aFqTLtNRw@mail.gmail.com>
	<20120401022159.GZ26028@merlinux.eu>
	<CAFHN2SM=GwcRO1unZwQPL5pV5=kMPnFdt_-8x4ptzRGhkRwHcQ@mail.gmail.com>
Message-ID: <20120604091055.GF11942@merlinux.eu>

Hi Bogdan,

sorry for taking a while ...

On Thu, May 03, 2012 at 11:18 +1000, Bogdan Opanchuk wrote:
> For some reason this message has not shown up in the list archives, so
> I'll resend it again.
> 
> On Sun, Apr 1, 2012 at 12:21 PM, holger krekel <holger at merlinux.eu> wrote:
> 
> > do you want to consider performance regressions as a failure?
> 
> Not really. I just need some table with performance results that I
> could get for different systems/versions and compare them. Besides,
> performance regressions can be implemented using existing
> functionality, because they do not have some continuous result
> associated with them ? only pass/fail.
> 
> > Could you maybe provide a simple example test file and make up
> > some example output that you'd like to see?
> 
> Sure. Consider the following test file:
> 
> -----
> import pytest
> 
> def test_matrixmul():
>    pass
> 
> @pytest.mark.perf('seconds')
> def test_reduce():
>    # <some lengthy preparation that I do not want to time>
>    # <actual work>
>    return 1.0
> 
> @pytest.mark.perf('GFLOPS')
> def test_fft():
>    # <again, some lengthy preparation that I do not want to time>
>    # <actual work>
>    return 1.0, 1e10
> -----
> 
> Here "test_matrixmul()" is a normal pass/fail test, "test_reduce()" is
> marked as performance test that returns execution time, and
> "test_fft()" is marked as a test that returns execution time + the
> number of operations (thus allowing us to calculate GFLOPS value).
> 
> I have put together a clunky solution (see the end of this letter)
> using existing hooks that gives me more or less what I want to see:
> 
> $ py.test -v
> ...
> test_test.py:3: test_matrixmul PASSED
> test_test.py:6: test_reduce 1.0 s
> test_test.py:10: test_fft 10.0 GFLOPS
> ...
> 
> The only problem here is that I have to explicitly increase verbosity
> level. I'd prefer 'perf' marked tests show their result even for
> default verbosity, but I haven't found a way to do it yet.

not sure it helps but are you aware that you can put 

    [pytest]
    addopts = -v

in a pytest.ini file?

> > Meanwhile, if you haven't already you might want to look at the output
> > of "py.test --durations=10" and see about its implementation (mostly
> > contained in _pytest/runner.py, grep for 'duration').
> 
> Yes, I know about it, but it is not quite what I need:
> - it measures the time of the whole testcase, while I usually need to
> time only specific part

right.  It differentiates between setup and runtest phases for a test, though.

> - it does not allow me to measure anything more complicated (e.g.
> GFLOPS, as another variant I may want to see the error value)
> - it prints its report after all the tests are finished, while it is
> much more convenient to see testcase result as soon as it is finished
> (my performance tests may run for quite a long time)

right.

> So, the solution I have now is shown below. "pytest_pyfunc_call()"
> implementation annoys me the most, because I had to copy-paste it from
> python.py, so it exposes some py.test internals and can easily break
> when something (seemingly hidden) inside the library is changed.

That's true.  If you want to open an issue about this (pytest_pyfunc_call
to return test function return value), i can see to care about it.

> -----
> def pytest_configure(config):
>    config.pluginmanager.register(PerfPlugin(config), '_perf')
> 
> class PerfPlugin(object):
> 
>    def __init__(self, config):
>        pass
> 
>    def pytest_pyfunc_call(self, __multicall__, pyfuncitem):
>        # collect testcase return result
>        testfunction = pyfuncitem.obj
>        if pyfuncitem._isyieldedfunction():
>            res = testfunction(*pyfuncitem._args)
>        else:
>            funcargs = pyfuncitem.funcargs
>            res = testfunction(**funcargs)
>        pyfuncitem.result = res
> 
>    def pytest_report_teststatus(self, __multicall__, report):
>        outcome, letter, msg = __multicall__.execute()
> 
>        # if we have some result attached to the testcase, print it
> instead of 'PASSED'
>        if hasattr(report, 'result'):
>            msg = report.result
> 
>        return outcome, letter, msg
> 
>    def pytest_runtest_makereport(self, __multicall__, item, call):
>        report = __multicall__.execute()
> 
>        # if the testcase has passed, and has 'perf' marker, process its results
>        if call.when == 'call' and report.passed and
> hasattr(item.function, 'perf'):
>            perf = item.function.perf
>            perftype = perf.args[0]
>            if perftype == 'seconds':
>                report.result = str(item.result) + " s"
>            else:
>                seconds, operations = item.result
>                report.result = str(operations / seconds / 1e9) + " GFLOPS"
> 
>        return report
> -----

We could also think about a convention that would allow setting
the short/longform (letter,msg) on the report object so that could
also get rid of the report_teststatus hook.  I am slightly less
inclined to go for this because the above teststatus bit seems
nice enough.

best,
holger





From tetsuya.morimoto at gmail.com  Wed Jun  6 02:07:07 2012
From: tetsuya.morimoto at gmail.com (Tetsuya Morimoto)
Date: Wed, 6 Jun 2012 09:07:07 +0900
Subject: [py-dev] pytest documents with Japanese translation
In-Reply-To: <20120602113511.GC11942@merlinux.eu>
References: <CAGBzy2pGt6BYo41G9Vui5FmQaLCOGe2RveJhp6KEky6hn+VPMw@mail.gmail.com>
	<20120420034520.GG10174@merlinux.eu>
	<CAGBzy2p9Y7y9HPF56orDRM_mSC5NEW7YZew_HZ9+ODKjExgd2g@mail.gmail.com>
	<20120529141351.GE10174@merlinux.eu>
	<CAGBzy2rxp8YdMBzu6+ABbJ9_DsKfiFLXXhd6gL4EaoPx8iVwsA@mail.gmail.com>
	<CAGBzy2qToPaOAMS738XN9Rtwus7W4ErzzN7ncp=h_0-JccjskA@mail.gmail.com>
	<20120602113511.GC11942@merlinux.eu>
Message-ID: <CAGBzy2r+ybKk4cwwEcJWt7j8ate91Nb0YAa2UHR2QMSMaus-9Q@mail.gmail.com>

Hi Holger,

I sent a pull request. Confirm it!

https://bitbucket.org/hpk42/pytest/pull-request/14/added-japanese-translation-documentation

thanks,
Tetsuya

On Sat, Jun 2, 2012 at 8:35 PM, holger krekel <holger at merlinux.eu> wrote:
> Hi Tetsuya,
>
> On Sat, Jun 02, 2012 at 20:15 +0900, Tetsuya Morimoto wrote:
>> Hi Holger,
>>
>> I merged the changes of 2.2.4 into my translation repository. I mean
>> it's available to send a pull request.
>> https://bitbucket.org/t2y/pytest-ja
>>
>> I think it's better to send a pull request from me after you
>> reorganize the docs directory in your repository. Maybe, I re-fork
>> pytest repository to drop the named branch for translation, anyway, I
>> will follow your way.
>
> Can you imagine to do the doc reorganisation yourself? ?This way there
> is no need for a named branch - you could just do the final sub
> directory layout as discussed in the last mail. ?I would care for the
> "push-to-website" bit and the apache side reconfiguration.
>
> best,
> holger
>
>
>> thanks,
>> Tetsuya
>>
>> On Wed, May 30, 2012 at 12:07 AM, Tetsuya Morimoto
>> <tetsuya.morimoto at gmail.com> wrote:
>> > Hi Holger,
>> >
>> > Thanks for remembering the translation! :)
>> >
>> >> Does this also make sense to you? ?If so, it'd be great if you could
>> >> submit a pull request that reorganises pytest's docs accordingly,
>> >> preferably starting from the current trunk.
>> > Yes, it makes sense for me. I have experienced a similar work for
>> > virtualenvwrapper. That might be an informative.
>> >
>> > http://www.doughellmann.com/docs/virtualenvwrapper/index.html
>> > http://www.doughellmann.com/docs/virtualenvwrapper/ja/index.html
>> > https://bitbucket.org/dhellmann/virtualenvwrapper/src/e1a05e751a56/docs
>> >
>> >> There weren't much changes
>> >> between 2.2.3 and 2.2.4 in the doc directory, anyway.
>> > OK! I will update the Japanese translation and submit a pull request!
>> >
>> >> I'll take care to push the docs to pytest.org - maybe using a scheme like this:
>> >>
>> >> ? ?pytest.org/VER/... # for english documentation
>> >> ? ?pytest.org/en/VER ?# for english documentation
>> >> ? ?pytest.org/ja/VER ?# for japanese documentation
>> >>
>> >> where VER is a version number and "latest" could point to the latest number.
>> > It looks nice. I agree with you.
>> >
>> >> that there is another error i am not sure about at the moment.
>> >> Maybe Ronny can take a look.
>> > I see. I will talk to Ronny later.
>> >
>> > thanks,
>> > Tetsuya
>> >
>> > On Tue, May 29, 2012 at 11:13 PM, holger krekel <holger at merlinux.eu> wrote:
>> >> Hi Tetsuya,
>> >>
>> >> On Mon, Apr 23, 2012 at 03:43 +0900, Tetsuya Morimoto wrote:
>> >>> Hi Holger,
>> >>>
>> >>> Thanks for thinking about Japanese translation.
>> >>
>> >> sorry for taking a while.
>> >>
>> >>> > * how do the eventual URLs look like? Maybe pytest.org/latest-jp/...?
>> >>> > ?instead of pytest.org/latest/ ?
>> >>> > ?I'd definitely like to keep existing URLs working.
>> >>> It's good idea and I suggest "latest-ja" is proper than "latest-jp"
>> >>> since "jp" is the country code.
>> >>
>> >> I think the eventual URL is not a big problem. ?We just need to take
>> >> care that it is compatible with the existing scheme, i.e. allows existing
>> >> URLs to remain valid.
>> >>
>> >>> > * how to organise the repository so that both EN and JP are included
>> >>> > ?(without the need to have a branch)
>> >>> I forked original branch for Japanese translation and made named
>> >>> branch to represent the version, but do you want to manage the
>> >>> translation in original repository? If so, I know Sphinx has i18n
>> >>> feature using gettext since 1.1. Is this useful for your purpose?
>> >>> http://sphinx.pocoo.org/latest/intl.html
>> >>
>> >> I think what we need is something along those lines:
>> >>
>> >> http://mark-story.com/posts/view/creating-multi-language-documentation-with-sphinx
>> >>
>> >> Does this also make sense to you? ?If so, it'd be great if you could
>> >> submit a pull request that reorganises pytest's docs accordingly,
>> >> preferably starting from the current trunk. ?There weren't much changes
>> >> between 2.2.3 and 2.2.4 in the doc directory, anyway.
>> >>
>> >> I think we'd end up with something like:
>> >>
>> >> ? ?pytest/
>> >> ? ? ? ?doc/
>> >> ? ? ? ? ? ?en/
>> >> ? ? ? ? ? ? ? ?# current english files and dirs
>> >> ? ? ? ? ? ?ja/
>> >> ? ? ? ? ? ? ? ?# current japanese files and dirs
>> >>
>> >> I'll take care to push the docs to pytest.org - maybe using a scheme like this:
>> >>
>> >> ? ?pytest.org/VER/... # for english documentation
>> >> ? ?pytest.org/en/VER ?# for english documentation
>> >> ? ?pytest.org/ja/VER ?# for japanese documentation
>> >>
>> >> where VER is a version number and "latest" could point to the latest number.
>> >>
>> >>> > * do we need to do anything special wrt to the examples and their
>> >>> > ?generation? (we use a tool called 'regendoc' written by ronny which
>> >>> > ?regenerates the example outputs)
>> >>> I used original example code with document, so the example's version
>> >>> are "pytest-2.2.2"? And then, I tried to run regen (make regen), but I
>> >>> got an error. It seems regenerating has an encoding issue.
>> >>>
>> >>> (sphinx)$ make regen
>> >>> PYTHONDONTWRITEBYTECODE=1 COLUMNS=76 regendoc --update *.txt */*.txt
>> >>> ===== checking apiref.txt =====
>> >>> Traceback (most recent call last):
>> >>> ? File "/Users/t2y/.virtualenvs/sphinx/bin/regendoc", line 9, in <module>
>> >>> ? ? load_entry_point('RegenDoc==0.2.dev1', 'console_scripts', 'regendoc')()
>> >>> ? File "/Users/t2y/work/python/regendoc/regendoc.py", line 201, in main
>> >>> ? ? return _main(options.files, should_update=options.update)
>> >>> ? File "/Users/t2y/work/python/regendoc/regendoc.py", line 196, in _main
>> >>> ? ? path.write(corrected)
>> >>> ? File "/Users/t2y/.virtualenvs/sphinx/lib/python2.7/site-packages/py/_path/local.py",
>> >>> line 385, in write
>> >>> ? ? data = py.builtin._totext(data, sys.getdefaultencoding())
>> >>> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position
>> >>> 22: ordinal not in range(128)
>> >>> make: *** [regen] Error 1
>> >>
>> >> One problem is that regendoc.py:196 should call "path.write(corrected,
>> >> 'wb')" in order to write out bytes and inhibit conversions. But after
>> >> that there is another error i am not sure about at the moment.
>> >> Maybe Ronny can take a look.
>> >>
>> >> best,
>> >> holger
>> >>
>> >>> thanks,
>> >>> Tetsuya
>> >>>
>> >>> On Fri, Apr 20, 2012 at 12:45 PM, holger krekel <holger at merlinux.eu> wrote:
>> >>> > Hi Tetsuya,
>> >>> >
>> >>> > thanks for your work already!
>> >>> >
>> >>> > i guess we need to work a bit to have both language versions
>> >>> > generated. ?I haven't looked at your branch yet but i guess
>> >>> > we need to solve a few issues:
>> >>> >
>> >>> > * how do the eventual URLs look like? Maybe pytest.org/latest-jp/...?
>> >>> > ?instead of pytest.org/latest/ ?
>> >>> > ?I'd definitely like to keep existing URLs working.
>> >>> >
>> >>> > * how to organise the repository so that both EN and JP are included
>> >>> > ?(without the need to have a branch)
>> >>> >
>> >>> > * do we need to do anything special wrt to the examples and their
>> >>> > ?generation? (we use a tool called 'regendoc' written by ronny which
>> >>> > ?regenerates the example outputs)
>> >>> >
>> >>> > best,
>> >>> > holger
>> >>> >
>> >>> >
>> >>> > On Mon, Apr 16, 2012 at 16:24 +0900, Tetsuya Morimoto wrote:
>> >>> >> Hi,
>> >>> >>
>> >>> >> I finished translating pytest documents English to Japanese. My
>> >>> >> repository is below and I made the named branch "2.2.3-ja" for
>> >>> >> translating docs.
>> >>> >>
>> >>> >> https://bitbucket.org/t2y/pytest-ja
>> >>> >>
>> >>> >> I would like to publish this Japanese translation on pytest.org with
>> >>> >> some ways. But, I don't know it's possible or not, and how to deploy
>> >>> >> the current docs. I think putting original and translated docs
>> >>> >> separately is easy deployment to avoid some conflicts. Of course,
>> >>> >> other suggestions are welcome.
>> >>> >>
>> >>> >> Additionally, I can maintain Japanese docs in the future. So, I can
>> >>> >> work by myself if you give me needed permission.
>> >>> >>
>> >>> >> thanks,
>> >>> >> Tetsuya
>> >>> >> _______________________________________________
>> >>> >> py-dev mailing list
>> >>> >> py-dev at codespeak.net
>> >>> >> http://codespeak.net/mailman/listinfo/py-dev
>> >>> >>
>> >>> _______________________________________________
>> >>> py-dev mailing list
>> >>> py-dev at codespeak.net
>> >>> http://codespeak.net/mailman/listinfo/py-dev
>>


From Ronny.Pfannschmidt at gmx.de  Wed Jun  6 13:59:04 2012
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Wed, 06 Jun 2012 13:59:04 +0200
Subject: [py-dev] pytest documents with Japanese translation
In-Reply-To: <CAGBzy2r+ybKk4cwwEcJWt7j8ate91Nb0YAa2UHR2QMSMaus-9Q@mail.gmail.com>
References: <CAGBzy2pGt6BYo41G9Vui5FmQaLCOGe2RveJhp6KEky6hn+VPMw@mail.gmail.com>
	<20120420034520.GG10174@merlinux.eu>
	<CAGBzy2p9Y7y9HPF56orDRM_mSC5NEW7YZew_HZ9+ODKjExgd2g@mail.gmail.com>
	<20120529141351.GE10174@merlinux.eu>
	<CAGBzy2rxp8YdMBzu6+ABbJ9_DsKfiFLXXhd6gL4EaoPx8iVwsA@mail.gmail.com>
	<CAGBzy2qToPaOAMS738XN9Rtwus7W4ErzzN7ncp=h_0-JccjskA@mail.gmail.com>
	<20120602113511.GC11942@merlinux.eu>
	<CAGBzy2r+ybKk4cwwEcJWt7j8ate91Nb0YAa2UHR2QMSMaus-9Q@mail.gmail.com>
Message-ID: <4FCF4608.80701@gmx.de>

Hi Holger, Tetsuya

while taking a look i noticed that sphinx has a integrated translation 
system based on .po files

see http://sphinx.pocoo.org/latest/intl.html

im under the impression that this way is more maintainable than he 
current way due to using standard tools to manage translated strings

i'd like to suggest some investigation in its usefullness

-- ronny


On 06/06/2012 02:07 AM, Tetsuya Morimoto wrote:
> Hi Holger,
>
> I sent a pull request. Confirm it!
>
> https://bitbucket.org/hpk42/pytest/pull-request/14/added-japanese-translation-documentation
>
> thanks,
> Tetsuya
>
> On Sat, Jun 2, 2012 at 8:35 PM, holger krekel<holger at merlinux.eu>  wrote:
>> Hi Tetsuya,
>>
>> On Sat, Jun 02, 2012 at 20:15 +0900, Tetsuya Morimoto wrote:
>>> Hi Holger,
>>>
>>> I merged the changes of 2.2.4 into my translation repository. I mean
>>> it's available to send a pull request.
>>> https://bitbucket.org/t2y/pytest-ja
>>>
>>> I think it's better to send a pull request from me after you
>>> reorganize the docs directory in your repository. Maybe, I re-fork
>>> pytest repository to drop the named branch for translation, anyway, I
>>> will follow your way.
>>
>> Can you imagine to do the doc reorganisation yourself?  This way there
>> is no need for a named branch - you could just do the final sub
>> directory layout as discussed in the last mail.  I would care for the
>> "push-to-website" bit and the apache side reconfiguration.
>>
>> best,
>> holger
>>
>>
>>> thanks,
>>> Tetsuya
>>>
>>> On Wed, May 30, 2012 at 12:07 AM, Tetsuya Morimoto
>>> <tetsuya.morimoto at gmail.com>  wrote:
>>>> Hi Holger,
>>>>
>>>> Thanks for remembering the translation! :)
>>>>
>>>>> Does this also make sense to you?  If so, it'd be great if you could
>>>>> submit a pull request that reorganises pytest's docs accordingly,
>>>>> preferably starting from the current trunk.
>>>> Yes, it makes sense for me. I have experienced a similar work for
>>>> virtualenvwrapper. That might be an informative.
>>>>
>>>> http://www.doughellmann.com/docs/virtualenvwrapper/index.html
>>>> http://www.doughellmann.com/docs/virtualenvwrapper/ja/index.html
>>>> https://bitbucket.org/dhellmann/virtualenvwrapper/src/e1a05e751a56/docs
>>>>
>>>>> There weren't much changes
>>>>> between 2.2.3 and 2.2.4 in the doc directory, anyway.
>>>> OK! I will update the Japanese translation and submit a pull request!
>>>>
>>>>> I'll take care to push the docs to pytest.org - maybe using a scheme like this:
>>>>>
>>>>>     pytest.org/VER/... # for english documentation
>>>>>     pytest.org/en/VER  # for english documentation
>>>>>     pytest.org/ja/VER  # for japanese documentation
>>>>>
>>>>> where VER is a version number and "latest" could point to the latest number.
>>>> It looks nice. I agree with you.
>>>>
>>>>> that there is another error i am not sure about at the moment.
>>>>> Maybe Ronny can take a look.
>>>> I see. I will talk to Ronny later.
>>>>
>>>> thanks,
>>>> Tetsuya
>>>>
>>>> On Tue, May 29, 2012 at 11:13 PM, holger krekel<holger at merlinux.eu>  wrote:
>>>>> Hi Tetsuya,
>>>>>
>>>>> On Mon, Apr 23, 2012 at 03:43 +0900, Tetsuya Morimoto wrote:
>>>>>> Hi Holger,
>>>>>>
>>>>>> Thanks for thinking about Japanese translation.
>>>>>
>>>>> sorry for taking a while.
>>>>>
>>>>>>> * how do the eventual URLs look like? Maybe pytest.org/latest-jp/...?
>>>>>>>   instead of pytest.org/latest/ ?
>>>>>>>   I'd definitely like to keep existing URLs working.
>>>>>> It's good idea and I suggest "latest-ja" is proper than "latest-jp"
>>>>>> since "jp" is the country code.
>>>>>
>>>>> I think the eventual URL is not a big problem.  We just need to take
>>>>> care that it is compatible with the existing scheme, i.e. allows existing
>>>>> URLs to remain valid.
>>>>>
>>>>>>> * how to organise the repository so that both EN and JP are included
>>>>>>>   (without the need to have a branch)
>>>>>> I forked original branch for Japanese translation and made named
>>>>>> branch to represent the version, but do you want to manage the
>>>>>> translation in original repository? If so, I know Sphinx has i18n
>>>>>> feature using gettext since 1.1. Is this useful for your purpose?
>>>>>> http://sphinx.pocoo.org/latest/intl.html
>>>>>
>>>>> I think what we need is something along those lines:
>>>>>
>>>>> http://mark-story.com/posts/view/creating-multi-language-documentation-with-sphinx
>>>>>
>>>>> Does this also make sense to you?  If so, it'd be great if you could
>>>>> submit a pull request that reorganises pytest's docs accordingly,
>>>>> preferably starting from the current trunk.  There weren't much changes
>>>>> between 2.2.3 and 2.2.4 in the doc directory, anyway.
>>>>>
>>>>> I think we'd end up with something like:
>>>>>
>>>>>     pytest/
>>>>>         doc/
>>>>>             en/
>>>>>                 # current english files and dirs
>>>>>             ja/
>>>>>                 # current japanese files and dirs
>>>>>
>>>>> I'll take care to push the docs to pytest.org - maybe using a scheme like this:
>>>>>
>>>>>     pytest.org/VER/... # for english documentation
>>>>>     pytest.org/en/VER  # for english documentation
>>>>>     pytest.org/ja/VER  # for japanese documentation
>>>>>
>>>>> where VER is a version number and "latest" could point to the latest number.
>>>>>
>>>>>>> * do we need to do anything special wrt to the examples and their
>>>>>>>   generation? (we use a tool called 'regendoc' written by ronny which
>>>>>>>   regenerates the example outputs)
>>>>>> I used original example code with document, so the example's version
>>>>>> are "pytest-2.2.2"? And then, I tried to run regen (make regen), but I
>>>>>> got an error. It seems regenerating has an encoding issue.
>>>>>>
>>>>>> (sphinx)$ make regen
>>>>>> PYTHONDONTWRITEBYTECODE=1 COLUMNS=76 regendoc --update *.txt */*.txt
>>>>>> ===== checking apiref.txt =====
>>>>>> Traceback (most recent call last):
>>>>>>    File "/Users/t2y/.virtualenvs/sphinx/bin/regendoc", line 9, in<module>
>>>>>>      load_entry_point('RegenDoc==0.2.dev1', 'console_scripts', 'regendoc')()
>>>>>>    File "/Users/t2y/work/python/regendoc/regendoc.py", line 201, in main
>>>>>>      return _main(options.files, should_update=options.update)
>>>>>>    File "/Users/t2y/work/python/regendoc/regendoc.py", line 196, in _main
>>>>>>      path.write(corrected)
>>>>>>    File "/Users/t2y/.virtualenvs/sphinx/lib/python2.7/site-packages/py/_path/local.py",
>>>>>> line 385, in write
>>>>>>      data = py.builtin._totext(data, sys.getdefaultencoding())
>>>>>> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position
>>>>>> 22: ordinal not in range(128)
>>>>>> make: *** [regen] Error 1
>>>>>
>>>>> One problem is that regendoc.py:196 should call "path.write(corrected,
>>>>> 'wb')" in order to write out bytes and inhibit conversions. But after
>>>>> that there is another error i am not sure about at the moment.
>>>>> Maybe Ronny can take a look.
>>>>>
>>>>> best,
>>>>> holger
>>>>>
>>>>>> thanks,
>>>>>> Tetsuya
>>>>>>
>>>>>> On Fri, Apr 20, 2012 at 12:45 PM, holger krekel<holger at merlinux.eu>  wrote:
>>>>>>> Hi Tetsuya,
>>>>>>>
>>>>>>> thanks for your work already!
>>>>>>>
>>>>>>> i guess we need to work a bit to have both language versions
>>>>>>> generated.  I haven't looked at your branch yet but i guess
>>>>>>> we need to solve a few issues:
>>>>>>>
>>>>>>> * how do the eventual URLs look like? Maybe pytest.org/latest-jp/...?
>>>>>>>   instead of pytest.org/latest/ ?
>>>>>>>   I'd definitely like to keep existing URLs working.
>>>>>>>
>>>>>>> * how to organise the repository so that both EN and JP are included
>>>>>>>   (without the need to have a branch)
>>>>>>>
>>>>>>> * do we need to do anything special wrt to the examples and their
>>>>>>>   generation? (we use a tool called 'regendoc' written by ronny which
>>>>>>>   regenerates the example outputs)
>>>>>>>
>>>>>>> best,
>>>>>>> holger
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Apr 16, 2012 at 16:24 +0900, Tetsuya Morimoto wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I finished translating pytest documents English to Japanese. My
>>>>>>>> repository is below and I made the named branch "2.2.3-ja" for
>>>>>>>> translating docs.
>>>>>>>>
>>>>>>>> https://bitbucket.org/t2y/pytest-ja
>>>>>>>>
>>>>>>>> I would like to publish this Japanese translation on pytest.org with
>>>>>>>> some ways. But, I don't know it's possible or not, and how to deploy
>>>>>>>> the current docs. I think putting original and translated docs
>>>>>>>> separately is easy deployment to avoid some conflicts. Of course,
>>>>>>>> other suggestions are welcome.
>>>>>>>>
>>>>>>>> Additionally, I can maintain Japanese docs in the future. So, I can
>>>>>>>> work by myself if you give me needed permission.
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>> Tetsuya
>>>>>>>> _______________________________________________
>>>>>>>> py-dev mailing list
>>>>>>>> py-dev at codespeak.net
>>>>>>>> http://codespeak.net/mailman/listinfo/py-dev
>>>>>>>>
>>>>>> _______________________________________________
>>>>>> py-dev mailing list
>>>>>> py-dev at codespeak.net
>>>>>> http://codespeak.net/mailman/listinfo/py-dev
>>>
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev



From holger at merlinux.eu  Wed Jun  6 14:11:13 2012
From: holger at merlinux.eu (holger krekel)
Date: Wed, 6 Jun 2012 12:11:13 +0000
Subject: [py-dev] pytest documents with Japanese translation
In-Reply-To: <CAGBzy2r+ybKk4cwwEcJWt7j8ate91Nb0YAa2UHR2QMSMaus-9Q@mail.gmail.com>
References: <CAGBzy2pGt6BYo41G9Vui5FmQaLCOGe2RveJhp6KEky6hn+VPMw@mail.gmail.com>
	<20120420034520.GG10174@merlinux.eu>
	<CAGBzy2p9Y7y9HPF56orDRM_mSC5NEW7YZew_HZ9+ODKjExgd2g@mail.gmail.com>
	<20120529141351.GE10174@merlinux.eu>
	<CAGBzy2rxp8YdMBzu6+ABbJ9_DsKfiFLXXhd6gL4EaoPx8iVwsA@mail.gmail.com>
	<CAGBzy2qToPaOAMS738XN9Rtwus7W4ErzzN7ncp=h_0-JccjskA@mail.gmail.com>
	<20120602113511.GC11942@merlinux.eu>
	<CAGBzy2r+ybKk4cwwEcJWt7j8ate91Nb0YAa2UHR2QMSMaus-9Q@mail.gmail.com>
Message-ID: <20120606121112.GR11942@merlinux.eu>

Hi Tetsuya,

accepted it, many thanks!

I created an issue for some futher neccessary work:

https://bitbucket.org/hpk42/pytest/issue/155/bring-japanese-translation-online-reorg

which i hope to tackle soon.   

On a sidenote, I am also thinking about packaging docs separately now that
they grow larger (and maybe even tests at some point). But that can come
later.

best,
holger

On Wed, Jun 06, 2012 at 09:07 +0900, Tetsuya Morimoto wrote:
> Hi Holger,
> 
> I sent a pull request. Confirm it!
> 
> https://bitbucket.org/hpk42/pytest/pull-request/14/added-japanese-translation-documentation
> 
> thanks,
> Tetsuya
> 
> On Sat, Jun 2, 2012 at 8:35 PM, holger krekel <holger at merlinux.eu> wrote:
> > Hi Tetsuya,
> >
> > On Sat, Jun 02, 2012 at 20:15 +0900, Tetsuya Morimoto wrote:
> >> Hi Holger,
> >>
> >> I merged the changes of 2.2.4 into my translation repository. I mean
> >> it's available to send a pull request.
> >> https://bitbucket.org/t2y/pytest-ja
> >>
> >> I think it's better to send a pull request from me after you
> >> reorganize the docs directory in your repository. Maybe, I re-fork
> >> pytest repository to drop the named branch for translation, anyway, I
> >> will follow your way.
> >
> > Can you imagine to do the doc reorganisation yourself? ?This way there
> > is no need for a named branch - you could just do the final sub
> > directory layout as discussed in the last mail. ?I would care for the
> > "push-to-website" bit and the apache side reconfiguration.
> >
> > best,
> > holger
> >
> >
> >> thanks,
> >> Tetsuya
> >>
> >> On Wed, May 30, 2012 at 12:07 AM, Tetsuya Morimoto
> >> <tetsuya.morimoto at gmail.com> wrote:
> >> > Hi Holger,
> >> >
> >> > Thanks for remembering the translation! :)
> >> >
> >> >> Does this also make sense to you? ?If so, it'd be great if you could
> >> >> submit a pull request that reorganises pytest's docs accordingly,
> >> >> preferably starting from the current trunk.
> >> > Yes, it makes sense for me. I have experienced a similar work for
> >> > virtualenvwrapper. That might be an informative.
> >> >
> >> > http://www.doughellmann.com/docs/virtualenvwrapper/index.html
> >> > http://www.doughellmann.com/docs/virtualenvwrapper/ja/index.html
> >> > https://bitbucket.org/dhellmann/virtualenvwrapper/src/e1a05e751a56/docs
> >> >
> >> >> There weren't much changes
> >> >> between 2.2.3 and 2.2.4 in the doc directory, anyway.
> >> > OK! I will update the Japanese translation and submit a pull request!
> >> >
> >> >> I'll take care to push the docs to pytest.org - maybe using a scheme like this:
> >> >>
> >> >> ? ?pytest.org/VER/... # for english documentation
> >> >> ? ?pytest.org/en/VER ?# for english documentation
> >> >> ? ?pytest.org/ja/VER ?# for japanese documentation
> >> >>
> >> >> where VER is a version number and "latest" could point to the latest number.
> >> > It looks nice. I agree with you.
> >> >
> >> >> that there is another error i am not sure about at the moment.
> >> >> Maybe Ronny can take a look.
> >> > I see. I will talk to Ronny later.
> >> >
> >> > thanks,
> >> > Tetsuya
> >> >
> >> > On Tue, May 29, 2012 at 11:13 PM, holger krekel <holger at merlinux.eu> wrote:
> >> >> Hi Tetsuya,
> >> >>
> >> >> On Mon, Apr 23, 2012 at 03:43 +0900, Tetsuya Morimoto wrote:
> >> >>> Hi Holger,
> >> >>>
> >> >>> Thanks for thinking about Japanese translation.
> >> >>
> >> >> sorry for taking a while.
> >> >>
> >> >>> > * how do the eventual URLs look like? Maybe pytest.org/latest-jp/...?
> >> >>> > ?instead of pytest.org/latest/ ?
> >> >>> > ?I'd definitely like to keep existing URLs working.
> >> >>> It's good idea and I suggest "latest-ja" is proper than "latest-jp"
> >> >>> since "jp" is the country code.
> >> >>
> >> >> I think the eventual URL is not a big problem. ?We just need to take
> >> >> care that it is compatible with the existing scheme, i.e. allows existing
> >> >> URLs to remain valid.
> >> >>
> >> >>> > * how to organise the repository so that both EN and JP are included
> >> >>> > ?(without the need to have a branch)
> >> >>> I forked original branch for Japanese translation and made named
> >> >>> branch to represent the version, but do you want to manage the
> >> >>> translation in original repository? If so, I know Sphinx has i18n
> >> >>> feature using gettext since 1.1. Is this useful for your purpose?
> >> >>> http://sphinx.pocoo.org/latest/intl.html
> >> >>
> >> >> I think what we need is something along those lines:
> >> >>
> >> >> http://mark-story.com/posts/view/creating-multi-language-documentation-with-sphinx
> >> >>
> >> >> Does this also make sense to you? ?If so, it'd be great if you could
> >> >> submit a pull request that reorganises pytest's docs accordingly,
> >> >> preferably starting from the current trunk. ?There weren't much changes
> >> >> between 2.2.3 and 2.2.4 in the doc directory, anyway.
> >> >>
> >> >> I think we'd end up with something like:
> >> >>
> >> >> ? ?pytest/
> >> >> ? ? ? ?doc/
> >> >> ? ? ? ? ? ?en/
> >> >> ? ? ? ? ? ? ? ?# current english files and dirs
> >> >> ? ? ? ? ? ?ja/
> >> >> ? ? ? ? ? ? ? ?# current japanese files and dirs
> >> >>
> >> >> I'll take care to push the docs to pytest.org - maybe using a scheme like this:
> >> >>
> >> >> ? ?pytest.org/VER/... # for english documentation
> >> >> ? ?pytest.org/en/VER ?# for english documentation
> >> >> ? ?pytest.org/ja/VER ?# for japanese documentation
> >> >>
> >> >> where VER is a version number and "latest" could point to the latest number.
> >> >>
> >> >>> > * do we need to do anything special wrt to the examples and their
> >> >>> > ?generation? (we use a tool called 'regendoc' written by ronny which
> >> >>> > ?regenerates the example outputs)
> >> >>> I used original example code with document, so the example's version
> >> >>> are "pytest-2.2.2"? And then, I tried to run regen (make regen), but I
> >> >>> got an error. It seems regenerating has an encoding issue.
> >> >>>
> >> >>> (sphinx)$ make regen
> >> >>> PYTHONDONTWRITEBYTECODE=1 COLUMNS=76 regendoc --update *.txt */*.txt
> >> >>> ===== checking apiref.txt =====
> >> >>> Traceback (most recent call last):
> >> >>> ? File "/Users/t2y/.virtualenvs/sphinx/bin/regendoc", line 9, in <module>
> >> >>> ? ? load_entry_point('RegenDoc==0.2.dev1', 'console_scripts', 'regendoc')()
> >> >>> ? File "/Users/t2y/work/python/regendoc/regendoc.py", line 201, in main
> >> >>> ? ? return _main(options.files, should_update=options.update)
> >> >>> ? File "/Users/t2y/work/python/regendoc/regendoc.py", line 196, in _main
> >> >>> ? ? path.write(corrected)
> >> >>> ? File "/Users/t2y/.virtualenvs/sphinx/lib/python2.7/site-packages/py/_path/local.py",
> >> >>> line 385, in write
> >> >>> ? ? data = py.builtin._totext(data, sys.getdefaultencoding())
> >> >>> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position
> >> >>> 22: ordinal not in range(128)
> >> >>> make: *** [regen] Error 1
> >> >>
> >> >> One problem is that regendoc.py:196 should call "path.write(corrected,
> >> >> 'wb')" in order to write out bytes and inhibit conversions. But after
> >> >> that there is another error i am not sure about at the moment.
> >> >> Maybe Ronny can take a look.
> >> >>
> >> >> best,
> >> >> holger
> >> >>
> >> >>> thanks,
> >> >>> Tetsuya
> >> >>>
> >> >>> On Fri, Apr 20, 2012 at 12:45 PM, holger krekel <holger at merlinux.eu> wrote:
> >> >>> > Hi Tetsuya,
> >> >>> >
> >> >>> > thanks for your work already!
> >> >>> >
> >> >>> > i guess we need to work a bit to have both language versions
> >> >>> > generated. ?I haven't looked at your branch yet but i guess
> >> >>> > we need to solve a few issues:
> >> >>> >
> >> >>> > * how do the eventual URLs look like? Maybe pytest.org/latest-jp/...?
> >> >>> > ?instead of pytest.org/latest/ ?
> >> >>> > ?I'd definitely like to keep existing URLs working.
> >> >>> >
> >> >>> > * how to organise the repository so that both EN and JP are included
> >> >>> > ?(without the need to have a branch)
> >> >>> >
> >> >>> > * do we need to do anything special wrt to the examples and their
> >> >>> > ?generation? (we use a tool called 'regendoc' written by ronny which
> >> >>> > ?regenerates the example outputs)
> >> >>> >
> >> >>> > best,
> >> >>> > holger
> >> >>> >
> >> >>> >
> >> >>> > On Mon, Apr 16, 2012 at 16:24 +0900, Tetsuya Morimoto wrote:
> >> >>> >> Hi,
> >> >>> >>
> >> >>> >> I finished translating pytest documents English to Japanese. My
> >> >>> >> repository is below and I made the named branch "2.2.3-ja" for
> >> >>> >> translating docs.
> >> >>> >>
> >> >>> >> https://bitbucket.org/t2y/pytest-ja
> >> >>> >>
> >> >>> >> I would like to publish this Japanese translation on pytest.org with
> >> >>> >> some ways. But, I don't know it's possible or not, and how to deploy
> >> >>> >> the current docs. I think putting original and translated docs
> >> >>> >> separately is easy deployment to avoid some conflicts. Of course,
> >> >>> >> other suggestions are welcome.
> >> >>> >>
> >> >>> >> Additionally, I can maintain Japanese docs in the future. So, I can
> >> >>> >> work by myself if you give me needed permission.
> >> >>> >>
> >> >>> >> thanks,
> >> >>> >> Tetsuya
> >> >>> >> _______________________________________________
> >> >>> >> py-dev mailing list
> >> >>> >> py-dev at codespeak.net
> >> >>> >> http://codespeak.net/mailman/listinfo/py-dev
> >> >>> >>
> >> >>> _______________________________________________
> >> >>> py-dev mailing list
> >> >>> py-dev at codespeak.net
> >> >>> http://codespeak.net/mailman/listinfo/py-dev
> >>
> 


From holger at merlinux.eu  Wed Jun  6 14:35:18 2012
From: holger at merlinux.eu (holger krekel)
Date: Wed, 6 Jun 2012 12:35:18 +0000
Subject: [py-dev] pytest documents with Japanese translation
In-Reply-To: <4FCF4608.80701@gmx.de>
References: <CAGBzy2pGt6BYo41G9Vui5FmQaLCOGe2RveJhp6KEky6hn+VPMw@mail.gmail.com>
	<20120420034520.GG10174@merlinux.eu>
	<CAGBzy2p9Y7y9HPF56orDRM_mSC5NEW7YZew_HZ9+ODKjExgd2g@mail.gmail.com>
	<20120529141351.GE10174@merlinux.eu>
	<CAGBzy2rxp8YdMBzu6+ABbJ9_DsKfiFLXXhd6gL4EaoPx8iVwsA@mail.gmail.com>
	<CAGBzy2qToPaOAMS738XN9Rtwus7W4ErzzN7ncp=h_0-JccjskA@mail.gmail.com>
	<20120602113511.GC11942@merlinux.eu>
	<CAGBzy2r+ybKk4cwwEcJWt7j8ate91Nb0YAa2UHR2QMSMaus-9Q@mail.gmail.com>
	<4FCF4608.80701@gmx.de>
Message-ID: <20120606123518.GT11942@merlinux.eu>

Hello Ronny,

On Wed, Jun 06, 2012 at 13:59 +0200, Ronny Pfannschmidt wrote:
> Hi Holger, Tetsuya
> 
> while taking a look i noticed that sphinx has a integrated
> translation system based on .po files
> 
> see http://sphinx.pocoo.org/latest/intl.html
> 
> im under the impression that this way is more maintainable than he
> current way due to using standard tools to manage translated strings
> 
> i'd like to suggest some investigation in its usefullness

I am happy to consider using it - not sure i get to try it myself
any time soon and wonder specifically if a two-language situation with
not so often changing docs warrants using the above system.

Tetsuya, what do you think? Can you imagine investigating a bit?

best,
holger

> -- ronny
> 
> 
> On 06/06/2012 02:07 AM, Tetsuya Morimoto wrote:
> >Hi Holger,
> >
> >I sent a pull request. Confirm it!
> >
> >https://bitbucket.org/hpk42/pytest/pull-request/14/added-japanese-translation-documentation
> >
> >thanks,
> >Tetsuya
> >
> >On Sat, Jun 2, 2012 at 8:35 PM, holger krekel<holger at merlinux.eu>  wrote:
> >>Hi Tetsuya,
> >>
> >>On Sat, Jun 02, 2012 at 20:15 +0900, Tetsuya Morimoto wrote:
> >>>Hi Holger,
> >>>
> >>>I merged the changes of 2.2.4 into my translation repository. I mean
> >>>it's available to send a pull request.
> >>>https://bitbucket.org/t2y/pytest-ja
> >>>
> >>>I think it's better to send a pull request from me after you
> >>>reorganize the docs directory in your repository. Maybe, I re-fork
> >>>pytest repository to drop the named branch for translation, anyway, I
> >>>will follow your way.
> >>
> >>Can you imagine to do the doc reorganisation yourself?  This way there
> >>is no need for a named branch - you could just do the final sub
> >>directory layout as discussed in the last mail.  I would care for the
> >>"push-to-website" bit and the apache side reconfiguration.
> >>
> >>best,
> >>holger
> >>
> >>
> >>>thanks,
> >>>Tetsuya
> >>>
> >>>On Wed, May 30, 2012 at 12:07 AM, Tetsuya Morimoto
> >>><tetsuya.morimoto at gmail.com>  wrote:
> >>>>Hi Holger,
> >>>>
> >>>>Thanks for remembering the translation! :)
> >>>>
> >>>>>Does this also make sense to you?  If so, it'd be great if you could
> >>>>>submit a pull request that reorganises pytest's docs accordingly,
> >>>>>preferably starting from the current trunk.
> >>>>Yes, it makes sense for me. I have experienced a similar work for
> >>>>virtualenvwrapper. That might be an informative.
> >>>>
> >>>>http://www.doughellmann.com/docs/virtualenvwrapper/index.html
> >>>>http://www.doughellmann.com/docs/virtualenvwrapper/ja/index.html
> >>>>https://bitbucket.org/dhellmann/virtualenvwrapper/src/e1a05e751a56/docs
> >>>>
> >>>>>There weren't much changes
> >>>>>between 2.2.3 and 2.2.4 in the doc directory, anyway.
> >>>>OK! I will update the Japanese translation and submit a pull request!
> >>>>
> >>>>>I'll take care to push the docs to pytest.org - maybe using a scheme like this:
> >>>>>
> >>>>>    pytest.org/VER/... # for english documentation
> >>>>>    pytest.org/en/VER  # for english documentation
> >>>>>    pytest.org/ja/VER  # for japanese documentation
> >>>>>
> >>>>>where VER is a version number and "latest" could point to the latest number.
> >>>>It looks nice. I agree with you.
> >>>>
> >>>>>that there is another error i am not sure about at the moment.
> >>>>>Maybe Ronny can take a look.
> >>>>I see. I will talk to Ronny later.
> >>>>
> >>>>thanks,
> >>>>Tetsuya
> >>>>
> >>>>On Tue, May 29, 2012 at 11:13 PM, holger krekel<holger at merlinux.eu>  wrote:
> >>>>>Hi Tetsuya,
> >>>>>
> >>>>>On Mon, Apr 23, 2012 at 03:43 +0900, Tetsuya Morimoto wrote:
> >>>>>>Hi Holger,
> >>>>>>
> >>>>>>Thanks for thinking about Japanese translation.
> >>>>>
> >>>>>sorry for taking a while.
> >>>>>
> >>>>>>>* how do the eventual URLs look like? Maybe pytest.org/latest-jp/...?
> >>>>>>>  instead of pytest.org/latest/ ?
> >>>>>>>  I'd definitely like to keep existing URLs working.
> >>>>>>It's good idea and I suggest "latest-ja" is proper than "latest-jp"
> >>>>>>since "jp" is the country code.
> >>>>>
> >>>>>I think the eventual URL is not a big problem.  We just need to take
> >>>>>care that it is compatible with the existing scheme, i.e. allows existing
> >>>>>URLs to remain valid.
> >>>>>
> >>>>>>>* how to organise the repository so that both EN and JP are included
> >>>>>>>  (without the need to have a branch)
> >>>>>>I forked original branch for Japanese translation and made named
> >>>>>>branch to represent the version, but do you want to manage the
> >>>>>>translation in original repository? If so, I know Sphinx has i18n
> >>>>>>feature using gettext since 1.1. Is this useful for your purpose?
> >>>>>>http://sphinx.pocoo.org/latest/intl.html
> >>>>>
> >>>>>I think what we need is something along those lines:
> >>>>>
> >>>>>http://mark-story.com/posts/view/creating-multi-language-documentation-with-sphinx
> >>>>>
> >>>>>Does this also make sense to you?  If so, it'd be great if you could
> >>>>>submit a pull request that reorganises pytest's docs accordingly,
> >>>>>preferably starting from the current trunk.  There weren't much changes
> >>>>>between 2.2.3 and 2.2.4 in the doc directory, anyway.
> >>>>>
> >>>>>I think we'd end up with something like:
> >>>>>
> >>>>>    pytest/
> >>>>>        doc/
> >>>>>            en/
> >>>>>                # current english files and dirs
> >>>>>            ja/
> >>>>>                # current japanese files and dirs
> >>>>>
> >>>>>I'll take care to push the docs to pytest.org - maybe using a scheme like this:
> >>>>>
> >>>>>    pytest.org/VER/... # for english documentation
> >>>>>    pytest.org/en/VER  # for english documentation
> >>>>>    pytest.org/ja/VER  # for japanese documentation
> >>>>>
> >>>>>where VER is a version number and "latest" could point to the latest number.
> >>>>>
> >>>>>>>* do we need to do anything special wrt to the examples and their
> >>>>>>>  generation? (we use a tool called 'regendoc' written by ronny which
> >>>>>>>  regenerates the example outputs)
> >>>>>>I used original example code with document, so the example's version
> >>>>>>are "pytest-2.2.2"? And then, I tried to run regen (make regen), but I
> >>>>>>got an error. It seems regenerating has an encoding issue.
> >>>>>>
> >>>>>>(sphinx)$ make regen
> >>>>>>PYTHONDONTWRITEBYTECODE=1 COLUMNS=76 regendoc --update *.txt */*.txt
> >>>>>>===== checking apiref.txt =====
> >>>>>>Traceback (most recent call last):
> >>>>>>   File "/Users/t2y/.virtualenvs/sphinx/bin/regendoc", line 9, in<module>
> >>>>>>     load_entry_point('RegenDoc==0.2.dev1', 'console_scripts', 'regendoc')()
> >>>>>>   File "/Users/t2y/work/python/regendoc/regendoc.py", line 201, in main
> >>>>>>     return _main(options.files, should_update=options.update)
> >>>>>>   File "/Users/t2y/work/python/regendoc/regendoc.py", line 196, in _main
> >>>>>>     path.write(corrected)
> >>>>>>   File "/Users/t2y/.virtualenvs/sphinx/lib/python2.7/site-packages/py/_path/local.py",
> >>>>>>line 385, in write
> >>>>>>     data = py.builtin._totext(data, sys.getdefaultencoding())
> >>>>>>UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position
> >>>>>>22: ordinal not in range(128)
> >>>>>>make: *** [regen] Error 1
> >>>>>
> >>>>>One problem is that regendoc.py:196 should call "path.write(corrected,
> >>>>>'wb')" in order to write out bytes and inhibit conversions. But after
> >>>>>that there is another error i am not sure about at the moment.
> >>>>>Maybe Ronny can take a look.
> >>>>>
> >>>>>best,
> >>>>>holger
> >>>>>
> >>>>>>thanks,
> >>>>>>Tetsuya
> >>>>>>
> >>>>>>On Fri, Apr 20, 2012 at 12:45 PM, holger krekel<holger at merlinux.eu>  wrote:
> >>>>>>>Hi Tetsuya,
> >>>>>>>
> >>>>>>>thanks for your work already!
> >>>>>>>
> >>>>>>>i guess we need to work a bit to have both language versions
> >>>>>>>generated.  I haven't looked at your branch yet but i guess
> >>>>>>>we need to solve a few issues:
> >>>>>>>
> >>>>>>>* how do the eventual URLs look like? Maybe pytest.org/latest-jp/...?
> >>>>>>>  instead of pytest.org/latest/ ?
> >>>>>>>  I'd definitely like to keep existing URLs working.
> >>>>>>>
> >>>>>>>* how to organise the repository so that both EN and JP are included
> >>>>>>>  (without the need to have a branch)
> >>>>>>>
> >>>>>>>* do we need to do anything special wrt to the examples and their
> >>>>>>>  generation? (we use a tool called 'regendoc' written by ronny which
> >>>>>>>  regenerates the example outputs)
> >>>>>>>
> >>>>>>>best,
> >>>>>>>holger
> >>>>>>>
> >>>>>>>
> >>>>>>>On Mon, Apr 16, 2012 at 16:24 +0900, Tetsuya Morimoto wrote:
> >>>>>>>>Hi,
> >>>>>>>>
> >>>>>>>>I finished translating pytest documents English to Japanese. My
> >>>>>>>>repository is below and I made the named branch "2.2.3-ja" for
> >>>>>>>>translating docs.
> >>>>>>>>
> >>>>>>>>https://bitbucket.org/t2y/pytest-ja
> >>>>>>>>
> >>>>>>>>I would like to publish this Japanese translation on pytest.org with
> >>>>>>>>some ways. But, I don't know it's possible or not, and how to deploy
> >>>>>>>>the current docs. I think putting original and translated docs
> >>>>>>>>separately is easy deployment to avoid some conflicts. Of course,
> >>>>>>>>other suggestions are welcome.
> >>>>>>>>
> >>>>>>>>Additionally, I can maintain Japanese docs in the future. So, I can
> >>>>>>>>work by myself if you give me needed permission.
> >>>>>>>>
> >>>>>>>>thanks,
> >>>>>>>>Tetsuya
> >>>>>>>>_______________________________________________
> >>>>>>>>py-dev mailing list
> >>>>>>>>py-dev at codespeak.net
> >>>>>>>>http://codespeak.net/mailman/listinfo/py-dev
> >>>>>>>>
> >>>>>>_______________________________________________
> >>>>>>py-dev mailing list
> >>>>>>py-dev at codespeak.net
> >>>>>>http://codespeak.net/mailman/listinfo/py-dev
> >>>
> >_______________________________________________
> >py-dev mailing list
> >py-dev at codespeak.net
> >http://codespeak.net/mailman/listinfo/py-dev
> 


From holger at merlinux.eu  Wed Jun  6 15:18:06 2012
From: holger at merlinux.eu (holger krekel)
Date: Wed, 6 Jun 2012 13:18:06 +0000
Subject: [py-dev] pytest tmpdir / test directories
In-Reply-To: <4FCF50B7.9090402@gmx.de>
References: <4FAF703E.5070404@gmx.de> <20120515165631.GC10174@merlinux.eu>
	<4FB28F95.8000705@gmx.de> <20120604144940.GI11942@merlinux.eu>
	<4FCDA4AD.6070106@gmx.de> <20120606123550.GU11942@merlinux.eu>
	<4FCF50B7.9090402@gmx.de>
Message-ID: <20120606131806.GV11942@merlinux.eu>

Hi Ronny, CCing py-dev again, was lost in between,

On Wed, Jun 06, 2012 at 14:44 +0200, Ronny Pfannschmidt wrote:
> On 06/06/2012 02:35 PM, holger krekel wrote:
> >On Tue, Jun 05, 2012 at 08:18 +0200, Ronny Pfannschmidt wrote:
> >>Hi Holger,
> >>
> >>i was thinking of just naming the current tmpdir funcarg testdatadir,
> >>and implementing tmpdir in terms of testdatadir.ensure('tmpdir', dir=1)
> >
> >sure.  no immediate need to have this as a pytest core plugin, i guess.
> >
> 
> this as meant as a patch to pytests tmpdir plugin

Ah, i slowly get it.  If you get to the habit of providing a full example 
of things at the beginning i might be able to understand things quicker.

I am hesitant because it introduces another generic core funcarg which
needs explanation and examples for relatively little benefit.  I'd
rather suggest to think about extending reporting such that the paths
to interesting files for a (failing) test are presented, like in your
example the one to couchdb.dump

best,
holger


> -- Ronny
> 
> >holger
> >
> >>-- Ronny
> >>
> >>On 06/04/2012 04:49 PM, holger krekel wrote:
> >>>Hi Ronny,
> >>>
> >>>i think you could implement your scheme by writing maybe a "testdir"
> >>>funcarg (a py.path.local object) which has a .tmpdir attribute.
> >>>
> >>>The existing "testdatadir" is only for internal purposes and a
> >>>bit convoluted anyway - i don't want to promote its usage but i
> >>>also don't currently feel like refactoring it on a large scale.
> >>>
> >>>best,
> >>>holger
> >>>
> >>>On Tue, May 15, 2012 at 19:17 +0200, Ronny Pfannschmidt wrote:
> >>>>Hi Holger,
> >>>>
> >>>>currently, the tmpdir funcarg creates a directory like::
> >>>>
> >>>>   /tmp/pytest-0/test_python0
> >>>>
> >>>>i currently abuse that in a plugin to store db dump, that currently
> >>>>looks like::
> >>>>
> >>>>   $ tree /tmp/pytest-0/test_python0
> >>>>   /tmp/pytest-0/test_python0
> >>>>   |-- couchdb.dump
> >>>>   `-- proc
> >>>>
> >>>>where couchdb.dump is a database dump, thats actually related to a
> >>>>test, but shouldnt really be in its tmpdir,
> >>>>
> >>>>while proc is a directory actually created by the test
> >>>>
> >>>>i would rather have the following tree::
> >>>>
> >>>>   /tmp/pytest-0/ (test session root as before)
> >>>>    test_python0 (test data directory for that test)
> >>>>      couchdb.dump (the db dump)
> >>>>      tmpdir (this path will be in the
> >>>>        proc (the directory the test actually made)
> >>>>
> >>>>
> >>>>so testdatadir will be a funcarg *and* literally a directory that
> >>>>will be used by other functionalities as a place to put data,
> >>>>
> >>>>tmpdir would just be a directory within that
> >>>>
> >>>>if this structure is a given,
> >>>>we can also easily add per test coverage data and some extra dumps
> >>>>(like for example a logging filehandler)
> >>>>
> >>>>without disturbing expectations about having a clean tmpdir
> >>>>
> >>>>also i would like to grab screenshoots there as well
> >>>>(acceptance tests with a headless webkit)
> >>>>
> >>>>-- Ronny
> >>>>
> >>>>On 05/15/2012 06:56 PM, holger krekel wrote:
> >>>>>Hi Ronny,
> >>>>>
> >>>>>On Sun, May 13, 2012 at 10:26 +0200, Ronny Pfannschmidt wrote:
> >>>>>>Hi Holger,
> >>>>>>
> >>>>>>for one of my pytest plugins i drop out files, that dont exctly fit
> >>>>>>tmpdir, so i'd like to propose to flip it around a bit,
> >>>>>>
> >>>>>>so we get a testdatadir funcarg/directory and tmpdir is a directory below it
> >>>>>
> >>>>>confused a bit - do you literally mean funcarg/directory?
> >>>>>could you give a more concrete example?
> >>>>>
> >>>>>>from pytest plugins i'd use it to drop things like screenshots
> >>>>>>(pytest-ghost i.e. headless webkit),
> >>>>>>db dumps (pytest_couchdbkit)
> >>>>>>and later mabe for something like per test coverage reports
> >>>>>>
> >>>>>>for later it would also be nice to be able to transfer that data
> >>>>>>with a report and store it in some kind of test repository (for my
> >>>>>>thesis i'll probably prototype a couchdb one)
> >>>>>
> >>>>>I'd definitely like to see a test result repository and give test code
> >>>>>the possibility to create some payload and make this easily accessible
> >>>>>from outside a test run for visualization or other purposes.  I'd like
> >>>>>to list a few use cases for such a repository and then design the API.
> >>>>>But this is rather something post-may.
> >>>>>
> >>>>>holger
> >>>>>
> >>>>>>
> >>>>>>-- Ronny
> >>>>>>
> >>>>
> >>
> 


From Ronny.Pfannschmidt at gmx.de  Wed Jun  6 15:22:19 2012
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Wed, 06 Jun 2012 15:22:19 +0200
Subject: [py-dev] pytest tmpdir / test directories
In-Reply-To: <20120606131806.GV11942@merlinux.eu>
References: <4FAF703E.5070404@gmx.de> <20120515165631.GC10174@merlinux.eu>
	<4FB28F95.8000705@gmx.de> <20120604144940.GI11942@merlinux.eu>
	<4FCDA4AD.6070106@gmx.de> <20120606123550.GU11942@merlinux.eu>
	<4FCF50B7.9090402@gmx.de> <20120606131806.GV11942@merlinux.eu>
Message-ID: <4FCF598B.20106@gmx.de>

On 06/06/2012 03:18 PM, holger krekel wrote:
> Hi Ronny, CCing py-dev again, was lost in between,
>
> On Wed, Jun 06, 2012 at 14:44 +0200, Ronny Pfannschmidt wrote:
>> On 06/06/2012 02:35 PM, holger krekel wrote:
>>> On Tue, Jun 05, 2012 at 08:18 +0200, Ronny Pfannschmidt wrote:
>>>> Hi Holger,
>>>>
>>>> i was thinking of just naming the current tmpdir funcarg testdatadir,
>>>> and implementing tmpdir in terms of testdatadir.ensure('tmpdir', dir=1)
>>>
>>> sure.  no immediate need to have this as a pytest core plugin, i guess.
>>>
>>
>> this as meant as a patch to pytests tmpdir plugin
>
> Ah, i slowly get it.  If you get to the habit of providing a full example
> of things at the beginning i might be able to understand things quicker.
>
> I am hesitant because it introduces another generic core funcarg which
> needs explanation and examples for relatively little benefit.  I'd
> rather suggest to think about extending reporting such that the paths
> to interesting files for a (failing) test are presented, like in your
> example the one to couchdb.dump

this would mean that each plugin needs a own way to manage test specific 
files + report them afterwards
as opposed to just droping them into a dir thats just meant for that

-- Ronny

>
> best,
> holger
>
>


From holger at merlinux.eu  Wed Jun  6 15:34:20 2012
From: holger at merlinux.eu (holger krekel)
Date: Wed, 6 Jun 2012 13:34:20 +0000
Subject: [py-dev] pytest tmpdir / test directories
In-Reply-To: <4FCF598B.20106@gmx.de>
References: <4FAF703E.5070404@gmx.de> <20120515165631.GC10174@merlinux.eu>
	<4FB28F95.8000705@gmx.de> <20120604144940.GI11942@merlinux.eu>
	<4FCDA4AD.6070106@gmx.de> <20120606123550.GU11942@merlinux.eu>
	<4FCF50B7.9090402@gmx.de> <20120606131806.GV11942@merlinux.eu>
	<4FCF598B.20106@gmx.de>
Message-ID: <20120606133420.GW11942@merlinux.eu>

On Wed, Jun 06, 2012 at 15:22 +0200, Ronny Pfannschmidt wrote:
> On 06/06/2012 03:18 PM, holger krekel wrote:
> >Hi Ronny, CCing py-dev again, was lost in between,
> >
> >On Wed, Jun 06, 2012 at 14:44 +0200, Ronny Pfannschmidt wrote:
> >>On 06/06/2012 02:35 PM, holger krekel wrote:
> >>>On Tue, Jun 05, 2012 at 08:18 +0200, Ronny Pfannschmidt wrote:
> >>>>Hi Holger,
> >>>>
> >>>>i was thinking of just naming the current tmpdir funcarg testdatadir,
> >>>>and implementing tmpdir in terms of testdatadir.ensure('tmpdir', dir=1)
> >>>
> >>>sure.  no immediate need to have this as a pytest core plugin, i guess.
> >>>
> >>
> >>this as meant as a patch to pytests tmpdir plugin
> >
> >Ah, i slowly get it.  If you get to the habit of providing a full example
> >of things at the beginning i might be able to understand things quicker.
> >
> >I am hesitant because it introduces another generic core funcarg which
> >needs explanation and examples for relatively little benefit.  I'd
> >rather suggest to think about extending reporting such that the paths
> >to interesting files for a (failing) test are presented, like in your
> >example the one to couchdb.dump
> 
> this would mean that each plugin needs a own way to manage test
> specific files + report them afterwards
> as opposed to just droping them into a dir thats just meant for that

Which plugins do you have in mind that directly could/would use it?

holger


> -- Ronny
> 
> >
> >best,
> >holger
> >
> >
> 


From Ronny.Pfannschmidt at gmx.de  Wed Jun  6 15:41:22 2012
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Wed, 06 Jun 2012 15:41:22 +0200
Subject: [py-dev] pytest tmpdir / test directories
In-Reply-To: <20120606133420.GW11942@merlinux.eu>
References: <4FAF703E.5070404@gmx.de> <20120515165631.GC10174@merlinux.eu>
	<4FB28F95.8000705@gmx.de> <20120604144940.GI11942@merlinux.eu>
	<4FCDA4AD.6070106@gmx.de> <20120606123550.GU11942@merlinux.eu>
	<4FCF50B7.9090402@gmx.de> <20120606131806.GV11942@merlinux.eu>
	<4FCF598B.20106@gmx.de> <20120606133420.GW11942@merlinux.eu>
Message-ID: <4FCF5E02.9040501@gmx.de>

> Which plugins do you have in mind that directly could/would use it?
>

pytest-couchdbkit -> db dumps and later on db logs as well
pytest-ghost/mozwebqa -> browser screenshots

also it would be interesting for logcapture/stdcapture
to drop the output there for better post-mortem

-- Ronny


From holger at merlinux.eu  Wed Jun  6 17:10:27 2012
From: holger at merlinux.eu (holger krekel)
Date: Wed, 6 Jun 2012 15:10:27 +0000
Subject: [py-dev] pytest tmpdir / test directories
In-Reply-To: <4FCF5E02.9040501@gmx.de>
References: <20120515165631.GC10174@merlinux.eu> <4FB28F95.8000705@gmx.de>
	<20120604144940.GI11942@merlinux.eu> <4FCDA4AD.6070106@gmx.de>
	<20120606123550.GU11942@merlinux.eu> <4FCF50B7.9090402@gmx.de>
	<20120606131806.GV11942@merlinux.eu> <4FCF598B.20106@gmx.de>
	<20120606133420.GW11942@merlinux.eu> <4FCF5E02.9040501@gmx.de>
Message-ID: <20120606151027.GX11942@merlinux.eu>

On Wed, Jun 06, 2012 at 15:41 +0200, Ronny Pfannschmidt wrote:
> > Which plugins do you have in mind that directly could/would use it?
> >
> 
> pytest-couchdbkit -> db dumps and later on db logs as well
> pytest-ghost/mozwebqa -> browser screenshots
> 
> also it would be interesting for logcapture/stdcapture
> to drop the output there for better post-mortem

I see the usefullness of something like this.  If you go for this,
please also care for documentation and examples and look into actually
allowing storage of stdout/stderr by introducing a --capture-to-files option
where a failing test should report the path to the non-empty files.
One slightly open question is the name "testdatadir" - it's a bit long
and "testdir" is currently used (mostly for pytests own testing purposes
but also from some plugins).  We can postpone that question, however.

On a sidenote, a seperate issue is to review and integrate the logging
plugin because it relates to a standard library module anyway.  Part of
the complexity of pytest's capture.py plugin stems from some of the
logging package's behaviour and i guess by integrating the logging
plugin we might get rid of that eventually.

holger

> -- Ronny
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 


From tetsuya.morimoto at gmail.com  Thu Jun  7 02:09:46 2012
From: tetsuya.morimoto at gmail.com (Tetsuya Morimoto)
Date: Thu, 7 Jun 2012 09:09:46 +0900
Subject: [py-dev] pytest documents with Japanese translation
In-Reply-To: <20120606123518.GT11942@merlinux.eu>
References: <CAGBzy2pGt6BYo41G9Vui5FmQaLCOGe2RveJhp6KEky6hn+VPMw@mail.gmail.com>
	<20120420034520.GG10174@merlinux.eu>
	<CAGBzy2p9Y7y9HPF56orDRM_mSC5NEW7YZew_HZ9+ODKjExgd2g@mail.gmail.com>
	<20120529141351.GE10174@merlinux.eu>
	<CAGBzy2rxp8YdMBzu6+ABbJ9_DsKfiFLXXhd6gL4EaoPx8iVwsA@mail.gmail.com>
	<CAGBzy2qToPaOAMS738XN9Rtwus7W4ErzzN7ncp=h_0-JccjskA@mail.gmail.com>
	<20120602113511.GC11942@merlinux.eu>
	<CAGBzy2r+ybKk4cwwEcJWt7j8ate91Nb0YAa2UHR2QMSMaus-9Q@mail.gmail.com>
	<4FCF4608.80701@gmx.de> <20120606123518.GT11942@merlinux.eu>
Message-ID: <CAGBzy2rerA_c9jO1goPa5WkSRU7H7u4fe3jFe8Cm+oYJenMstQ@mail.gmail.com>

Hi Holger, Ronny

In my opinion, I agree with Ronny's idea (use Sphinx i18n feature),
because of its maintainability.

However, we need to change some operations for documentation workflow
if we started to use Sphinx i18n feature. I don't know you want it or
not, in this time.

Though I haven't used Sphinx i18n feature, I'm willing to investigate
the functionality and make the documentation workflow if you want.

thanks,
Tetsuya

On Wed, Jun 6, 2012 at 9:35 PM, holger krekel <holger at merlinux.eu> wrote:
> Hello Ronny,
>
> On Wed, Jun 06, 2012 at 13:59 +0200, Ronny Pfannschmidt wrote:
>> Hi Holger, Tetsuya
>>
>> while taking a look i noticed that sphinx has a integrated
>> translation system based on .po files
>>
>> see http://sphinx.pocoo.org/latest/intl.html
>>
>> im under the impression that this way is more maintainable than he
>> current way due to using standard tools to manage translated strings
>>
>> i'd like to suggest some investigation in its usefullness
>
> I am happy to consider using it - not sure i get to try it myself
> any time soon and wonder specifically if a two-language situation with
> not so often changing docs warrants using the above system.
>
> Tetsuya, what do you think? Can you imagine investigating a bit?
>
> best,
> holger
>
>> -- ronny
>>
>>
>> On 06/06/2012 02:07 AM, Tetsuya Morimoto wrote:
>> >Hi Holger,
>> >
>> >I sent a pull request. Confirm it!
>> >
>> >https://bitbucket.org/hpk42/pytest/pull-request/14/added-japanese-translation-documentation
>> >
>> >thanks,
>> >Tetsuya
>> >
>> >On Sat, Jun 2, 2012 at 8:35 PM, holger krekel<holger at merlinux.eu> ?wrote:
>> >>Hi Tetsuya,
>> >>
>> >>On Sat, Jun 02, 2012 at 20:15 +0900, Tetsuya Morimoto wrote:
>> >>>Hi Holger,
>> >>>
>> >>>I merged the changes of 2.2.4 into my translation repository. I mean
>> >>>it's available to send a pull request.
>> >>>https://bitbucket.org/t2y/pytest-ja
>> >>>
>> >>>I think it's better to send a pull request from me after you
>> >>>reorganize the docs directory in your repository. Maybe, I re-fork
>> >>>pytest repository to drop the named branch for translation, anyway, I
>> >>>will follow your way.
>> >>
>> >>Can you imagine to do the doc reorganisation yourself? ?This way there
>> >>is no need for a named branch - you could just do the final sub
>> >>directory layout as discussed in the last mail. ?I would care for the
>> >>"push-to-website" bit and the apache side reconfiguration.
>> >>
>> >>best,
>> >>holger
>> >>
>> >>
>> >>>thanks,
>> >>>Tetsuya
>> >>>
>> >>>On Wed, May 30, 2012 at 12:07 AM, Tetsuya Morimoto
>> >>><tetsuya.morimoto at gmail.com> ?wrote:
>> >>>>Hi Holger,
>> >>>>
>> >>>>Thanks for remembering the translation! :)
>> >>>>
>> >>>>>Does this also make sense to you? ?If so, it'd be great if you could
>> >>>>>submit a pull request that reorganises pytest's docs accordingly,
>> >>>>>preferably starting from the current trunk.
>> >>>>Yes, it makes sense for me. I have experienced a similar work for
>> >>>>virtualenvwrapper. That might be an informative.
>> >>>>
>> >>>>http://www.doughellmann.com/docs/virtualenvwrapper/index.html
>> >>>>http://www.doughellmann.com/docs/virtualenvwrapper/ja/index.html
>> >>>>https://bitbucket.org/dhellmann/virtualenvwrapper/src/e1a05e751a56/docs
>> >>>>
>> >>>>>There weren't much changes
>> >>>>>between 2.2.3 and 2.2.4 in the doc directory, anyway.
>> >>>>OK! I will update the Japanese translation and submit a pull request!
>> >>>>
>> >>>>>I'll take care to push the docs to pytest.org - maybe using a scheme like this:
>> >>>>>
>> >>>>> ? ?pytest.org/VER/... # for english documentation
>> >>>>> ? ?pytest.org/en/VER ?# for english documentation
>> >>>>> ? ?pytest.org/ja/VER ?# for japanese documentation
>> >>>>>
>> >>>>>where VER is a version number and "latest" could point to the latest number.
>> >>>>It looks nice. I agree with you.
>> >>>>
>> >>>>>that there is another error i am not sure about at the moment.
>> >>>>>Maybe Ronny can take a look.
>> >>>>I see. I will talk to Ronny later.
>> >>>>
>> >>>>thanks,
>> >>>>Tetsuya
>> >>>>
>> >>>>On Tue, May 29, 2012 at 11:13 PM, holger krekel<holger at merlinux.eu> ?wrote:
>> >>>>>Hi Tetsuya,
>> >>>>>
>> >>>>>On Mon, Apr 23, 2012 at 03:43 +0900, Tetsuya Morimoto wrote:
>> >>>>>>Hi Holger,
>> >>>>>>
>> >>>>>>Thanks for thinking about Japanese translation.
>> >>>>>
>> >>>>>sorry for taking a while.
>> >>>>>
>> >>>>>>>* how do the eventual URLs look like? Maybe pytest.org/latest-jp/...?
>> >>>>>>> ?instead of pytest.org/latest/ ?
>> >>>>>>> ?I'd definitely like to keep existing URLs working.
>> >>>>>>It's good idea and I suggest "latest-ja" is proper than "latest-jp"
>> >>>>>>since "jp" is the country code.
>> >>>>>
>> >>>>>I think the eventual URL is not a big problem. ?We just need to take
>> >>>>>care that it is compatible with the existing scheme, i.e. allows existing
>> >>>>>URLs to remain valid.
>> >>>>>
>> >>>>>>>* how to organise the repository so that both EN and JP are included
>> >>>>>>> ?(without the need to have a branch)
>> >>>>>>I forked original branch for Japanese translation and made named
>> >>>>>>branch to represent the version, but do you want to manage the
>> >>>>>>translation in original repository? If so, I know Sphinx has i18n
>> >>>>>>feature using gettext since 1.1. Is this useful for your purpose?
>> >>>>>>http://sphinx.pocoo.org/latest/intl.html
>> >>>>>
>> >>>>>I think what we need is something along those lines:
>> >>>>>
>> >>>>>http://mark-story.com/posts/view/creating-multi-language-documentation-with-sphinx
>> >>>>>
>> >>>>>Does this also make sense to you? ?If so, it'd be great if you could
>> >>>>>submit a pull request that reorganises pytest's docs accordingly,
>> >>>>>preferably starting from the current trunk. ?There weren't much changes
>> >>>>>between 2.2.3 and 2.2.4 in the doc directory, anyway.
>> >>>>>
>> >>>>>I think we'd end up with something like:
>> >>>>>
>> >>>>> ? ?pytest/
>> >>>>> ? ? ? ?doc/
>> >>>>> ? ? ? ? ? ?en/
>> >>>>> ? ? ? ? ? ? ? ?# current english files and dirs
>> >>>>> ? ? ? ? ? ?ja/
>> >>>>> ? ? ? ? ? ? ? ?# current japanese files and dirs
>> >>>>>
>> >>>>>I'll take care to push the docs to pytest.org - maybe using a scheme like this:
>> >>>>>
>> >>>>> ? ?pytest.org/VER/... # for english documentation
>> >>>>> ? ?pytest.org/en/VER ?# for english documentation
>> >>>>> ? ?pytest.org/ja/VER ?# for japanese documentation
>> >>>>>
>> >>>>>where VER is a version number and "latest" could point to the latest number.
>> >>>>>
>> >>>>>>>* do we need to do anything special wrt to the examples and their
>> >>>>>>> ?generation? (we use a tool called 'regendoc' written by ronny which
>> >>>>>>> ?regenerates the example outputs)
>> >>>>>>I used original example code with document, so the example's version
>> >>>>>>are "pytest-2.2.2"? And then, I tried to run regen (make regen), but I
>> >>>>>>got an error. It seems regenerating has an encoding issue.
>> >>>>>>
>> >>>>>>(sphinx)$ make regen
>> >>>>>>PYTHONDONTWRITEBYTECODE=1 COLUMNS=76 regendoc --update *.txt */*.txt
>> >>>>>>===== checking apiref.txt =====
>> >>>>>>Traceback (most recent call last):
>> >>>>>> ? File "/Users/t2y/.virtualenvs/sphinx/bin/regendoc", line 9, in<module>
>> >>>>>> ? ? load_entry_point('RegenDoc==0.2.dev1', 'console_scripts', 'regendoc')()
>> >>>>>> ? File "/Users/t2y/work/python/regendoc/regendoc.py", line 201, in main
>> >>>>>> ? ? return _main(options.files, should_update=options.update)
>> >>>>>> ? File "/Users/t2y/work/python/regendoc/regendoc.py", line 196, in _main
>> >>>>>> ? ? path.write(corrected)
>> >>>>>> ? File "/Users/t2y/.virtualenvs/sphinx/lib/python2.7/site-packages/py/_path/local.py",
>> >>>>>>line 385, in write
>> >>>>>> ? ? data = py.builtin._totext(data, sys.getdefaultencoding())
>> >>>>>>UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position
>> >>>>>>22: ordinal not in range(128)
>> >>>>>>make: *** [regen] Error 1
>> >>>>>
>> >>>>>One problem is that regendoc.py:196 should call "path.write(corrected,
>> >>>>>'wb')" in order to write out bytes and inhibit conversions. But after
>> >>>>>that there is another error i am not sure about at the moment.
>> >>>>>Maybe Ronny can take a look.
>> >>>>>
>> >>>>>best,
>> >>>>>holger
>> >>>>>
>> >>>>>>thanks,
>> >>>>>>Tetsuya
>> >>>>>>
>> >>>>>>On Fri, Apr 20, 2012 at 12:45 PM, holger krekel<holger at merlinux.eu> ?wrote:
>> >>>>>>>Hi Tetsuya,
>> >>>>>>>
>> >>>>>>>thanks for your work already!
>> >>>>>>>
>> >>>>>>>i guess we need to work a bit to have both language versions
>> >>>>>>>generated. ?I haven't looked at your branch yet but i guess
>> >>>>>>>we need to solve a few issues:
>> >>>>>>>
>> >>>>>>>* how do the eventual URLs look like? Maybe pytest.org/latest-jp/...?
>> >>>>>>> ?instead of pytest.org/latest/ ?
>> >>>>>>> ?I'd definitely like to keep existing URLs working.
>> >>>>>>>
>> >>>>>>>* how to organise the repository so that both EN and JP are included
>> >>>>>>> ?(without the need to have a branch)
>> >>>>>>>
>> >>>>>>>* do we need to do anything special wrt to the examples and their
>> >>>>>>> ?generation? (we use a tool called 'regendoc' written by ronny which
>> >>>>>>> ?regenerates the example outputs)
>> >>>>>>>
>> >>>>>>>best,
>> >>>>>>>holger
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>On Mon, Apr 16, 2012 at 16:24 +0900, Tetsuya Morimoto wrote:
>> >>>>>>>>Hi,
>> >>>>>>>>
>> >>>>>>>>I finished translating pytest documents English to Japanese. My
>> >>>>>>>>repository is below and I made the named branch "2.2.3-ja" for
>> >>>>>>>>translating docs.
>> >>>>>>>>
>> >>>>>>>>https://bitbucket.org/t2y/pytest-ja
>> >>>>>>>>
>> >>>>>>>>I would like to publish this Japanese translation on pytest.org with
>> >>>>>>>>some ways. But, I don't know it's possible or not, and how to deploy
>> >>>>>>>>the current docs. I think putting original and translated docs
>> >>>>>>>>separately is easy deployment to avoid some conflicts. Of course,
>> >>>>>>>>other suggestions are welcome.
>> >>>>>>>>
>> >>>>>>>>Additionally, I can maintain Japanese docs in the future. So, I can
>> >>>>>>>>work by myself if you give me needed permission.
>> >>>>>>>>
>> >>>>>>>>thanks,
>> >>>>>>>>Tetsuya
>> >>>>>>>>_______________________________________________
>> >>>>>>>>py-dev mailing list
>> >>>>>>>>py-dev at codespeak.net
>> >>>>>>>>http://codespeak.net/mailman/listinfo/py-dev
>> >>>>>>>>
>> >>>>>>_______________________________________________
>> >>>>>>py-dev mailing list
>> >>>>>>py-dev at codespeak.net
>> >>>>>>http://codespeak.net/mailman/listinfo/py-dev
>> >>>
>> >_______________________________________________
>> >py-dev mailing list
>> >py-dev at codespeak.net
>> >http://codespeak.net/mailman/listinfo/py-dev
>>


From Ronny.Pfannschmidt at gmx.de  Thu Jun  7 09:21:54 2012
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Thu, 07 Jun 2012 09:21:54 +0200
Subject: [py-dev] pytest documents with Japanese translation
In-Reply-To: <CAGBzy2rerA_c9jO1goPa5WkSRU7H7u4fe3jFe8Cm+oYJenMstQ@mail.gmail.com>
References: <CAGBzy2pGt6BYo41G9Vui5FmQaLCOGe2RveJhp6KEky6hn+VPMw@mail.gmail.com>
	<20120420034520.GG10174@merlinux.eu>
	<CAGBzy2p9Y7y9HPF56orDRM_mSC5NEW7YZew_HZ9+ODKjExgd2g@mail.gmail.com>
	<20120529141351.GE10174@merlinux.eu>
	<CAGBzy2rxp8YdMBzu6+ABbJ9_DsKfiFLXXhd6gL4EaoPx8iVwsA@mail.gmail.com>
	<CAGBzy2qToPaOAMS738XN9Rtwus7W4ErzzN7ncp=h_0-JccjskA@mail.gmail.com>
	<20120602113511.GC11942@merlinux.eu>
	<CAGBzy2r+ybKk4cwwEcJWt7j8ate91Nb0YAa2UHR2QMSMaus-9Q@mail.gmail.com>
	<4FCF4608.80701@gmx.de> <20120606123518.GT11942@merlinux.eu>
	<CAGBzy2rerA_c9jO1goPa5WkSRU7H7u4fe3jFe8Cm+oYJenMstQ@mail.gmail.com>
Message-ID: <4FD05692.6060507@gmx.de>

Hi Holger, Tetsuya

is there some suggested readng for the workflow changes?
(i really didn't investigate further than it exists and uses .po)

we might also want to investgate something like transifex
for making it easy for translators to translate the docs

-- Ronny

On 06/07/2012 02:09 AM, Tetsuya Morimoto wrote:
> Hi Holger, Ronny
>
> In my opinion, I agree with Ronny's idea (use Sphinx i18n feature),
> because of its maintainability.
>
> However, we need to change some operations for documentation workflow
> if we started to use Sphinx i18n feature. I don't know you want it or
> not, in this time.
>
> Though I haven't used Sphinx i18n feature, I'm willing to investigate
> the functionality and make the documentation workflow if you want.
>
> thanks,
> Tetsuya
>
> On Wed, Jun 6, 2012 at 9:35 PM, holger krekel<holger at merlinux.eu>  wrote:
>> Hello Ronny,
>>
>> On Wed, Jun 06, 2012 at 13:59 +0200, Ronny Pfannschmidt wrote:
>>> Hi Holger, Tetsuya
>>>
>>> while taking a look i noticed that sphinx has a integrated
>>> translation system based on .po files
>>>
>>> see http://sphinx.pocoo.org/latest/intl.html
>>>
>>> im under the impression that this way is more maintainable than he
>>> current way due to using standard tools to manage translated strings
>>>
>>> i'd like to suggest some investigation in its usefullness
>>
>> I am happy to consider using it - not sure i get to try it myself
>> any time soon and wonder specifically if a two-language situation with
>> not so often changing docs warrants using the above system.
>>
>> Tetsuya, what do you think? Can you imagine investigating a bit?
>>
>> best,
>> holger
>>
>>> -- ronny
>>>
>>>


From tetsuya.morimoto at gmail.com  Thu Jun  7 14:03:09 2012
From: tetsuya.morimoto at gmail.com (Tetsuya Morimoto)
Date: Thu, 7 Jun 2012 21:03:09 +0900
Subject: [py-dev] pytest documents with Japanese translation
In-Reply-To: <4FD05692.6060507@gmx.de>
References: <CAGBzy2pGt6BYo41G9Vui5FmQaLCOGe2RveJhp6KEky6hn+VPMw@mail.gmail.com>
	<20120420034520.GG10174@merlinux.eu>
	<CAGBzy2p9Y7y9HPF56orDRM_mSC5NEW7YZew_HZ9+ODKjExgd2g@mail.gmail.com>
	<20120529141351.GE10174@merlinux.eu>
	<CAGBzy2rxp8YdMBzu6+ABbJ9_DsKfiFLXXhd6gL4EaoPx8iVwsA@mail.gmail.com>
	<CAGBzy2qToPaOAMS738XN9Rtwus7W4ErzzN7ncp=h_0-JccjskA@mail.gmail.com>
	<20120602113511.GC11942@merlinux.eu>
	<CAGBzy2r+ybKk4cwwEcJWt7j8ate91Nb0YAa2UHR2QMSMaus-9Q@mail.gmail.com>
	<4FCF4608.80701@gmx.de> <20120606123518.GT11942@merlinux.eu>
	<CAGBzy2rerA_c9jO1goPa5WkSRU7H7u4fe3jFe8Cm+oYJenMstQ@mail.gmail.com>
	<4FD05692.6060507@gmx.de>
Message-ID: <CAGBzy2qmPdkzL9W_DYspLutjMTR6Q8PLsA7Y+ivoLJe3AGJ_Hw@mail.gmail.com>

Hi Holger, Ronny

> is there some suggested readng for the workflow changes?
> (i really didn't investigate further than it exists and uses .po)
I haven't known Sphinx i18n feature well, either. Sorry, I'm not sure
we need the workflow changes. Let me look into more detail.

By the way, I'm happy that the Japanese translation for 2.2.4 will put
on pytest.org if it isn't much hand work.

thanks,
Tetsuya

On Thu, Jun 7, 2012 at 4:21 PM, Ronny Pfannschmidt
<Ronny.Pfannschmidt at gmx.de> wrote:
> Hi Holger, Tetsuya
>
> is there some suggested readng for the workflow changes?
> (i really didn't investigate further than it exists and uses .po)
>
> we might also want to investgate something like transifex
> for making it easy for translators to translate the docs
>
> -- Ronny
>
>
> On 06/07/2012 02:09 AM, Tetsuya Morimoto wrote:
>>
>> Hi Holger, Ronny
>>
>> In my opinion, I agree with Ronny's idea (use Sphinx i18n feature),
>> because of its maintainability.
>>
>> However, we need to change some operations for documentation workflow
>> if we started to use Sphinx i18n feature. I don't know you want it or
>> not, in this time.
>>
>> Though I haven't used Sphinx i18n feature, I'm willing to investigate
>> the functionality and make the documentation workflow if you want.
>>
>> thanks,
>> Tetsuya
>>
>> On Wed, Jun 6, 2012 at 9:35 PM, holger krekel<holger at merlinux.eu> ?wrote:
>>>
>>> Hello Ronny,
>>>
>>> On Wed, Jun 06, 2012 at 13:59 +0200, Ronny Pfannschmidt wrote:
>>>>
>>>> Hi Holger, Tetsuya
>>>>
>>>> while taking a look i noticed that sphinx has a integrated
>>>> translation system based on .po files
>>>>
>>>> see http://sphinx.pocoo.org/latest/intl.html
>>>>
>>>> im under the impression that this way is more maintainable than he
>>>> current way due to using standard tools to manage translated strings
>>>>
>>>> i'd like to suggest some investigation in its usefullness
>>>
>>>
>>> I am happy to consider using it - not sure i get to try it myself
>>> any time soon and wonder specifically if a two-language situation with
>>> not so often changing docs warrants using the above system.
>>>
>>> Tetsuya, what do you think? Can you imagine investigating a bit?
>>>
>>> best,
>>> holger
>>>
>>>> -- ronny
>>>>
>>>>
>


From holger at merlinux.eu  Thu Jun  7 19:29:05 2012
From: holger at merlinux.eu (holger krekel)
Date: Thu, 7 Jun 2012 17:29:05 +0000
Subject: [py-dev] pytest documents with Japanese translation
In-Reply-To: <CAGBzy2qmPdkzL9W_DYspLutjMTR6Q8PLsA7Y+ivoLJe3AGJ_Hw@mail.gmail.com>
References: <20120529141351.GE10174@merlinux.eu>
	<CAGBzy2rxp8YdMBzu6+ABbJ9_DsKfiFLXXhd6gL4EaoPx8iVwsA@mail.gmail.com>
	<CAGBzy2qToPaOAMS738XN9Rtwus7W4ErzzN7ncp=h_0-JccjskA@mail.gmail.com>
	<20120602113511.GC11942@merlinux.eu>
	<CAGBzy2r+ybKk4cwwEcJWt7j8ate91Nb0YAa2UHR2QMSMaus-9Q@mail.gmail.com>
	<4FCF4608.80701@gmx.de> <20120606123518.GT11942@merlinux.eu>
	<CAGBzy2rerA_c9jO1goPa5WkSRU7H7u4fe3jFe8Cm+oYJenMstQ@mail.gmail.com>
	<4FD05692.6060507@gmx.de>
	<CAGBzy2qmPdkzL9W_DYspLutjMTR6Q8PLsA7Y+ivoLJe3AGJ_Hw@mail.gmail.com>
Message-ID: <20120607172905.GZ11942@merlinux.eu>

Hi Tetsuya, Ronny,

i created a preliminary http://pytest.org/latest-ja, it is online now!

i tried to fix regendocs - i pushed a commit which 
should handle encoding more correctly.  But there is a new problem.
I think you translated the directive "# content of PATH" which regendoc
uses to create files - so regendoc gets problems there. Not sure
what's the best way to fix it.

I also changed the way docs are versioned: en/conf.py and ja/conf.py
now contain a more fine grained version which can diverge according
to translation/documentation status.  Currently the en/conf.py
has two more examples (i added them the last two days) and the
version 2.2.4.1 whereas the ja/conf.py has 2.2.4.0 which still
strictly relates to the docs at 2.2.4 release time.

Tetsuya, if you want to be able to commit/push to doc/ja/*
i can happily add you.  I'd also like to eventually allow
you to push the japanese docs yourself or have some automated
way. We should also think about creating a Japenese PDF
(see the latestpdf target in the makefile).

best,
holger

On Thu, Jun 07, 2012 at 21:03 +0900, Tetsuya Morimoto wrote:
> Hi Holger, Ronny
> 
> > is there some suggested readng for the workflow changes?
> > (i really didn't investigate further than it exists and uses .po)
> I haven't known Sphinx i18n feature well, either. Sorry, I'm not sure
> we need the workflow changes. Let me look into more detail.
> 
> By the way, I'm happy that the Japanese translation for 2.2.4 will put
> on pytest.org if it isn't much hand work.
> 
> thanks,
> Tetsuya
> 
> On Thu, Jun 7, 2012 at 4:21 PM, Ronny Pfannschmidt
> <Ronny.Pfannschmidt at gmx.de> wrote:
> > Hi Holger, Tetsuya
> >
> > is there some suggested readng for the workflow changes?
> > (i really didn't investigate further than it exists and uses .po)
> >
> > we might also want to investgate something like transifex
> > for making it easy for translators to translate the docs
> >
> > -- Ronny
> >
> >
> > On 06/07/2012 02:09 AM, Tetsuya Morimoto wrote:
> >>
> >> Hi Holger, Ronny
> >>
> >> In my opinion, I agree with Ronny's idea (use Sphinx i18n feature),
> >> because of its maintainability.
> >>
> >> However, we need to change some operations for documentation workflow
> >> if we started to use Sphinx i18n feature. I don't know you want it or
> >> not, in this time.
> >>
> >> Though I haven't used Sphinx i18n feature, I'm willing to investigate
> >> the functionality and make the documentation workflow if you want.
> >>
> >> thanks,
> >> Tetsuya
> >>
> >> On Wed, Jun 6, 2012 at 9:35 PM, holger krekel<holger at merlinux.eu> ?wrote:
> >>>
> >>> Hello Ronny,
> >>>
> >>> On Wed, Jun 06, 2012 at 13:59 +0200, Ronny Pfannschmidt wrote:
> >>>>
> >>>> Hi Holger, Tetsuya
> >>>>
> >>>> while taking a look i noticed that sphinx has a integrated
> >>>> translation system based on .po files
> >>>>
> >>>> see http://sphinx.pocoo.org/latest/intl.html
> >>>>
> >>>> im under the impression that this way is more maintainable than he
> >>>> current way due to using standard tools to manage translated strings
> >>>>
> >>>> i'd like to suggest some investigation in its usefullness
> >>>
> >>>
> >>> I am happy to consider using it - not sure i get to try it myself
> >>> any time soon and wonder specifically if a two-language situation with
> >>> not so often changing docs warrants using the above system.
> >>>
> >>> Tetsuya, what do you think? Can you imagine investigating a bit?
> >>>
> >>> best,
> >>> holger
> >>>
> >>>> -- ronny
> >>>>
> >>>>
> >
> 


From holger at merlinux.eu  Wed Jun 13 16:26:07 2012
From: holger at merlinux.eu (holger krekel)
Date: Wed, 13 Jun 2012 14:26:07 +0000
Subject: [py-dev] detox-0.9: speeding up tox/test runs with NUM(CORES)
Message-ID: <20120613142607.GK11942@merlinux.eu>

Morning all,

be the goats with you.

I've finally released detox-0.9 to PYPI which brings parallelizing
tox/test runs to your console, driving the test runner of your choice.
detox has the same options and invocation as the good old
one-step-after-the-other tox, the virtualenv-based generic test runner
(see http://tox.testrun.org).

install detox (and get tox installed for free!) with:

    pip install detox

and run it on a project which already has a tox.ini 
with some environments:

    detox -e py26,py27,pypy

to have all happen in parallel (packaging, virtualenv-creation,
installation of deps, running of tests).

Be the first to report issues to:

    http://bitbucket.org/hpk42/detox/issues

best,
holger

P.S.: due to the recent refactoring of tox and due to the superiority
of greenlet-based programming models, detox is only 175 lines of 
somewhat easy to read code :)


From tseaver at palladion.com  Thu Jun 14 16:13:12 2012
From: tseaver at palladion.com (Tres Seaver)
Date: Thu, 14 Jun 2012 10:13:12 -0400
Subject: [py-dev] detox-0.9: speeding up tox/test runs with NUM(CORES)
In-Reply-To: <20120614081639.GB27643@platonas>
References: <20120613142607.GK11942@merlinux.eu>
	<20120614081639.GB27643@platonas>
Message-ID: <jrcrho$3d0$1@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/14/2012 04:16 AM, Marius Gedminas wrote:
> On Wed, Jun 13, 2012 at 02:26:07PM +0000, holger krekel wrote:
>> I've finally released detox-0.9 to PYPI which brings parallelizing 
>> tox/test runs to your console, driving the test runner of your
>> choice. detox has the same options and invocation as the good old 
>> one-step-after-the-other tox, the virtualenv-based generic test
>> runner (see http://tox.testrun.org).
> 
> It.  Is.  AWESOME!

Agreed.  Very noce work indeed.


Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/Z8XMACgkQ+gerLs4ltQ7OjwCfQwVdcSz6G3xZr967nW89A2GE
9uAAn0flCcL9wAPtJ1ffP38WJXd0BhQX
=N0G6
-----END PGP SIGNATURE-----



From imichaelmiers at gmail.com  Sat Jun 16 02:32:50 2012
From: imichaelmiers at gmail.com (Ian Miers)
Date: Fri, 15 Jun 2012 20:32:50 -0400
Subject: [py-dev] intermittent bugs in pytest/python on osx lion ?
Message-ID: <CAEC9zAZDKitA0WYd+AE5Cz=bMApweao-J127+kMxSRJ0vZ0f5g@mail.gmail.com>

Hi, I just started using pytest. It's lovely.
The TLDR on this is we are getting intermittent non reproducible errors
 that change and sometimes disappear between test runs like the following :
>   import os.path
E   TypeError: __import__() argument 1 must be str without null bytes, not
str

Longer version:
We've been getting buggy results out of test runs on OSX Lion with python
3.2.3  and  py.test version 2.2.4. Specifically we've been getting what
appear to be false-positive  test failures that change from run to run  and
cannot be reproduced by running some code ourselves or in the case of
doctest manually running  python3.2 -m doctest file.

Some of these errors will stay around for multiple test runs even after
make clean, etc. Some will change from run to run. All of them
eventually disappeared  temporarily and we got a clean test pass, though
how I don't know. Morever, the problems cropped up again. All of this was
with no code changes and code known to work on ubuntu and partially
manually tested on OSX.

Ordinarly I'd say there was something wrong with our code. However, some of
the errors are vanishingly unlikely. Claims that modules don't exist when
they do and are importable via python3.2 -c "from foo.bar.baz import narf"
and such.

The most glaringly, however, is this gem:
charm/toolbox/pairinggroup.py:3: in <module>
>   import os.path
E   TypeError: __import__() argument 1 must be str without null bytes, not
str

We also got a lovely bug where it appeared __pycache__  was corrupted
during test runs.  On an initial run, we could import a function from a
python c extension. On subsequent runs, it didn't exist. The function was
still in the .so file, as shown by nm, however help(module) returned
function_name#$@^%#$% Function description. Deleting __pychache__ folders
 resolved it for the next test run but then it came back. It too
disappeared after a couple of test runs never to be seen since.

Has anyone seen anyhting like this? Are their known issues on OSX with
python ? With pytest? Does anyone have any idea how I might get a better
idea whats going on?

As an addendum, the latest error I am getting is now :
>   test = [hashFn(struct.pack(">%dsI" % (len(seed)), seed, i)) for i in
ran]
E   UnicodeEncodeError: 'ascii' codec can't encode character '\x9e' in
position 0: ordinal not in range(128
This actually might be in our code,though again it works on ubuntu and at
one point on OSX.  Given that its a pattern that points to python or pytest
doing something  to binaries,  I'm including it anyway.

The project is charm, you can see the code on this branch here via
https://github.com/JHUISI/charm/tree/dev. Python was installed via fenc ( I
think, its not my box). The errors happened both with python3.2 -m pytest
 and with python3.2 setup.py test.  Though it appears more so with the
later.

Thanks,

Ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20120615/0a2ea86a/attachment.html>

From holger at merlinux.eu  Sat Jun 16 10:19:54 2012
From: holger at merlinux.eu (holger krekel)
Date: Sat, 16 Jun 2012 08:19:54 +0000
Subject: [py-dev] intermittent bugs in pytest/python on osx lion ?
In-Reply-To: <CAEC9zAZDKitA0WYd+AE5Cz=bMApweao-J127+kMxSRJ0vZ0f5g@mail.gmail.com>
References: <CAEC9zAZDKitA0WYd+AE5Cz=bMApweao-J127+kMxSRJ0vZ0f5g@mail.gmail.com>
Message-ID: <20120616081954.GU11942@merlinux.eu>

Hi Ian,

On Fri, Jun 15, 2012 at 20:32 -0400, Ian Miers wrote:
> Hi, I just started using pytest. It's lovely.
> The TLDR on this is we are getting intermittent non reproducible errors
>  that change and sometimes disappear between test runs like the following :
> >   import os.path
> E   TypeError: __import__() argument 1 must be str without null bytes, not
> str

Looks odd.  pytest does not override __import__ but it does by default
use a PEP302 compliant module loader.  If you use

    py.test --assert=reinterpret  # or --assert=plain

do the errors go away?  If so that points to a problem in pytest's module
loader or some interaction problem with python3.2.

If changing the assertion mode still leads to errors then i strongly
suspect it's other parts of the code you are running.  I'd then suggest
to check if something in your environment modifies __import__
e.g. by writing a test that checks/prints out __import__?

best,
holger

> Longer version:
> We've been getting buggy results out of test runs on OSX Lion with python
> 3.2.3  and  py.test version 2.2.4. Specifically we've been getting what
> appear to be false-positive  test failures that change from run to run  and
> cannot be reproduced by running some code ourselves or in the case of
> doctest manually running  python3.2 -m doctest file.
> 
> Some of these errors will stay around for multiple test runs even after
> make clean, etc. Some will change from run to run. All of them
> eventually disappeared  temporarily and we got a clean test pass, though
> how I don't know. Morever, the problems cropped up again. All of this was
> with no code changes and code known to work on ubuntu and partially
> manually tested on OSX.
> 
> Ordinarly I'd say there was something wrong with our code. However, some of
> the errors are vanishingly unlikely. Claims that modules don't exist when
> they do and are importable via python3.2 -c "from foo.bar.baz import narf"
> and such.
> 
> The most glaringly, however, is this gem:
> charm/toolbox/pairinggroup.py:3: in <module>
> >   import os.path
> E   TypeError: __import__() argument 1 must be str without null bytes, not
> str
> 
> We also got a lovely bug where it appeared __pycache__  was corrupted
> during test runs.  On an initial run, we could import a function from a
> python c extension. On subsequent runs, it didn't exist. The function was
> still in the .so file, as shown by nm, however help(module) returned
> function_name#$@^%#$% Function description. Deleting __pychache__ folders
>  resolved it for the next test run but then it came back. It too
> disappeared after a couple of test runs never to be seen since.
> 
> Has anyone seen anyhting like this? Are their known issues on OSX with
> python ? With pytest? Does anyone have any idea how I might get a better
> idea whats going on?
> 
> As an addendum, the latest error I am getting is now :
> >   test = [hashFn(struct.pack(">%dsI" % (len(seed)), seed, i)) for i in
> ran]
> E   UnicodeEncodeError: 'ascii' codec can't encode character '\x9e' in
> position 0: ordinal not in range(128
> This actually might be in our code,though again it works on ubuntu and at
> one point on OSX.  Given that its a pattern that points to python or pytest
> doing something  to binaries,  I'm including it anyway.
> 
> The project is charm, you can see the code on this branch here via
> https://github.com/JHUISI/charm/tree/dev. Python was installed via fenc ( I
> think, its not my box). The errors happened both with python3.2 -m pytest
>  and with python3.2 setup.py test.  Though it appears more so with the
> later.
> 
> Thanks,
> 
> Ian

> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev



From holger at merlinux.eu  Sat Jun 16 17:41:30 2012
From: holger at merlinux.eu (holger krekel)
Date: Sat, 16 Jun 2012 15:41:30 +0000
Subject: [py-dev] pytest-pep8-0.9.1: compatibility to pep8-1.3
Message-ID: <20120616154130.GV11942@merlinux.eu>


I just did a quick release of pytest-pep8, version 0.9.1 which fixes
compatibility issues with the recent pep8 package (1.3).

See http://pypi.python.org/pypi/pytest-pep8 for more info.

best,
holger



From imichaelmiers at gmail.com  Sat Jun 16 17:59:23 2012
From: imichaelmiers at gmail.com (Ian Miers)
Date: Sat, 16 Jun 2012 11:59:23 -0400
Subject: [py-dev] intermittent bugs in pytest/python on osx lion ?
In-Reply-To: <20120616081954.GU11942@merlinux.eu>
References: <CAEC9zAZDKitA0WYd+AE5Cz=bMApweao-J127+kMxSRJ0vZ0f5g@mail.gmail.com>
	<20120616081954.GU11942@merlinux.eu>
Message-ID: <CAEC9zAYfhpaxvgvadfSvJw6VHK30R9ZyxU3FvtHzcdtggLBxEg@mail.gmail.com>

So these issues only happen on OSX and as I said,they come and go and
change,which is why I am skeptical it's our code. Actually if I had to
guess I'd say its something with python3 on OSX Lion, but so far we've only
seen the issues in test runs, not when attempting to manually recreate the
issue.

Regarding import os.path error, I got it again. Trying to import the module
containing  that import after that error caused a bus error. However all
subsequent imports worked fine. The strange thing is that the pyc file
didn't change ( or at least its md5 sum didn't) and the modification date
for all of the pyc files for that package remain unchanged.


 python3.2 -m pytest --assert=plain seemed to work for a little bit, but
then we started getting the same intermittent changing  errors.

Allmost all runs with assert=reinterp  , including after removing all
__pychache__ and recompiling the c extensions  produce the INTERNALERROR
 below.



Thanks again,
Ian

python3.2 -m pytest --assert=reinterp
============================= test session starts
==============================
platform darwin -- Python 3.2.3 -- pytest-2.2.4
collected 232 items

schemes/__init__.py .
schemes/chamhash_adm05.py .
schemes/chamhash_rsa_hw09.py .
schemes/encap_bchk05.py .
schemes/pk_fre_ccv11.py .
schemes/pk_vrf.py .
schemes/protocol_cns07.py .
schemes/protocol_schnorr91.py .
schemes/sigma1.py .
schemes/sigma2.py .
schemes/sigma3.py .
schemes/abenc/__init__.py .
schemes/abenc/abenc_adapt_hybrid.py F
schemes/abenc/abenc_bsw07.py .
schemes/abenc/abenc_lsw08.py .
schemes/abenc/abenc_waters09.py .
schemes/abenc/kpabenc_adapt_hybrid.py F
schemes/commit/__init__.py .
schemes/commit/commit_gs08.py .
schemes/commit/commit_pedersen92.py .
schemes/dabenc/__init__.py .
schemes/dabenc/dabe_aw11.py
INTERNALERROR> Traceback (most recent call last):
INTERNALERROR>   File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/main.py",
line 74, in wrap_session
INTERNALERROR>     doit(config, session)
INTERNALERROR>   File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/main.py",
line 106, in _main
INTERNALERROR>     config.hook.pytest_runtestloop(session=session)
INTERNALERROR>   File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
line 421, in __call__
INTERNALERROR>     return self._docall(methods, kwargs)
INTERNALERROR>   File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
line 432, in _docall
INTERNALERROR>     res = mc.execute()
INTERNALERROR>   File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
line 350, in execute
INTERNALERROR>     res = method(**kwargs)
INTERNALERROR>   File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/main.py",
line 119, in pytest_runtestloop
INTERNALERROR>     item.config.hook.pytest_runtest_protocol(item=item,
nextitem=nextitem)
INTERNALERROR>   File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
line 421, in __call__
INTERNALERROR>     return self._docall(methods, kwargs)
INTERNALERROR>   File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
line 432, in _docall
INTERNALERROR>     res = mc.execute()
INTERNALERROR>   File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
line 350, in execute
INTERNALERROR>     res = method(**kwargs)
INTERNALERROR>   File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/runner.py",
line 61, in pytest_runtest_protocol
INTERNALERROR>     runtestprotocol(item, nextitem=nextitem)
INTERNALERROR>   File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/runner.py",
line 68, in runtestprotocol
INTERNALERROR>     reports.append(call_and_report(item, "call", log))
INTERNALERROR>   File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/runner.py",
line 99, in call_and_report
INTERNALERROR>     report = hook.pytest_runtest_makereport(item=item,
call=call)
INTERNALERROR>   File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/main.py",
line 141, in call_matching_hooks
INTERNALERROR>     return hookmethod.pcall(plugins, **kwargs)
INTERNALERROR>   File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
line 425, in pcall
INTERNALERROR>     return self._docall(methods, kwargs)
INTERNALERROR>   File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
line 432, in _docall
INTERNALERROR>     res = mc.execute()
INTERNALERROR>   File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
line 350, in execute
INTERNALERROR>     res = method(**kwargs)
INTERNALERROR>   File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/capture.py",
line 173, in pytest_runtest_makereport
INTERNALERROR>     rep = __multicall__.execute()
INTERNALERROR>   File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
line 350, in execute
INTERNALERROR>     res = method(**kwargs)
INTERNALERROR>   File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/runner.py",
line 187, in pytest_runtest_makereport
INTERNALERROR>     longrepr = item.repr_failure(excinfo)
INTERNALERROR>   File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/doctest.py",
line 44, in repr_failure
INTERNALERROR>     lineno = test.lineno + example.lineno + 1
INTERNALERROR> TypeError: unsupported operand type(s) for +: 'NoneType' and
'int'

===================== 2 failed, 19 passed in 3.42 seconds
======================




On Sat, Jun 16, 2012 at 4:19 AM, holger krekel <holger at merlinux.eu> wrote:

> Hi Ian,
>
> On Fri, Jun 15, 2012 at 20:32 -0400, Ian Miers wrote:
> > Hi, I just started using pytest. It's lovely.
> > The TLDR on this is we are getting intermittent non reproducible errors
> >  that change and sometimes disappear between test runs like the
> following :
> > >   import os.path
> > E   TypeError: __import__() argument 1 must be str without null bytes,
> not
> > str
>
> Looks odd.  pytest does not override __import__ but it does by default
> use a PEP302 compliant module loader.  If you use
>
>    py.test --assert=reinterpret  # or --assert=plain
>
> do the errors go away?  If so that points to a problem in pytest's module
> loader or some interaction problem with python3.2.
>
> If changing the assertion mode still leads to errors then i strongly
> suspect it's other parts of the code you are running.  I'd then suggest
> to check if something in your environment modifies __import__
> e.g. by writing a test that checks/prints out __import__?
>
> best,
> holger
>
> > Longer version:
> > We've been getting buggy results out of test runs on OSX Lion with python
> > 3.2.3  and  py.test version 2.2.4. Specifically we've been getting what
> > appear to be false-positive  test failures that change from run to run
>  and
> > cannot be reproduced by running some code ourselves or in the case of
> > doctest manually running  python3.2 -m doctest file.
> >
> > Some of these errors will stay around for multiple test runs even after
> > make clean, etc. Some will change from run to run. All of them
> > eventually disappeared  temporarily and we got a clean test pass, though
> > how I don't know. Morever, the problems cropped up again. All of this was
> > with no code changes and code known to work on ubuntu and partially
> > manually tested on OSX.
> >
> > Ordinarly I'd say there was something wrong with our code. However, some
> of
> > the errors are vanishingly unlikely. Claims that modules don't exist when
> > they do and are importable via python3.2 -c "from foo.bar.baz import
> narf"
> > and such.
> >
> > The most glaringly, however, is this gem:
> > charm/toolbox/pairinggroup.py:3: in <module>
> > >   import os.path
> > E   TypeError: __import__() argument 1 must be str without null bytes,
> not
> > str
> >
> > We also got a lovely bug where it appeared __pycache__  was corrupted
> > during test runs.  On an initial run, we could import a function from a
> > python c extension. On subsequent runs, it didn't exist. The function was
> > still in the .so file, as shown by nm, however help(module) returned
> > function_name#$@^%#$% Function description. Deleting __pychache__ folders
> >  resolved it for the next test run but then it came back. It too
> > disappeared after a couple of test runs never to be seen since.
> >
> > Has anyone seen anyhting like this? Are their known issues on OSX with
> > python ? With pytest? Does anyone have any idea how I might get a better
> > idea whats going on?
> >
> > As an addendum, the latest error I am getting is now :
> > >   test = [hashFn(struct.pack(">%dsI" % (len(seed)), seed, i)) for i in
> > ran]
> > E   UnicodeEncodeError: 'ascii' codec can't encode character '\x9e' in
> > position 0: ordinal not in range(128
> > This actually might be in our code,though again it works on ubuntu and at
> > one point on OSX.  Given that its a pattern that points to python or
> pytest
> > doing something  to binaries,  I'm including it anyway.
> >
> > The project is charm, you can see the code on this branch here via
> > https://github.com/JHUISI/charm/tree/dev. Python was installed via fenc
> ( I
> > think, its not my box). The errors happened both with python3.2 -m pytest
> >  and with python3.2 setup.py test.  Though it appears more so with the
> > later.
> >
> > Thanks,
> >
> > Ian
>
> > _______________________________________________
> > py-dev mailing list
> > py-dev at codespeak.net
> > http://codespeak.net/mailman/listinfo/py-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20120616/9ac284ac/attachment.html>

From holger at merlinux.eu  Sat Jun 16 18:30:29 2012
From: holger at merlinux.eu (holger krekel)
Date: Sat, 16 Jun 2012 16:30:29 +0000
Subject: [py-dev] intermittent bugs in pytest/python on osx lion ?
In-Reply-To: <CAEC9zAYfhpaxvgvadfSvJw6VHK30R9ZyxU3FvtHzcdtggLBxEg@mail.gmail.com>
References: <CAEC9zAZDKitA0WYd+AE5Cz=bMApweao-J127+kMxSRJ0vZ0f5g@mail.gmail.com>
	<20120616081954.GU11942@merlinux.eu>
	<CAEC9zAYfhpaxvgvadfSvJw6VHK30R9ZyxU3FvtHzcdtggLBxEg@mail.gmail.com>
Message-ID: <20120616163029.GW11942@merlinux.eu>

On Sat, Jun 16, 2012 at 11:59 -0400, Ian Miers wrote:
> So these issues only happen on OSX and as I said,they come and go and
> change,which is why I am skeptical it's our code. Actually if I had to
> guess I'd say its something with python3 on OSX Lion, but so far we've only
> seen the issues in test runs, not when attempting to manually recreate the
> issue.
> 
> Regarding import os.path error, I got it again. Trying to import the module
> containing  that import after that error caused a bus error. However all
> subsequent imports worked fine. The strange thing is that the pyc file
> didn't change ( or at least its md5 sum didn't) and the modification date
> for all of the pyc files for that package remain unchanged.
> 
> 
>  python3.2 -m pytest --assert=plain seemed to work for a little bit, but
> then we started getting the same intermittent changing  errors.

With --assert=plain pytest should not interfere with anything related
to importing.  Did you get the strange error with "import os.path" 
in this configuration?   Are you using any plugins (see output of
py.test --version)?

The below error may in principle be a doctest/pytest bug with
python3.2 although it would be strange if it only happened sometimes.

Holger

> Allmost all runs with assert=reinterp  , including after removing all
> __pychache__ and recompiling the c extensions  produce the INTERNALERROR
>  below.
> 
> 
> 
> Thanks again,
> Ian
> 
> python3.2 -m pytest --assert=reinterp
> ============================= test session starts
> ==============================
> platform darwin -- Python 3.2.3 -- pytest-2.2.4
> collected 232 items
> 
> schemes/__init__.py .
> schemes/chamhash_adm05.py .
> schemes/chamhash_rsa_hw09.py .
> schemes/encap_bchk05.py .
> schemes/pk_fre_ccv11.py .
> schemes/pk_vrf.py .
> schemes/protocol_cns07.py .
> schemes/protocol_schnorr91.py .
> schemes/sigma1.py .
> schemes/sigma2.py .
> schemes/sigma3.py .
> schemes/abenc/__init__.py .
> schemes/abenc/abenc_adapt_hybrid.py F
> schemes/abenc/abenc_bsw07.py .
> schemes/abenc/abenc_lsw08.py .
> schemes/abenc/abenc_waters09.py .
> schemes/abenc/kpabenc_adapt_hybrid.py F
> schemes/commit/__init__.py .
> schemes/commit/commit_gs08.py .
> schemes/commit/commit_pedersen92.py .
> schemes/dabenc/__init__.py .
> schemes/dabenc/dabe_aw11.py
> INTERNALERROR> Traceback (most recent call last):
> INTERNALERROR>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/main.py",
> line 74, in wrap_session
> INTERNALERROR>     doit(config, session)
> INTERNALERROR>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/main.py",
> line 106, in _main
> INTERNALERROR>     config.hook.pytest_runtestloop(session=session)
> INTERNALERROR>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> line 421, in __call__
> INTERNALERROR>     return self._docall(methods, kwargs)
> INTERNALERROR>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> line 432, in _docall
> INTERNALERROR>     res = mc.execute()
> INTERNALERROR>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> line 350, in execute
> INTERNALERROR>     res = method(**kwargs)
> INTERNALERROR>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/main.py",
> line 119, in pytest_runtestloop
> INTERNALERROR>     item.config.hook.pytest_runtest_protocol(item=item,
> nextitem=nextitem)
> INTERNALERROR>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> line 421, in __call__
> INTERNALERROR>     return self._docall(methods, kwargs)
> INTERNALERROR>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> line 432, in _docall
> INTERNALERROR>     res = mc.execute()
> INTERNALERROR>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> line 350, in execute
> INTERNALERROR>     res = method(**kwargs)
> INTERNALERROR>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/runner.py",
> line 61, in pytest_runtest_protocol
> INTERNALERROR>     runtestprotocol(item, nextitem=nextitem)
> INTERNALERROR>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/runner.py",
> line 68, in runtestprotocol
> INTERNALERROR>     reports.append(call_and_report(item, "call", log))
> INTERNALERROR>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/runner.py",
> line 99, in call_and_report
> INTERNALERROR>     report = hook.pytest_runtest_makereport(item=item,
> call=call)
> INTERNALERROR>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/main.py",
> line 141, in call_matching_hooks
> INTERNALERROR>     return hookmethod.pcall(plugins, **kwargs)
> INTERNALERROR>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> line 425, in pcall
> INTERNALERROR>     return self._docall(methods, kwargs)
> INTERNALERROR>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> line 432, in _docall
> INTERNALERROR>     res = mc.execute()
> INTERNALERROR>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> line 350, in execute
> INTERNALERROR>     res = method(**kwargs)
> INTERNALERROR>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/capture.py",
> line 173, in pytest_runtest_makereport
> INTERNALERROR>     rep = __multicall__.execute()
> INTERNALERROR>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> line 350, in execute
> INTERNALERROR>     res = method(**kwargs)
> INTERNALERROR>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/runner.py",
> line 187, in pytest_runtest_makereport
> INTERNALERROR>     longrepr = item.repr_failure(excinfo)
> INTERNALERROR>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/doctest.py",
> line 44, in repr_failure
> INTERNALERROR>     lineno = test.lineno + example.lineno + 1
> INTERNALERROR> TypeError: unsupported operand type(s) for +: 'NoneType' and
> 'int'
> 
> ===================== 2 failed, 19 passed in 3.42 seconds
> ======================
> 
> 
> 
> 
> On Sat, Jun 16, 2012 at 4:19 AM, holger krekel <holger at merlinux.eu> wrote:
> 
> > Hi Ian,
> >
> > On Fri, Jun 15, 2012 at 20:32 -0400, Ian Miers wrote:
> > > Hi, I just started using pytest. It's lovely.
> > > The TLDR on this is we are getting intermittent non reproducible errors
> > >  that change and sometimes disappear between test runs like the
> > following :
> > > >   import os.path
> > > E   TypeError: __import__() argument 1 must be str without null bytes,
> > not
> > > str
> >
> > Looks odd.  pytest does not override __import__ but it does by default
> > use a PEP302 compliant module loader.  If you use
> >
> >    py.test --assert=reinterpret  # or --assert=plain
> >
> > do the errors go away?  If so that points to a problem in pytest's module
> > loader or some interaction problem with python3.2.
> >
> > If changing the assertion mode still leads to errors then i strongly
> > suspect it's other parts of the code you are running.  I'd then suggest
> > to check if something in your environment modifies __import__
> > e.g. by writing a test that checks/prints out __import__?
> >
> > best,
> > holger
> >
> > > Longer version:
> > > We've been getting buggy results out of test runs on OSX Lion with python
> > > 3.2.3  and  py.test version 2.2.4. Specifically we've been getting what
> > > appear to be false-positive  test failures that change from run to run
> >  and
> > > cannot be reproduced by running some code ourselves or in the case of
> > > doctest manually running  python3.2 -m doctest file.
> > >
> > > Some of these errors will stay around for multiple test runs even after
> > > make clean, etc. Some will change from run to run. All of them
> > > eventually disappeared  temporarily and we got a clean test pass, though
> > > how I don't know. Morever, the problems cropped up again. All of this was
> > > with no code changes and code known to work on ubuntu and partially
> > > manually tested on OSX.
> > >
> > > Ordinarly I'd say there was something wrong with our code. However, some
> > of
> > > the errors are vanishingly unlikely. Claims that modules don't exist when
> > > they do and are importable via python3.2 -c "from foo.bar.baz import
> > narf"
> > > and such.
> > >
> > > The most glaringly, however, is this gem:
> > > charm/toolbox/pairinggroup.py:3: in <module>
> > > >   import os.path
> > > E   TypeError: __import__() argument 1 must be str without null bytes,
> > not
> > > str
> > >
> > > We also got a lovely bug where it appeared __pycache__  was corrupted
> > > during test runs.  On an initial run, we could import a function from a
> > > python c extension. On subsequent runs, it didn't exist. The function was
> > > still in the .so file, as shown by nm, however help(module) returned
> > > function_name#$@^%#$% Function description. Deleting __pychache__ folders
> > >  resolved it for the next test run but then it came back. It too
> > > disappeared after a couple of test runs never to be seen since.
> > >
> > > Has anyone seen anyhting like this? Are their known issues on OSX with
> > > python ? With pytest? Does anyone have any idea how I might get a better
> > > idea whats going on?
> > >
> > > As an addendum, the latest error I am getting is now :
> > > >   test = [hashFn(struct.pack(">%dsI" % (len(seed)), seed, i)) for i in
> > > ran]
> > > E   UnicodeEncodeError: 'ascii' codec can't encode character '\x9e' in
> > > position 0: ordinal not in range(128
> > > This actually might be in our code,though again it works on ubuntu and at
> > > one point on OSX.  Given that its a pattern that points to python or
> > pytest
> > > doing something  to binaries,  I'm including it anyway.
> > >
> > > The project is charm, you can see the code on this branch here via
> > > https://github.com/JHUISI/charm/tree/dev. Python was installed via fenc
> > ( I
> > > think, its not my box). The errors happened both with python3.2 -m pytest
> > >  and with python3.2 setup.py test.  Though it appears more so with the
> > > later.
> > >
> > > Thanks,
> > >
> > > Ian
> >
> > > _______________________________________________
> > > py-dev mailing list
> > > py-dev at codespeak.net
> > > http://codespeak.net/mailman/listinfo/py-dev
> >
> >


From imichaelmiers at gmail.com  Sun Jun 17 03:39:42 2012
From: imichaelmiers at gmail.com (Ian Miers)
Date: Sat, 16 Jun 2012 21:39:42 -0400
Subject: [py-dev] intermittent bugs in pytest/python on osx lion ?
In-Reply-To: <20120616163029.GW11942@merlinux.eu>
References: <CAEC9zAZDKitA0WYd+AE5Cz=bMApweao-J127+kMxSRJ0vZ0f5g@mail.gmail.com>
	<20120616081954.GU11942@merlinux.eu>
	<CAEC9zAYfhpaxvgvadfSvJw6VHK30R9ZyxU3FvtHzcdtggLBxEg@mail.gmail.com>
	<20120616163029.GW11942@merlinux.eu>
Message-ID: <CAEC9zAZuhe50Wq8H3hbsbjBc0zLmD6P-MKuwn=UwARSK_2FoQw@mail.gmail.com>

Well, I just got the __import__ error  but with a different file and module
 using assert=plain and not running the doctest module.

The subsequent runs could not find a certain c extension function. I
removed all the __pytcache__  and .pyc files with git clean -fxd -e "**.so"
and  it claimed it can't import charm.core despite the fact that it exists
and can by  imported via python3.2 -c "import charm.core" (which is
imported from the expected location even ).  The next test pass worked.

No I am not using any plugins.

Interestingly, I just got the error on a run with the unittest module.
Though it maybe because something was corrupted since clearing the pyc
files fixed it.
I am now completely baffled.
It looks like something is , for lack of a better term, corrupting  the
running copy of the interpreted code.  Do you know anything that could
possibly do that? Poorly written c extensions perhaps ?

I think I am going to set up some script and just see if I can collect
errors with pytest and unittest

Ian





ython3.2 -m pytest --assert=plain
=============================================== test session starts
================================================
platform darwin -- Python 3.2.3 -- pytest-2.2.4
collected 98 items / 1 errors

schemes/test/chamhash_test.py ..
schemes/test/commit_test.py ..
schemes/test/dabenc_test.py ..
schemes/test/encap_bchk05_test.py .
schemes/test/grpsig_test.py ..
schemes/test/hibenc_test.py .
schemes/test/ibenc_test.py .........
schemes/test/pk_vrf_test.py .
schemes/test/pkenc_test.py ...........
schemes/test/pksig_test.py .................
schemes/test/rsa_alg_test.py ....
charm/test/toolbox/conversion_test.py ...
charm/test/toolbox/paddingschemes_test.py s..........
charm/test/toolbox/secretshare_test.py .
charm/test/toolbox/symcrypto_test.py ..........
charm/toolbox/paddingschemes_test.py s..........
charm/toolbox/symcrypto_test.py ..........

====================================================== ERRORS
======================================================
___________________________________ ERROR collecting
schemes/test/abenc_test.py ____________________________________
schemes/test/abenc_test.py:1: in <module>
>   from schemes.abenc.abenc_adapt_hybrid import HybridABEnc as HybridABEnc
schemes/abenc/abenc_adapt_hybrid.py:6: in <module>
>   from charm.toolbox.symcrypto import AuthenticatedCryptoAbstraction
charm/toolbox/symcrypto.py:9: in <module>
>   import hmac
E   TypeError: __import__() argument 1 must be str without null bytes, not
str

On Sat, Jun 16, 2012 at 12:30 PM, holger krekel <holger at merlinux.eu> wrote:

> On Sat, Jun 16, 2012 at 11:59 -0400, Ian Miers wrote:
> > So these issues only happen on OSX and as I said,they come and go and
> > change,which is why I am skeptical it's our code. Actually if I had to
> > guess I'd say its something with python3 on OSX Lion, but so far we've
> only
> > seen the issues in test runs, not when attempting to manually recreate
> the
> > issue.
> >
> > Regarding import os.path error, I got it again. Trying to import the
> module
> > containing  that import after that error caused a bus error. However all
> > subsequent imports worked fine. The strange thing is that the pyc file
> > didn't change ( or at least its md5 sum didn't) and the modification date
> > for all of the pyc files for that package remain unchanged.
> >
> >
> >  python3.2 -m pytest --assert=plain seemed to work for a little bit, but
> > then we started getting the same intermittent changing  errors.
>
> With --assert=plain pytest should not interfere with anything related
> to importing.  Did you get the strange error with "import os.path"
> in this configuration?   Are you using any plugins (see output of
> py.test --version)?
>
> The below error may in principle be a doctest/pytest bug with
> python3.2 although it would be strange if it only happened sometimes.
>
> Holger
>
> > Allmost all runs with assert=reinterp  , including after removing all
> > __pychache__ and recompiling the c extensions  produce the INTERNALERROR
> >  below.
> >
> >
> >
> > Thanks again,
> > Ian
> >
> > python3.2 -m pytest --assert=reinterp
> > ============================= test session starts
> > ==============================
> > platform darwin -- Python 3.2.3 -- pytest-2.2.4
> > collected 232 items
> >
> > schemes/__init__.py .
> > schemes/chamhash_adm05.py .
> > schemes/chamhash_rsa_hw09.py .
> > schemes/encap_bchk05.py .
> > schemes/pk_fre_ccv11.py .
> > schemes/pk_vrf.py .
> > schemes/protocol_cns07.py .
> > schemes/protocol_schnorr91.py .
> > schemes/sigma1.py .
> > schemes/sigma2.py .
> > schemes/sigma3.py .
> > schemes/abenc/__init__.py .
> > schemes/abenc/abenc_adapt_hybrid.py F
> > schemes/abenc/abenc_bsw07.py .
> > schemes/abenc/abenc_lsw08.py .
> > schemes/abenc/abenc_waters09.py .
> > schemes/abenc/kpabenc_adapt_hybrid.py F
> > schemes/commit/__init__.py .
> > schemes/commit/commit_gs08.py .
> > schemes/commit/commit_pedersen92.py .
> > schemes/dabenc/__init__.py .
> > schemes/dabenc/dabe_aw11.py
> > INTERNALERROR> Traceback (most recent call last):
> > INTERNALERROR>   File
> >
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/main.py",
> > line 74, in wrap_session
> > INTERNALERROR>     doit(config, session)
> > INTERNALERROR>   File
> >
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/main.py",
> > line 106, in _main
> > INTERNALERROR>     config.hook.pytest_runtestloop(session=session)
> > INTERNALERROR>   File
> >
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> > line 421, in __call__
> > INTERNALERROR>     return self._docall(methods, kwargs)
> > INTERNALERROR>   File
> >
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> > line 432, in _docall
> > INTERNALERROR>     res = mc.execute()
> > INTERNALERROR>   File
> >
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> > line 350, in execute
> > INTERNALERROR>     res = method(**kwargs)
> > INTERNALERROR>   File
> >
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/main.py",
> > line 119, in pytest_runtestloop
> > INTERNALERROR>     item.config.hook.pytest_runtest_protocol(item=item,
> > nextitem=nextitem)
> > INTERNALERROR>   File
> >
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> > line 421, in __call__
> > INTERNALERROR>     return self._docall(methods, kwargs)
> > INTERNALERROR>   File
> >
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> > line 432, in _docall
> > INTERNALERROR>     res = mc.execute()
> > INTERNALERROR>   File
> >
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> > line 350, in execute
> > INTERNALERROR>     res = method(**kwargs)
> > INTERNALERROR>   File
> >
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/runner.py",
> > line 61, in pytest_runtest_protocol
> > INTERNALERROR>     runtestprotocol(item, nextitem=nextitem)
> > INTERNALERROR>   File
> >
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/runner.py",
> > line 68, in runtestprotocol
> > INTERNALERROR>     reports.append(call_and_report(item, "call", log))
> > INTERNALERROR>   File
> >
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/runner.py",
> > line 99, in call_and_report
> > INTERNALERROR>     report = hook.pytest_runtest_makereport(item=item,
> > call=call)
> > INTERNALERROR>   File
> >
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/main.py",
> > line 141, in call_matching_hooks
> > INTERNALERROR>     return hookmethod.pcall(plugins, **kwargs)
> > INTERNALERROR>   File
> >
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> > line 425, in pcall
> > INTERNALERROR>     return self._docall(methods, kwargs)
> > INTERNALERROR>   File
> >
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> > line 432, in _docall
> > INTERNALERROR>     res = mc.execute()
> > INTERNALERROR>   File
> >
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> > line 350, in execute
> > INTERNALERROR>     res = method(**kwargs)
> > INTERNALERROR>   File
> >
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/capture.py",
> > line 173, in pytest_runtest_makereport
> > INTERNALERROR>     rep = __multicall__.execute()
> > INTERNALERROR>   File
> >
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> > line 350, in execute
> > INTERNALERROR>     res = method(**kwargs)
> > INTERNALERROR>   File
> >
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/runner.py",
> > line 187, in pytest_runtest_makereport
> > INTERNALERROR>     longrepr = item.repr_failure(excinfo)
> > INTERNALERROR>   File
> >
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/doctest.py",
> > line 44, in repr_failure
> > INTERNALERROR>     lineno = test.lineno + example.lineno + 1
> > INTERNALERROR> TypeError: unsupported operand type(s) for +: 'NoneType'
> and
> > 'int'
> >
> > ===================== 2 failed, 19 passed in 3.42 seconds
> > ======================
> >
> >
> >
> >
> > On Sat, Jun 16, 2012 at 4:19 AM, holger krekel <holger at merlinux.eu>
> wrote:
> >
> > > Hi Ian,
> > >
> > > On Fri, Jun 15, 2012 at 20:32 -0400, Ian Miers wrote:
> > > > Hi, I just started using pytest. It's lovely.
> > > > The TLDR on this is we are getting intermittent non reproducible
> errors
> > > >  that change and sometimes disappear between test runs like the
> > > following :
> > > > >   import os.path
> > > > E   TypeError: __import__() argument 1 must be str without null
> bytes,
> > > not
> > > > str
> > >
> > > Looks odd.  pytest does not override __import__ but it does by default
> > > use a PEP302 compliant module loader.  If you use
> > >
> > >    py.test --assert=reinterpret  # or --assert=plain
> > >
> > > do the errors go away?  If so that points to a problem in pytest's
> module
> > > loader or some interaction problem with python3.2.
> > >
> > > If changing the assertion mode still leads to errors then i strongly
> > > suspect it's other parts of the code you are running.  I'd then suggest
> > > to check if something in your environment modifies __import__
> > > e.g. by writing a test that checks/prints out __import__?
> > >
> > > best,
> > > holger
> > >
> > > > Longer version:
> > > > We've been getting buggy results out of test runs on OSX Lion with
> python
> > > > 3.2.3  and  py.test version 2.2.4. Specifically we've been getting
> what
> > > > appear to be false-positive  test failures that change from run to
> run
> > >  and
> > > > cannot be reproduced by running some code ourselves or in the case of
> > > > doctest manually running  python3.2 -m doctest file.
> > > >
> > > > Some of these errors will stay around for multiple test runs even
> after
> > > > make clean, etc. Some will change from run to run. All of them
> > > > eventually disappeared  temporarily and we got a clean test pass,
> though
> > > > how I don't know. Morever, the problems cropped up again. All of
> this was
> > > > with no code changes and code known to work on ubuntu and partially
> > > > manually tested on OSX.
> > > >
> > > > Ordinarly I'd say there was something wrong with our code. However,
> some
> > > of
> > > > the errors are vanishingly unlikely. Claims that modules don't exist
> when
> > > > they do and are importable via python3.2 -c "from foo.bar.baz import
> > > narf"
> > > > and such.
> > > >
> > > > The most glaringly, however, is this gem:
> > > > charm/toolbox/pairinggroup.py:3: in <module>
> > > > >   import os.path
> > > > E   TypeError: __import__() argument 1 must be str without null
> bytes,
> > > not
> > > > str
> > > >
> > > > We also got a lovely bug where it appeared __pycache__  was corrupted
> > > > during test runs.  On an initial run, we could import a function
> from a
> > > > python c extension. On subsequent runs, it didn't exist. The
> function was
> > > > still in the .so file, as shown by nm, however help(module) returned
> > > > function_name#$@^%#$% Function description. Deleting __pychache__
> folders
> > > >  resolved it for the next test run but then it came back. It too
> > > > disappeared after a couple of test runs never to be seen since.
> > > >
> > > > Has anyone seen anyhting like this? Are their known issues on OSX
> with
> > > > python ? With pytest? Does anyone have any idea how I might get a
> better
> > > > idea whats going on?
> > > >
> > > > As an addendum, the latest error I am getting is now :
> > > > >   test = [hashFn(struct.pack(">%dsI" % (len(seed)), seed, i)) for
> i in
> > > > ran]
> > > > E   UnicodeEncodeError: 'ascii' codec can't encode character '\x9e'
> in
> > > > position 0: ordinal not in range(128
> > > > This actually might be in our code,though again it works on ubuntu
> and at
> > > > one point on OSX.  Given that its a pattern that points to python or
> > > pytest
> > > > doing something  to binaries,  I'm including it anyway.
> > > >
> > > > The project is charm, you can see the code on this branch here via
> > > > https://github.com/JHUISI/charm/tree/dev. Python was installed via
> fenc
> > > ( I
> > > > think, its not my box). The errors happened both with python3.2 -m
> pytest
> > > >  and with python3.2 setup.py test.  Though it appears more so with
> the
> > > > later.
> > > >
> > > > Thanks,
> > > >
> > > > Ian
> > >
> > > > _______________________________________________
> > > > py-dev mailing list
> > > > py-dev at codespeak.net
> > > > http://codespeak.net/mailman/listinfo/py-dev
> > >
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20120616/c2c0d0f7/attachment.html>

From holger at merlinux.eu  Sun Jun 17 10:03:08 2012
From: holger at merlinux.eu (holger krekel)
Date: Sun, 17 Jun 2012 08:03:08 +0000
Subject: [py-dev] intermittent bugs in pytest/python on osx lion ?
In-Reply-To: <CAEC9zAZuhe50Wq8H3hbsbjBc0zLmD6P-MKuwn=UwARSK_2FoQw@mail.gmail.com>
References: <CAEC9zAZDKitA0WYd+AE5Cz=bMApweao-J127+kMxSRJ0vZ0f5g@mail.gmail.com>
	<20120616081954.GU11942@merlinux.eu>
	<CAEC9zAYfhpaxvgvadfSvJw6VHK30R9ZyxU3FvtHzcdtggLBxEg@mail.gmail.com>
	<20120616163029.GW11942@merlinux.eu>
	<CAEC9zAZuhe50Wq8H3hbsbjBc0zLmD6P-MKuwn=UwARSK_2FoQw@mail.gmail.com>
Message-ID: <20120617080307.GX11942@merlinux.eu>


Thanks for your persistence.  I recommend also compiling Python-3.3 (not
released yet - you need to grab the repository i think)  and throwing
that in the mix. FYI you could use tox (http://tox.testrun.org) to
automate the various test runs.

Your guess of something corrupting bytecode makes sense.
You might want to use "export PYTHONDONTWRITECODE=1" to inhibit
pyc file writing (this also disables it for pytest's test module
assertion rewriting, so you may return to using the default 
assert mode).

good luck,
holger


On Sat, Jun 16, 2012 at 21:39 -0400, Ian Miers wrote:
> Well, I just got the __import__ error  but with a different file and module
>  using assert=plain and not running the doctest module.
> 
> The subsequent runs could not find a certain c extension function. I
> removed all the __pytcache__  and .pyc files with git clean -fxd -e "**.so"
> and  it claimed it can't import charm.core despite the fact that it exists
> and can by  imported via python3.2 -c "import charm.core" (which is
> imported from the expected location even ).  The next test pass worked.
> 
> No I am not using any plugins.
> 
> Interestingly, I just got the error on a run with the unittest module.
> Though it maybe because something was corrupted since clearing the pyc
> files fixed it.
> I am now completely baffled.
> It looks like something is , for lack of a better term, corrupting  the
> running copy of the interpreted code.  Do you know anything that could
> possibly do that? Poorly written c extensions perhaps ?
> 
> I think I am going to set up some script and just see if I can collect
> errors with pytest and unittest
> 
> Ian
> 
> 
> 
> 
> 
> ython3.2 -m pytest --assert=plain
> =============================================== test session starts
> ================================================
> platform darwin -- Python 3.2.3 -- pytest-2.2.4
> collected 98 items / 1 errors
> 
> schemes/test/chamhash_test.py ..
> schemes/test/commit_test.py ..
> schemes/test/dabenc_test.py ..
> schemes/test/encap_bchk05_test.py .
> schemes/test/grpsig_test.py ..
> schemes/test/hibenc_test.py .
> schemes/test/ibenc_test.py .........
> schemes/test/pk_vrf_test.py .
> schemes/test/pkenc_test.py ...........
> schemes/test/pksig_test.py .................
> schemes/test/rsa_alg_test.py ....
> charm/test/toolbox/conversion_test.py ...
> charm/test/toolbox/paddingschemes_test.py s..........
> charm/test/toolbox/secretshare_test.py .
> charm/test/toolbox/symcrypto_test.py ..........
> charm/toolbox/paddingschemes_test.py s..........
> charm/toolbox/symcrypto_test.py ..........
> 
> ====================================================== ERRORS
> ======================================================
> ___________________________________ ERROR collecting
> schemes/test/abenc_test.py ____________________________________
> schemes/test/abenc_test.py:1: in <module>
> >   from schemes.abenc.abenc_adapt_hybrid import HybridABEnc as HybridABEnc
> schemes/abenc/abenc_adapt_hybrid.py:6: in <module>
> >   from charm.toolbox.symcrypto import AuthenticatedCryptoAbstraction
> charm/toolbox/symcrypto.py:9: in <module>
> >   import hmac
> E   TypeError: __import__() argument 1 must be str without null bytes, not
> str
> 
> On Sat, Jun 16, 2012 at 12:30 PM, holger krekel <holger at merlinux.eu> wrote:
> 
> > On Sat, Jun 16, 2012 at 11:59 -0400, Ian Miers wrote:
> > > So these issues only happen on OSX and as I said,they come and go and
> > > change,which is why I am skeptical it's our code. Actually if I had to
> > > guess I'd say its something with python3 on OSX Lion, but so far we've
> > only
> > > seen the issues in test runs, not when attempting to manually recreate
> > the
> > > issue.
> > >
> > > Regarding import os.path error, I got it again. Trying to import the
> > module
> > > containing  that import after that error caused a bus error. However all
> > > subsequent imports worked fine. The strange thing is that the pyc file
> > > didn't change ( or at least its md5 sum didn't) and the modification date
> > > for all of the pyc files for that package remain unchanged.
> > >
> > >
> > >  python3.2 -m pytest --assert=plain seemed to work for a little bit, but
> > > then we started getting the same intermittent changing  errors.
> >
> > With --assert=plain pytest should not interfere with anything related
> > to importing.  Did you get the strange error with "import os.path"
> > in this configuration?   Are you using any plugins (see output of
> > py.test --version)?
> >
> > The below error may in principle be a doctest/pytest bug with
> > python3.2 although it would be strange if it only happened sometimes.
> >
> > Holger
> >
> > > Allmost all runs with assert=reinterp  , including after removing all
> > > __pychache__ and recompiling the c extensions  produce the INTERNALERROR
> > >  below.
> > >
> > >
> > >
> > > Thanks again,
> > > Ian
> > >
> > > python3.2 -m pytest --assert=reinterp
> > > ============================= test session starts
> > > ==============================
> > > platform darwin -- Python 3.2.3 -- pytest-2.2.4
> > > collected 232 items
> > >
> > > schemes/__init__.py .
> > > schemes/chamhash_adm05.py .
> > > schemes/chamhash_rsa_hw09.py .
> > > schemes/encap_bchk05.py .
> > > schemes/pk_fre_ccv11.py .
> > > schemes/pk_vrf.py .
> > > schemes/protocol_cns07.py .
> > > schemes/protocol_schnorr91.py .
> > > schemes/sigma1.py .
> > > schemes/sigma2.py .
> > > schemes/sigma3.py .
> > > schemes/abenc/__init__.py .
> > > schemes/abenc/abenc_adapt_hybrid.py F
> > > schemes/abenc/abenc_bsw07.py .
> > > schemes/abenc/abenc_lsw08.py .
> > > schemes/abenc/abenc_waters09.py .
> > > schemes/abenc/kpabenc_adapt_hybrid.py F
> > > schemes/commit/__init__.py .
> > > schemes/commit/commit_gs08.py .
> > > schemes/commit/commit_pedersen92.py .
> > > schemes/dabenc/__init__.py .
> > > schemes/dabenc/dabe_aw11.py
> > > INTERNALERROR> Traceback (most recent call last):
> > > INTERNALERROR>   File
> > >
> > "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/main.py",
> > > line 74, in wrap_session
> > > INTERNALERROR>     doit(config, session)
> > > INTERNALERROR>   File
> > >
> > "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/main.py",
> > > line 106, in _main
> > > INTERNALERROR>     config.hook.pytest_runtestloop(session=session)
> > > INTERNALERROR>   File
> > >
> > "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> > > line 421, in __call__
> > > INTERNALERROR>     return self._docall(methods, kwargs)
> > > INTERNALERROR>   File
> > >
> > "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> > > line 432, in _docall
> > > INTERNALERROR>     res = mc.execute()
> > > INTERNALERROR>   File
> > >
> > "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> > > line 350, in execute
> > > INTERNALERROR>     res = method(**kwargs)
> > > INTERNALERROR>   File
> > >
> > "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/main.py",
> > > line 119, in pytest_runtestloop
> > > INTERNALERROR>     item.config.hook.pytest_runtest_protocol(item=item,
> > > nextitem=nextitem)
> > > INTERNALERROR>   File
> > >
> > "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> > > line 421, in __call__
> > > INTERNALERROR>     return self._docall(methods, kwargs)
> > > INTERNALERROR>   File
> > >
> > "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> > > line 432, in _docall
> > > INTERNALERROR>     res = mc.execute()
> > > INTERNALERROR>   File
> > >
> > "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> > > line 350, in execute
> > > INTERNALERROR>     res = method(**kwargs)
> > > INTERNALERROR>   File
> > >
> > "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/runner.py",
> > > line 61, in pytest_runtest_protocol
> > > INTERNALERROR>     runtestprotocol(item, nextitem=nextitem)
> > > INTERNALERROR>   File
> > >
> > "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/runner.py",
> > > line 68, in runtestprotocol
> > > INTERNALERROR>     reports.append(call_and_report(item, "call", log))
> > > INTERNALERROR>   File
> > >
> > "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/runner.py",
> > > line 99, in call_and_report
> > > INTERNALERROR>     report = hook.pytest_runtest_makereport(item=item,
> > > call=call)
> > > INTERNALERROR>   File
> > >
> > "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/main.py",
> > > line 141, in call_matching_hooks
> > > INTERNALERROR>     return hookmethod.pcall(plugins, **kwargs)
> > > INTERNALERROR>   File
> > >
> > "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> > > line 425, in pcall
> > > INTERNALERROR>     return self._docall(methods, kwargs)
> > > INTERNALERROR>   File
> > >
> > "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> > > line 432, in _docall
> > > INTERNALERROR>     res = mc.execute()
> > > INTERNALERROR>   File
> > >
> > "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> > > line 350, in execute
> > > INTERNALERROR>     res = method(**kwargs)
> > > INTERNALERROR>   File
> > >
> > "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/capture.py",
> > > line 173, in pytest_runtest_makereport
> > > INTERNALERROR>     rep = __multicall__.execute()
> > > INTERNALERROR>   File
> > >
> > "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/core.py",
> > > line 350, in execute
> > > INTERNALERROR>     res = method(**kwargs)
> > > INTERNALERROR>   File
> > >
> > "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/runner.py",
> > > line 187, in pytest_runtest_makereport
> > > INTERNALERROR>     longrepr = item.repr_failure(excinfo)
> > > INTERNALERROR>   File
> > >
> > "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pytest-2.2.4-py3.2.egg/_pytest/doctest.py",
> > > line 44, in repr_failure
> > > INTERNALERROR>     lineno = test.lineno + example.lineno + 1
> > > INTERNALERROR> TypeError: unsupported operand type(s) for +: 'NoneType'
> > and
> > > 'int'
> > >
> > > ===================== 2 failed, 19 passed in 3.42 seconds
> > > ======================
> > >
> > >
> > >
> > >
> > > On Sat, Jun 16, 2012 at 4:19 AM, holger krekel <holger at merlinux.eu>
> > wrote:
> > >
> > > > Hi Ian,
> > > >
> > > > On Fri, Jun 15, 2012 at 20:32 -0400, Ian Miers wrote:
> > > > > Hi, I just started using pytest. It's lovely.
> > > > > The TLDR on this is we are getting intermittent non reproducible
> > errors
> > > > >  that change and sometimes disappear between test runs like the
> > > > following :
> > > > > >   import os.path
> > > > > E   TypeError: __import__() argument 1 must be str without null
> > bytes,
> > > > not
> > > > > str
> > > >
> > > > Looks odd.  pytest does not override __import__ but it does by default
> > > > use a PEP302 compliant module loader.  If you use
> > > >
> > > >    py.test --assert=reinterpret  # or --assert=plain
> > > >
> > > > do the errors go away?  If so that points to a problem in pytest's
> > module
> > > > loader or some interaction problem with python3.2.
> > > >
> > > > If changing the assertion mode still leads to errors then i strongly
> > > > suspect it's other parts of the code you are running.  I'd then suggest
> > > > to check if something in your environment modifies __import__
> > > > e.g. by writing a test that checks/prints out __import__?
> > > >
> > > > best,
> > > > holger
> > > >
> > > > > Longer version:
> > > > > We've been getting buggy results out of test runs on OSX Lion with
> > python
> > > > > 3.2.3  and  py.test version 2.2.4. Specifically we've been getting
> > what
> > > > > appear to be false-positive  test failures that change from run to
> > run
> > > >  and
> > > > > cannot be reproduced by running some code ourselves or in the case of
> > > > > doctest manually running  python3.2 -m doctest file.
> > > > >
> > > > > Some of these errors will stay around for multiple test runs even
> > after
> > > > > make clean, etc. Some will change from run to run. All of them
> > > > > eventually disappeared  temporarily and we got a clean test pass,
> > though
> > > > > how I don't know. Morever, the problems cropped up again. All of
> > this was
> > > > > with no code changes and code known to work on ubuntu and partially
> > > > > manually tested on OSX.
> > > > >
> > > > > Ordinarly I'd say there was something wrong with our code. However,
> > some
> > > > of
> > > > > the errors are vanishingly unlikely. Claims that modules don't exist
> > when
> > > > > they do and are importable via python3.2 -c "from foo.bar.baz import
> > > > narf"
> > > > > and such.
> > > > >
> > > > > The most glaringly, however, is this gem:
> > > > > charm/toolbox/pairinggroup.py:3: in <module>
> > > > > >   import os.path
> > > > > E   TypeError: __import__() argument 1 must be str without null
> > bytes,
> > > > not
> > > > > str
> > > > >
> > > > > We also got a lovely bug where it appeared __pycache__  was corrupted
> > > > > during test runs.  On an initial run, we could import a function
> > from a
> > > > > python c extension. On subsequent runs, it didn't exist. The
> > function was
> > > > > still in the .so file, as shown by nm, however help(module) returned
> > > > > function_name#$@^%#$% Function description. Deleting __pychache__
> > folders
> > > > >  resolved it for the next test run but then it came back. It too
> > > > > disappeared after a couple of test runs never to be seen since.
> > > > >
> > > > > Has anyone seen anyhting like this? Are their known issues on OSX
> > with
> > > > > python ? With pytest? Does anyone have any idea how I might get a
> > better
> > > > > idea whats going on?
> > > > >
> > > > > As an addendum, the latest error I am getting is now :
> > > > > >   test = [hashFn(struct.pack(">%dsI" % (len(seed)), seed, i)) for
> > i in
> > > > > ran]
> > > > > E   UnicodeEncodeError: 'ascii' codec can't encode character '\x9e'
> > in
> > > > > position 0: ordinal not in range(128
> > > > > This actually might be in our code,though again it works on ubuntu
> > and at
> > > > > one point on OSX.  Given that its a pattern that points to python or
> > > > pytest
> > > > > doing something  to binaries,  I'm including it anyway.
> > > > >
> > > > > The project is charm, you can see the code on this branch here via
> > > > > https://github.com/JHUISI/charm/tree/dev. Python was installed via
> > fenc
> > > > ( I
> > > > > think, its not my box). The errors happened both with python3.2 -m
> > pytest
> > > > >  and with python3.2 setup.py test.  Though it appears more so with
> > the
> > > > > later.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Ian
> > > >
> > > > > _______________________________________________
> > > > > py-dev mailing list
> > > > > py-dev at codespeak.net
> > > > > http://codespeak.net/mailman/listinfo/py-dev
> > > >
> > > >
> >


From holger at merlinux.eu  Wed Jun 20 22:52:01 2012
From: holger at merlinux.eu (holger krekel)
Date: Wed, 20 Jun 2012 20:52:01 +0000
Subject: [py-dev] new cache and pep8 pytest plugin releases
Message-ID: <20120620205201.GL11942@merlinux.eu>


i just released two new plugins:

* pytest-cache-0.9 (initial) for easy caching of values across test runs 
  and a new --lf option to rerun the failing tests of a previous run. Install,
  basic example and API (for use by other plugins) is here:

  http://packages.python.org/pytest-cache/readme.html

* pytest-pep8-1.0 a flexible pep8 checker which allows to keep your project
  PEP8 compliant with your choice of ignore-options on a per-file basis.
  It avoids checking files that haven't changed.  Examples and docs at:
  
  http://pypi.python.org/pypi/pytest-pep8

have fun,
holger


From flub at devork.be  Thu Jun 21 00:31:42 2012
From: flub at devork.be (Floris Bruynooghe)
Date: Wed, 20 Jun 2012 23:31:42 +0100
Subject: [py-dev] pytest-timeout 0.2
In-Reply-To: <CAAWk_Dw2XTQK8P7vDEFK7xRkWsZiNm1dT1Pp2OCZEPAsFaQBrg@mail.gmail.com>
References: <CAAWk_DwoODtnt7XwfS5ngHzsw9bXscbApL+oPArs=4_gDbiR+A@mail.gmail.com>
	<20120317231627.GT26028@merlinux.eu>
	<CAAWk_Dy3E=eee9qXv5P5qfOyVCF5KbyM3JAfVcTbqU=zP8UuhQ@mail.gmail.com>
	<05BB196AB3DA6C4BBE11AB6C957581FE445528E2@sfo-exch-01.dolby.net>
	<CAAWk_Dw2XTQK8P7vDEFK7xRkWsZiNm1dT1Pp2OCZEPAsFaQBrg@mail.gmail.com>
Message-ID: <CAAWk_DzGmKHANCnyj4RrnO_1m0xoYn4XF8uioEJa6=PWapPg2A@mail.gmail.com>

On 19 March 2012 22:20, Floris Bruynooghe <flub at devork.be> wrote:
> On 19 March 2012 16:38, Brack, Laurent P. <lpbrac at dolby.com> wrote:
>> It would also be nice to have a consistent behavior between sigalarm on/off. For instance, on Windows, pytest exits on first hang as opposed to *nix where the test is pre-empted and pytest moves on to the next one.
>
> I was writing up a response saying I didn't know how to do so, but
> while doing so I thought it might be possible to emulate sigalrm with
> a timer thread which fires an other signal. ?I might investigate the
> feasibility of such an approach.

I (finally) had a look at this and don't think it's worth pursuing
mostly because windows doesn't have any user-usable signals to do
this.  And the benefit on UNIX just doesn't seem that big to me.  I
think integration with xdist would be a better approach to tackle
this.

Regards,
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org


From flub at devork.be  Thu Jun 21 01:16:52 2012
From: flub at devork.be (Floris Bruynooghe)
Date: Thu, 21 Jun 2012 00:16:52 +0100
Subject: [py-dev] Storing terminal width in py.test config object
Message-ID: <CAAWk_Dx=CMKLh7q9X9CwzU2trDxSaf5SXwCNNDV84HvS4o32Pw@mail.gmail.com>

Hi,

An annoyance of the pytest_assertrepr_compare hook is that it can not
normally access the terminal width since usually it is called while
stdout and stderr are being captured which breaks
py.io.get_terminal_width().  Since I think it is fairly rare to get a
changing terminal size during a py.test run I would propose py.test
stores the terminal width on it's config object which would solve that
annoyance.

Would this be a reasonable thing to do?

Regards,
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org


From holger at merlinux.eu  Thu Jun 21 08:16:48 2012
From: holger at merlinux.eu (holger krekel)
Date: Thu, 21 Jun 2012 06:16:48 +0000
Subject: [py-dev] Storing terminal width in py.test config object
In-Reply-To: <CAAWk_Dx=CMKLh7q9X9CwzU2trDxSaf5SXwCNNDV84HvS4o32Pw@mail.gmail.com>
References: <CAAWk_Dx=CMKLh7q9X9CwzU2trDxSaf5SXwCNNDV84HvS4o32Pw@mail.gmail.com>
Message-ID: <20120621061648.GM11942@merlinux.eu>

On Thu, Jun 21, 2012 at 00:16 +0100, Floris Bruynooghe wrote:
> An annoyance of the pytest_assertrepr_compare hook is that it can not
> normally access the terminal width since usually it is called while
> stdout and stderr are being captured which breaks
> py.io.get_terminal_width().  Since I think it is fairly rare to get a
> changing terminal size during a py.test run I would propose py.test
> stores the terminal width on it's config object which would solve that
> annoyance.
> 
> Would this be a reasonable thing to do?

I think so.  However, I'd like to have this working with xdist as well
and slaves generally do not have access to the master terminal.
I guess xdist could take care to explicitely transfer terminal_width
once it is on the config object. You can leave the latter to me if you prefer.

best,

holger


> Regards,
> Floris
> 
> -- 
> Debian GNU/Linux -- The Power of Freedom
> www.debian.org | www.gnu.org | www.kernel.org
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 


From holger at merlinux.eu  Thu Jun 21 10:32:44 2012
From: holger at merlinux.eu (holger krekel)
Date: Thu, 21 Jun 2012 08:32:44 +0000
Subject: [py-dev] new cache and pep8 pytest plugin releases
In-Reply-To: <20120620205201.GL11942@merlinux.eu>
References: <20120620205201.GL11942@merlinux.eu>
Message-ID: <20120621083244.GP11942@merlinux.eu>


I quickly released a pytest-pep8-1.0.1 which includes an explicit dependency on
pytest-cache.  Thanks to Hynek Schlawack for reporting.

On Wed, Jun 20, 2012 at 20:52 +0000, holger krekel wrote:
> i just released two new plugins:
> 
> * pytest-cache-0.9 (initial) for easy caching of values across test runs 
>   and a new --lf option to rerun the failing tests of a previous run. Install,
>   basic example and API (for use by other plugins) is here:
> 
>   http://packages.python.org/pytest-cache/readme.html
> 
> * pytest-pep8-1.0 a flexible pep8 checker which allows to keep your project
>   PEP8 compliant with your choice of ignore-options on a per-file basis.
>   It avoids checking files that haven't changed.  Examples and docs at:
>   
>   http://pypi.python.org/pypi/pytest-pep8
> 
> have fun,
> holger
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 


From flub at devork.be  Mon Jun 25 11:55:53 2012
From: flub at devork.be (Floris Bruynooghe)
Date: Mon, 25 Jun 2012 10:55:53 +0100
Subject: [py-dev] Resource providers
Message-ID: <CAAWk_Dzzp0TPsgJAT5gXna1KtxUGYZNbEokD5ZWrObbtKw+3LA@mail.gmail.com>

Hi Holger, everyone,

Yesterday a resource provider API was considered on IRC, unfortunately
I have no logs and forgot the details already.  But today I remembered
a, possibly invalid, use case which might want to benefit form this:
occasionally I wish it was possible to dynamically create funcarg
objects.

The concrete example I have now is that it could be nice in
pytest-django to be able to request e.g. "Users" which is a model
class used to access the User table in the database.  Currently this
is only possible by someone explicitly defining pytest_funcarg__Users,
but Django allows you to dynamically look up all the models in the
database so there is no reason this can't be build automatically.

I think this is what the API you proposed was for, but as I said I
can't remember the details.  And in this case I might be less
enthusiastic in postponing it's implementation to a later release ;-)

Regards,
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org


From flub at devork.be  Mon Jun 25 12:06:07 2012
From: flub at devork.be (Floris Bruynooghe)
Date: Mon, 25 Jun 2012 11:06:07 +0100
Subject: [py-dev] Storing terminal width in py.test config object
In-Reply-To: <20120621061648.GM11942@merlinux.eu>
References: <CAAWk_Dx=CMKLh7q9X9CwzU2trDxSaf5SXwCNNDV84HvS4o32Pw@mail.gmail.com>
	<20120621061648.GM11942@merlinux.eu>
Message-ID: <CAAWk_Dx84uCHNLME_ZDWRiRqxvmmi8JyQMsE2Ug0v5H-H_ZSQQ@mail.gmail.com>

On 21 June 2012 07:16, holger krekel <holger at merlinux.eu> wrote:
> On Thu, Jun 21, 2012 at 00:16 +0100, Floris Bruynooghe wrote:
>> An annoyance of the pytest_assertrepr_compare hook is that it can not
>> normally access the terminal width since usually it is called while
>> stdout and stderr are being captured which breaks
>> py.io.get_terminal_width(). ?Since I think it is fairly rare to get a
>> changing terminal size during a py.test run I would propose py.test
>> stores the terminal width on it's config object which would solve that
>> annoyance.
>>
>> Would this be a reasonable thing to do?
>
> I think so. ?However, I'd like to have this working with xdist as well
> and slaves generally do not have access to the master terminal.
> I guess xdist could take care to explicitely transfer terminal_width
> once it is on the config object. You can leave the latter to me if you prefer.

Ok, as I'm in no hurry on this I've created an issue for this so I
don't completely loose track.  I don't mind attempting to look at
xdist when I get round to it, I probably need to get to know it for my
pytest-timeout plugin anyway.

Regards,
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org


From holger at merlinux.eu  Mon Jun 25 15:29:36 2012
From: holger at merlinux.eu (holger krekel)
Date: Mon, 25 Jun 2012 13:29:36 +0000
Subject: [py-dev] Resource providers
In-Reply-To: <CAAWk_Dzzp0TPsgJAT5gXna1KtxUGYZNbEokD5ZWrObbtKw+3LA@mail.gmail.com>
References: <CAAWk_Dzzp0TPsgJAT5gXna1KtxUGYZNbEokD5ZWrObbtKw+3LA@mail.gmail.com>
Message-ID: <20120625132936.GV11942@merlinux.eu>

Hi Floris,

On Mon, Jun 25, 2012 at 10:55 +0100, Floris Bruynooghe wrote:
> Hi Holger, everyone,
> 
> Yesterday a resource provider API was considered on IRC, unfortunately
> I have no logs and forgot the details already.  But today I remembered
> a, possibly invalid, use case which might want to benefit form this:
> occasionally I wish it was possible to dynamically create funcarg
> objects.
> 
> The concrete example I have now is that it could be nice in
> pytest-django to be able to request e.g. "Users" which is a model
> class used to access the User table in the database.  Currently this
> is only possible by someone explicitly defining pytest_funcarg__Users,
> but Django allows you to dynamically look up all the models in the
> database so there is no reason this can't be build automatically.
> 
> I think this is what the API you proposed was for, but as I said I
> can't remember the details.  And in this case I might be less
> enthusiastic in postponing it's implementation to a later release ;-)

It's probably true that we could invent an register-factory API for this.

However, what about a single "models" object (done traditionally
with a pytest_funcarg__models definition) which itself provides
an API to give "Users" or others data?

best,
holger

> Regards,
> Floris
> 
> -- 
> Debian GNU/Linux -- The Power of Freedom
> www.debian.org | www.gnu.org | www.kernel.org
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 


From holger at merlinux.eu  Mon Jun 25 15:54:04 2012
From: holger at merlinux.eu (holger krekel)
Date: Mon, 25 Jun 2012 13:54:04 +0000
Subject: [py-dev] Storing terminal width in py.test config object
In-Reply-To: <CAAWk_Dx84uCHNLME_ZDWRiRqxvmmi8JyQMsE2Ug0v5H-H_ZSQQ@mail.gmail.com>
References: <CAAWk_Dx=CMKLh7q9X9CwzU2trDxSaf5SXwCNNDV84HvS4o32Pw@mail.gmail.com>
	<20120621061648.GM11942@merlinux.eu>
	<CAAWk_Dx84uCHNLME_ZDWRiRqxvmmi8JyQMsE2Ug0v5H-H_ZSQQ@mail.gmail.com>
Message-ID: <20120625135404.GW11942@merlinux.eu>

On Mon, Jun 25, 2012 at 11:06 +0100, Floris Bruynooghe wrote:
> On 21 June 2012 07:16, holger krekel <holger at merlinux.eu> wrote:
> > On Thu, Jun 21, 2012 at 00:16 +0100, Floris Bruynooghe wrote:
> >> An annoyance of the pytest_assertrepr_compare hook is that it can not
> >> normally access the terminal width since usually it is called while
> >> stdout and stderr are being captured which breaks
> >> py.io.get_terminal_width(). ?Since I think it is fairly rare to get a
> >> changing terminal size during a py.test run I would propose py.test
> >> stores the terminal width on it's config object which would solve that
> >> annoyance.
> >>
> >> Would this be a reasonable thing to do?
> >
> > I think so. ?However, I'd like to have this working with xdist as well
> > and slaves generally do not have access to the master terminal.
> > I guess xdist could take care to explicitely transfer terminal_width
> > once it is on the config object. You can leave the latter to me if you prefer.
> 
> Ok, as I'm in no hurry on this I've created an issue for this so I
> don't completely loose track.  I don't mind attempting to look at
> xdist when I get round to it, I probably need to get to know it for my
> pytest-timeout plugin anyway.

There is a semi-official way to pass data between master and slaves,
see this test:

    https://bitbucket.org/hpk42/pytest-xdist/src/6d23d5c1326f/testing/acceptance_test.py#cl-159

With this, you could define the appropriate code in the xdist-plugin
(or in any other plugin) to make config.terminal_width available 
on slaves.  I guess that pytest itself should grow a config.terminal_width
and xdist would just take care to transfer it.

Actually, it would be interesting to make a virtual py.io.TerminalWriter()
available which uses the settings from the master terminalwriter (as
used in the terminal plugin). It could be used to produce colored
output on the slaves to be shown on the master terminal.  I am hesitant
to point you to py.io.TerminalWritter, however, because its code is in
need for a cleanup and a unicode-review ... but maybe this is unrelated.

best,
holger


From Ronny.Pfannschmidt at gmx.de  Mon Jun 25 16:09:23 2012
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Mon, 25 Jun 2012 16:09:23 +0200
Subject: [py-dev] Storing terminal width in py.test config object
In-Reply-To: <20120625135404.GW11942@merlinux.eu>
References: <CAAWk_Dx=CMKLh7q9X9CwzU2trDxSaf5SXwCNNDV84HvS4o32Pw@mail.gmail.com>
	<20120621061648.GM11942@merlinux.eu>
	<CAAWk_Dx84uCHNLME_ZDWRiRqxvmmi8JyQMsE2Ug0v5H-H_ZSQQ@mail.gmail.com>
	<20120625135404.GW11942@merlinux.eu>
Message-ID: <4FE87113.2070709@gmx.de>

given the nature of the problem,
i think its wrong to go for terminal width there,
instead we should serialize the exponations,
and render them on the master.

that way we could also have other ways of display more nicely.

On 06/25/2012 03:54 PM, holger krekel wrote:
> On Mon, Jun 25, 2012 at 11:06 +0100, Floris Bruynooghe wrote:
>> On 21 June 2012 07:16, holger krekel<holger at merlinux.eu>  wrote:
>>> On Thu, Jun 21, 2012 at 00:16 +0100, Floris Bruynooghe wrote:
>>>> An annoyance of the pytest_assertrepr_compare hook is that it can not
>>>> normally access the terminal width since usually it is called while
>>>> stdout and stderr are being captured which breaks
>>>> py.io.get_terminal_width().  Since I think it is fairly rare to get a
>>>> changing terminal size during a py.test run I would propose py.test
>>>> stores the terminal width on it's config object which would solve that
>>>> annoyance.
>>>>
>>>> Would this be a reasonable thing to do?
>>>
>>> I think so.  However, I'd like to have this working with xdist as well
>>> and slaves generally do not have access to the master terminal.
>>> I guess xdist could take care to explicitely transfer terminal_width
>>> once it is on the config object. You can leave the latter to me if you prefer.
>>
>> Ok, as I'm in no hurry on this I've created an issue for this so I
>> don't completely loose track.  I don't mind attempting to look at
>> xdist when I get round to it, I probably need to get to know it for my
>> pytest-timeout plugin anyway.
>
> There is a semi-official way to pass data between master and slaves,
> see this test:
>
>      https://bitbucket.org/hpk42/pytest-xdist/src/6d23d5c1326f/testing/acceptance_test.py#cl-159
>
> With this, you could define the appropriate code in the xdist-plugin
> (or in any other plugin) to make config.terminal_width available
> on slaves.  I guess that pytest itself should grow a config.terminal_width
> and xdist would just take care to transfer it.
>
> Actually, it would be interesting to make a virtual py.io.TerminalWriter()
> available which uses the settings from the master terminalwriter (as
> used in the terminal plugin). It could be used to produce colored
> output on the slaves to be shown on the master terminal.  I am hesitant
> to point you to py.io.TerminalWritter, however, because its code is in
> need for a cleanup and a unicode-review ... but maybe this is unrelated.
>
> best,
> holger
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev



From flub at devork.be  Mon Jun 25 16:21:42 2012
From: flub at devork.be (Floris Bruynooghe)
Date: Mon, 25 Jun 2012 15:21:42 +0100
Subject: [py-dev] Resource providers
In-Reply-To: <20120625132936.GV11942@merlinux.eu>
References: <CAAWk_Dzzp0TPsgJAT5gXna1KtxUGYZNbEokD5ZWrObbtKw+3LA@mail.gmail.com>
	<20120625132936.GV11942@merlinux.eu>
Message-ID: <CAAWk_DzSqd8LyDmieoc_uSrRLDJRwoE7h-C5bEGnAZG0b4Ks6w@mail.gmail.com>

On 25 June 2012 14:29, holger krekel <holger at merlinux.eu> wrote:
> On Mon, Jun 25, 2012 at 10:55 +0100, Floris Bruynooghe wrote:
>> The concrete example I have now is that it could be nice in
>> pytest-django to be able to request e.g. "Users" which is a model
>> class used to access the User table in the database. ?Currently this
>> is only possible by someone explicitly defining pytest_funcarg__Users,
>> but Django allows you to dynamically look up all the models in the
>> database so there is no reason this can't be build automatically.
>>
>> I think this is what the API you proposed was for, but as I said I
>> can't remember the details. ?And in this case I might be less
>> enthusiastic in postponing it's implementation to a later release ;-)
>
> It's probably true that we could invent an register-factory API for this.
>
> However, what about a single "models" object (done traditionally
> with a pytest_funcarg__models definition) which itself provides
> an API to give "Users" or others data?

Yes of course, that is what I currently have in my conftest.py.  But
it would still be a nice thing to be able to do and a nice example of
functionality I have wished I had before.  Hence I was wondering if
the API you talked about yesterday would support it.


Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org


From holger at merlinux.eu  Mon Jun 25 16:36:00 2012
From: holger at merlinux.eu (holger krekel)
Date: Mon, 25 Jun 2012 14:36:00 +0000
Subject: [py-dev] Storing terminal width in py.test config object
In-Reply-To: <4FE87113.2070709@gmx.de>
References: <CAAWk_Dx=CMKLh7q9X9CwzU2trDxSaf5SXwCNNDV84HvS4o32Pw@mail.gmail.com>
	<20120621061648.GM11942@merlinux.eu>
	<CAAWk_Dx84uCHNLME_ZDWRiRqxvmmi8JyQMsE2Ug0v5H-H_ZSQQ@mail.gmail.com>
	<20120625135404.GW11942@merlinux.eu> <4FE87113.2070709@gmx.de>
Message-ID: <20120625143600.GZ11942@merlinux.eu>

On Mon, Jun 25, 2012 at 16:09 +0200, Ronny Pfannschmidt wrote:
> given the nature of the problem,
> i think its wrong to go for terminal width there,
> instead we should serialize the exponations,
> and render them on the master.
> 
> that way we could also have other ways of display more nicely.

It's indeed true that a frontend-independent format that can be
rendered on the master would be nice ... um, html? (not sure it's a joke).

holger


> On 06/25/2012 03:54 PM, holger krekel wrote:
> >On Mon, Jun 25, 2012 at 11:06 +0100, Floris Bruynooghe wrote:
> >>On 21 June 2012 07:16, holger krekel<holger at merlinux.eu>  wrote:
> >>>On Thu, Jun 21, 2012 at 00:16 +0100, Floris Bruynooghe wrote:
> >>>>An annoyance of the pytest_assertrepr_compare hook is that it can not
> >>>>normally access the terminal width since usually it is called while
> >>>>stdout and stderr are being captured which breaks
> >>>>py.io.get_terminal_width().  Since I think it is fairly rare to get a
> >>>>changing terminal size during a py.test run I would propose py.test
> >>>>stores the terminal width on it's config object which would solve that
> >>>>annoyance.
> >>>>
> >>>>Would this be a reasonable thing to do?
> >>>
> >>>I think so.  However, I'd like to have this working with xdist as well
> >>>and slaves generally do not have access to the master terminal.
> >>>I guess xdist could take care to explicitely transfer terminal_width
> >>>once it is on the config object. You can leave the latter to me if you prefer.
> >>
> >>Ok, as I'm in no hurry on this I've created an issue for this so I
> >>don't completely loose track.  I don't mind attempting to look at
> >>xdist when I get round to it, I probably need to get to know it for my
> >>pytest-timeout plugin anyway.
> >
> >There is a semi-official way to pass data between master and slaves,
> >see this test:
> >
> >     https://bitbucket.org/hpk42/pytest-xdist/src/6d23d5c1326f/testing/acceptance_test.py#cl-159
> >
> >With this, you could define the appropriate code in the xdist-plugin
> >(or in any other plugin) to make config.terminal_width available
> >on slaves.  I guess that pytest itself should grow a config.terminal_width
> >and xdist would just take care to transfer it.
> >
> >Actually, it would be interesting to make a virtual py.io.TerminalWriter()
> >available which uses the settings from the master terminalwriter (as
> >used in the terminal plugin). It could be used to produce colored
> >output on the slaves to be shown on the master terminal.  I am hesitant
> >to point you to py.io.TerminalWritter, however, because its code is in
> >need for a cleanup and a unicode-review ... but maybe this is unrelated.
> >
> >best,
> >holger
> >_______________________________________________
> >py-dev mailing list
> >py-dev at codespeak.net
> >http://codespeak.net/mailman/listinfo/py-dev
> 


From holger at merlinux.eu  Mon Jun 25 17:23:51 2012
From: holger at merlinux.eu (holger krekel)
Date: Mon, 25 Jun 2012 15:23:51 +0000
Subject: [py-dev] Resource providers
In-Reply-To: <CAAWk_DzSqd8LyDmieoc_uSrRLDJRwoE7h-C5bEGnAZG0b4Ks6w@mail.gmail.com>
References: <CAAWk_Dzzp0TPsgJAT5gXna1KtxUGYZNbEokD5ZWrObbtKw+3LA@mail.gmail.com>
	<20120625132936.GV11942@merlinux.eu>
	<CAAWk_DzSqd8LyDmieoc_uSrRLDJRwoE7h-C5bEGnAZG0b4Ks6w@mail.gmail.com>
Message-ID: <20120625152351.GA11942@merlinux.eu>

On Mon, Jun 25, 2012 at 15:21 +0100, Floris Bruynooghe wrote:
> On 25 June 2012 14:29, holger krekel <holger at merlinux.eu> wrote:
> > On Mon, Jun 25, 2012 at 10:55 +0100, Floris Bruynooghe wrote:
> >> The concrete example I have now is that it could be nice in
> >> pytest-django to be able to request e.g. "Users" which is a model
> >> class used to access the User table in the database. ?Currently this
> >> is only possible by someone explicitly defining pytest_funcarg__Users,
> >> but Django allows you to dynamically look up all the models in the
> >> database so there is no reason this can't be build automatically.
> >>
> >> I think this is what the API you proposed was for, but as I said I
> >> can't remember the details. ?And in this case I might be less
> >> enthusiastic in postponing it's implementation to a later release ;-)
> >
> > It's probably true that we could invent an register-factory API for this.
> >
> > However, what about a single "models" object (done traditionally
> > with a pytest_funcarg__models definition) which itself provides
> > an API to give "Users" or others data?
> 
> Yes of course, that is what I currently have in my conftest.py.  But
> it would still be a nice thing to be able to do and a nice example of
> functionality I have wished I had before.  Hence I was wondering if
> the API you talked about yesterday would support it.

I guess it could, for example, look like this::

    def pytest_configure(config):  # [1]
        def createmodel(name, node):
            """ return django model object. """
            # node can be None, Directory, Module, Class, Item, etc.
            # (code to compute model)
            return model

        for name in modelnames:
            config.register_factory(name, createmodel)

Getting a resource would work like this::
    
    config.getresource(name)

The "--funcargs" option would (remain) able to show the docstring
and location of the createmodel function.

Another interesting bit is how to use register_factory
to connect the existing "pytest_funcarg__..." factories
which have a certain scope.  I guess something like this::

    config.register_factory(name, factoryfunc, node)

would suffice - it would restrict the scope of the factory
function to the specified node and all of its descendents.
It could be called from Directory, Module, Class's setup methods
to register the respective "pytest_funcarg__" functions scoped as
per-directory (conftest.py), per-module or per-class factories.

Note that the "node" passed to the createmodel factory function
above is probably neccessary for this case because existing
funcarg-factories operate on Items (or in the future Nodes).

getfuncargvalue() would then be implemented in terms of a
call to config.getresource(name, node).

In general, register_factory needs to be callable multiple
times with the same name.  accept multiple factories for
the same resource will One little issues is that we want to 

This new resource registration/lookup could work much
more efficiently than the current scheme which - upon every getfuncargvalue() -
iterates over all plugins, modules and classes to discover matching 
pytest_funcarg__ factories.

hope this all makes some sense.

best,
holger


[1] We really need a new hook like pytest_runtest_init() which
    is called once before the runtest loop actually starts it work.
    pytest_configure() usually works but it is also called on the
    xdist-master process for which setting up resources makes no sense.

> Floris
> 
> -- 
> Debian GNU/Linux -- The Power of Freedom
> www.debian.org | www.gnu.org | www.kernel.org
> 


From flub at devork.be  Mon Jun 25 19:11:05 2012
From: flub at devork.be (Floris Bruynooghe)
Date: Mon, 25 Jun 2012 18:11:05 +0100
Subject: [py-dev] Storing terminal width in py.test config object
In-Reply-To: <20120625143600.GZ11942@merlinux.eu>
References: <CAAWk_Dx=CMKLh7q9X9CwzU2trDxSaf5SXwCNNDV84HvS4o32Pw@mail.gmail.com>
	<20120621061648.GM11942@merlinux.eu>
	<CAAWk_Dx84uCHNLME_ZDWRiRqxvmmi8JyQMsE2Ug0v5H-H_ZSQQ@mail.gmail.com>
	<20120625135404.GW11942@merlinux.eu> <4FE87113.2070709@gmx.de>
	<20120625143600.GZ11942@merlinux.eu>
Message-ID: <CAAWk_Dx+NbKS=ukfsi4ca7UOZFXMSK=9on=zjCzCmOqc4+LTfA@mail.gmail.com>

On 25 June 2012 15:36, holger krekel <holger at merlinux.eu> wrote:
> On Mon, Jun 25, 2012 at 16:09 +0200, Ronny Pfannschmidt wrote:
>> given the nature of the problem,
>> i think its wrong to go for terminal width there,
>> instead we should serialize the exponations,
>> and render them on the master.
>>
>> that way we could also have other ways of display more nicely.
>
> It's indeed true that a frontend-independent format that can be
> rendered on the master would be nice ... um, html? (not sure it's a joke).

Not sure that would cover all situations, py.io.saferepr() would
somehow have to serialise the full thing (which might be simply too
much data) and the other side would have to then notice this and
somehow figure out the right argument for the maxsize argument of
saferepr.  I'm sure there's a way of encoding all that but that but
it's a lot of complexity and still won't solve the too much serialised
data problem.


Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org


From holger at merlinux.eu  Tue Jun 26 09:43:58 2012
From: holger at merlinux.eu (holger krekel)
Date: Tue, 26 Jun 2012 07:43:58 +0000
Subject: [py-dev] Storing terminal width in py.test config object
In-Reply-To: <CAAWk_Dx+NbKS=ukfsi4ca7UOZFXMSK=9on=zjCzCmOqc4+LTfA@mail.gmail.com>
References: <CAAWk_Dx=CMKLh7q9X9CwzU2trDxSaf5SXwCNNDV84HvS4o32Pw@mail.gmail.com>
	<20120621061648.GM11942@merlinux.eu>
	<CAAWk_Dx84uCHNLME_ZDWRiRqxvmmi8JyQMsE2Ug0v5H-H_ZSQQ@mail.gmail.com>
	<20120625135404.GW11942@merlinux.eu> <4FE87113.2070709@gmx.de>
	<20120625143600.GZ11942@merlinux.eu>
	<CAAWk_Dx+NbKS=ukfsi4ca7UOZFXMSK=9on=zjCzCmOqc4+LTfA@mail.gmail.com>
Message-ID: <20120626074358.GD11942@merlinux.eu>

On Mon, Jun 25, 2012 at 18:11 +0100, Floris Bruynooghe wrote:
> On 25 June 2012 15:36, holger krekel <holger at merlinux.eu> wrote:
> > On Mon, Jun 25, 2012 at 16:09 +0200, Ronny Pfannschmidt wrote:
> >> given the nature of the problem,
> >> i think its wrong to go for terminal width there,
> >> instead we should serialize the exponations,
> >> and render them on the master.
> >>
> >> that way we could also have other ways of display more nicely.
> >
> > It's indeed true that a frontend-independent format that can be
> > rendered on the master would be nice ... um, html? (not sure it's a joke).
> 
> Not sure that would cover all situations, py.io.saferepr() would
> somehow have to serialise the full thing (which might be simply too
> much data) and the other side would have to then notice this and
> somehow figure out the right argument for the maxsize argument of
> saferepr.  I'm sure there's a way of encoding all that but that but
> it's a lot of complexity and still won't solve the too much serialised
> data problem.

What about a "reportsettings" object with all neccessary settings
(including maxsize, tb-represenation defaults, ...) which slaves use to
parametrize their reporting?  We should then also allow reading
reportsettings from the ini-file and let cmdline options override them.

Particulary with respect to coloring/bold effects, i'd still want a
more abstract representation of output than plain (ansi-colored)
strings, i think.  It should allow to easily produce html-output or to adapt
to windows/unix terminal coloring styles.  This is some effort to get right
but it can at least be tested separately.

In general, i'd target the following goals with such a refactoring:

* a new --htmlreport option to produce html-output (maybe with a little
  javascript to fold/unfold tracebacks etc.)

* colored,linewidth adapted terminal output for xdist on all platforms

* much less network/cpu usage for long failure reps if --tb=native/no
  is supplied

Additionally, if we manage to get most of this functionality into pylib,
detox might also make use of it as it aims to support cross-host distributed
testing on a different level.

best,
holger


From flub at devork.be  Tue Jun 26 16:07:09 2012
From: flub at devork.be (Floris Bruynooghe)
Date: Tue, 26 Jun 2012 15:07:09 +0100
Subject: [py-dev] Resource providers
In-Reply-To: <20120625152351.GA11942@merlinux.eu>
References: <CAAWk_Dzzp0TPsgJAT5gXna1KtxUGYZNbEokD5ZWrObbtKw+3LA@mail.gmail.com>
	<20120625132936.GV11942@merlinux.eu>
	<CAAWk_DzSqd8LyDmieoc_uSrRLDJRwoE7h-C5bEGnAZG0b4Ks6w@mail.gmail.com>
	<20120625152351.GA11942@merlinux.eu>
Message-ID: <CAAWk_DyOeY8XnMOi22typyL6t1pdvdpbzWKvbFHF-4fWSRYN=A@mail.gmail.com>

On 25 June 2012 16:23, holger krekel <holger at merlinux.eu> wrote:
> On Mon, Jun 25, 2012 at 15:21 +0100, Floris Bruynooghe wrote:
>> On 25 June 2012 14:29, holger krekel <holger at merlinux.eu> wrote:
>> > On Mon, Jun 25, 2012 at 10:55 +0100, Floris Bruynooghe wrote:
>> >> The concrete example I have now is that it could be nice in
>> >> pytest-django to be able to request e.g. "Users" which is a model
>> >> class used to access the User table in the database. ?Currently this
>> >> is only possible by someone explicitly defining pytest_funcarg__Users,
>> >> but Django allows you to dynamically look up all the models in the
>> >> database so there is no reason this can't be build automatically.
>> >>
>> >> I think this is what the API you proposed was for, but as I said I
>> >> can't remember the details. ?And in this case I might be less
>> >> enthusiastic in postponing it's implementation to a later release ;-)
>> >
>> > It's probably true that we could invent an register-factory API for this.
>> >
>> > However, what about a single "models" object (done traditionally
>> > with a pytest_funcarg__models definition) which itself provides
>> > an API to give "Users" or others data?
>>
>> Yes of course, that is what I currently have in my conftest.py. ?But
>> it would still be a nice thing to be able to do and a nice example of
>> functionality I have wished I had before. ?Hence I was wondering if
>> the API you talked about yesterday would support it.
>
> I guess it could, for example, look like this::
>
> ? ?def pytest_configure(config): ?# [1]
> ? ? ? ?def createmodel(name, node):
> ? ? ? ? ? ?""" return django model object. """
> ? ? ? ? ? ?# node can be None, Directory, Module, Class, Item, etc.
> ? ? ? ? ? ?# (code to compute model)
> ? ? ? ? ? ?return model
>
> ? ? ? ?for name in modelnames:
> ? ? ? ? ? ?config.register_factory(name, createmodel)

I think for addressing this specific usecase I was more imagining a
standard pytest hook:

   def pytest_resource_factory(name, item):
       """The docstring which can show up in --funcargs"""
       if name == 'User':
           return models.User

That way it can be scoped per-directory in the conftest.py files and
used in plugins, which would be scoped globally.

I appreciate that this does not provide the other benefits nor can it
be used to implement funcargs themself.  So maybe there is a need for
an API you just describe which would allow one to implement what I
just described in a plugin as well as write the funcargs as a plugin.
But I'm much less comfortable suggesting what that API should be like,
I do not fully know the innards of py.test like you do.


Hope this makes sense,
Floris


From flub at devork.be  Tue Jun 26 16:13:55 2012
From: flub at devork.be (Floris Bruynooghe)
Date: Tue, 26 Jun 2012 15:13:55 +0100
Subject: [py-dev] Resource providers
In-Reply-To: <20120625152351.GA11942@merlinux.eu>
References: <CAAWk_Dzzp0TPsgJAT5gXna1KtxUGYZNbEokD5ZWrObbtKw+3LA@mail.gmail.com>
	<20120625132936.GV11942@merlinux.eu>
	<CAAWk_DzSqd8LyDmieoc_uSrRLDJRwoE7h-C5bEGnAZG0b4Ks6w@mail.gmail.com>
	<20120625152351.GA11942@merlinux.eu>
Message-ID: <CAAWk_DzAZWLzyyY4AochotSWp_+2UG3NwVXE4fbHFanvTMOazQ@mail.gmail.com>

Another remark about this.  If my use-case of dynamically creating
funcargs/resources is making this too complicated then feel free to
ignore it for now.  As you rightly point out it is not that cumbersome
to achieve the same with the existing funcargs.  See it more as a
nice-to-have but I don't want it to become an ill-thought-out legacy
you have to provide compatibility for later.

Regards,
Floris


On 25 June 2012 16:23, holger krekel <holger at merlinux.eu> wrote:
> On Mon, Jun 25, 2012 at 15:21 +0100, Floris Bruynooghe wrote:
>> On 25 June 2012 14:29, holger krekel <holger at merlinux.eu> wrote:
>> > On Mon, Jun 25, 2012 at 10:55 +0100, Floris Bruynooghe wrote:
>> >> The concrete example I have now is that it could be nice in
>> >> pytest-django to be able to request e.g. "Users" which is a model
>> >> class used to access the User table in the database. ?Currently this
>> >> is only possible by someone explicitly defining pytest_funcarg__Users,
>> >> but Django allows you to dynamically look up all the models in the
>> >> database so there is no reason this can't be build automatically.
>> >>
>> >> I think this is what the API you proposed was for, but as I said I
>> >> can't remember the details. ?And in this case I might be less
>> >> enthusiastic in postponing it's implementation to a later release ;-)
>> >
>> > It's probably true that we could invent an register-factory API for this.
>> >
>> > However, what about a single "models" object (done traditionally
>> > with a pytest_funcarg__models definition) which itself provides
>> > an API to give "Users" or others data?
>>
>> Yes of course, that is what I currently have in my conftest.py. ?But
>> it would still be a nice thing to be able to do and a nice example of
>> functionality I have wished I had before. ?Hence I was wondering if
>> the API you talked about yesterday would support it.
>
> I guess it could, for example, look like this::
>
> ? ?def pytest_configure(config): ?# [1]
> ? ? ? ?def createmodel(name, node):
> ? ? ? ? ? ?""" return django model object. """
> ? ? ? ? ? ?# node can be None, Directory, Module, Class, Item, etc.
> ? ? ? ? ? ?# (code to compute model)
> ? ? ? ? ? ?return model
>
> ? ? ? ?for name in modelnames:
> ? ? ? ? ? ?config.register_factory(name, createmodel)
>
> Getting a resource would work like this::
>
> ? ?config.getresource(name)
>
> The "--funcargs" option would (remain) able to show the docstring
> and location of the createmodel function.
>
> Another interesting bit is how to use register_factory
> to connect the existing "pytest_funcarg__..." factories
> which have a certain scope. ?I guess something like this::
>
> ? ?config.register_factory(name, factoryfunc, node)
>
> would suffice - it would restrict the scope of the factory
> function to the specified node and all of its descendents.
> It could be called from Directory, Module, Class's setup methods
> to register the respective "pytest_funcarg__" functions scoped as
> per-directory (conftest.py), per-module or per-class factories.
>
> Note that the "node" passed to the createmodel factory function
> above is probably neccessary for this case because existing
> funcarg-factories operate on Items (or in the future Nodes).
>
> getfuncargvalue() would then be implemented in terms of a
> call to config.getresource(name, node).
>
> In general, register_factory needs to be callable multiple
> times with the same name. ?accept multiple factories for
> the same resource will One little issues is that we want to
>
> This new resource registration/lookup could work much
> more efficiently than the current scheme which - upon every getfuncargvalue() -
> iterates over all plugins, modules and classes to discover matching
> pytest_funcarg__ factories.
>
> hope this all makes some sense.
>
> best,
> holger
>
>
> [1] We really need a new hook like pytest_runtest_init() which
> ? ?is called once before the runtest loop actually starts it work.
> ? ?pytest_configure() usually works but it is also called on the
> ? ?xdist-master process for which setting up resources makes no sense.
>
>> Floris
>>
>> --
>> Debian GNU/Linux -- The Power of Freedom
>> www.debian.org | www.gnu.org | www.kernel.org
>>



-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org


From holger at merlinux.eu  Tue Jun 26 16:15:11 2012
From: holger at merlinux.eu (holger krekel)
Date: Tue, 26 Jun 2012 14:15:11 +0000
Subject: [py-dev] Resource providers
In-Reply-To: <CAAWk_DyOeY8XnMOi22typyL6t1pdvdpbzWKvbFHF-4fWSRYN=A@mail.gmail.com>
References: <CAAWk_Dzzp0TPsgJAT5gXna1KtxUGYZNbEokD5ZWrObbtKw+3LA@mail.gmail.com>
	<20120625132936.GV11942@merlinux.eu>
	<CAAWk_DzSqd8LyDmieoc_uSrRLDJRwoE7h-C5bEGnAZG0b4Ks6w@mail.gmail.com>
	<20120625152351.GA11942@merlinux.eu>
	<CAAWk_DyOeY8XnMOi22typyL6t1pdvdpbzWKvbFHF-4fWSRYN=A@mail.gmail.com>
Message-ID: <20120626141511.GJ11942@merlinux.eu>

On Tue, Jun 26, 2012 at 15:07 +0100, Floris Bruynooghe wrote:
> On 25 June 2012 16:23, holger krekel <holger at merlinux.eu> wrote:
> > On Mon, Jun 25, 2012 at 15:21 +0100, Floris Bruynooghe wrote:
> >> On 25 June 2012 14:29, holger krekel <holger at merlinux.eu> wrote:
> >> > On Mon, Jun 25, 2012 at 10:55 +0100, Floris Bruynooghe wrote:
> >> >> The concrete example I have now is that it could be nice in
> >> >> pytest-django to be able to request e.g. "Users" which is a model
> >> >> class used to access the User table in the database. ?Currently this
> >> >> is only possible by someone explicitly defining pytest_funcarg__Users,
> >> >> but Django allows you to dynamically look up all the models in the
> >> >> database so there is no reason this can't be build automatically.
> >> >>
> >> >> I think this is what the API you proposed was for, but as I said I
> >> >> can't remember the details. ?And in this case I might be less
> >> >> enthusiastic in postponing it's implementation to a later release ;-)
> >> >
> >> > It's probably true that we could invent an register-factory API for this.
> >> >
> >> > However, what about a single "models" object (done traditionally
> >> > with a pytest_funcarg__models definition) which itself provides
> >> > an API to give "Users" or others data?
> >>
> >> Yes of course, that is what I currently have in my conftest.py. ?But
> >> it would still be a nice thing to be able to do and a nice example of
> >> functionality I have wished I had before. ?Hence I was wondering if
> >> the API you talked about yesterday would support it.
> >
> > I guess it could, for example, look like this::
> >
> > ? ?def pytest_configure(config): ?# [1]
> > ? ? ? ?def createmodel(name, node):
> > ? ? ? ? ? ?""" return django model object. """
> > ? ? ? ? ? ?# node can be None, Directory, Module, Class, Item, etc.
> > ? ? ? ? ? ?# (code to compute model)
> > ? ? ? ? ? ?return model
> >
> > ? ? ? ?for name in modelnames:
> > ? ? ? ? ? ?config.register_factory(name, createmodel)
> 
> I think for addressing this specific usecase I was more imagining a
> standard pytest hook:
> 
>    def pytest_resource_factory(name, item):
>        """The docstring which can show up in --funcargs"""
>        if name == 'User':
>            return models.User

The docstring cannot show up in --funcargs because it would
be unclear to which name it actually belongs without executing it.
And just showing that there is a generic factory hook would not
be very informative.

> That way it can be scoped per-directory in the conftest.py files and
> used in plugins, which would be scoped globally.
> 
> I appreciate that this does not provide the other benefits nor can it
> be used to implement funcargs themself.  So maybe there is a need for
> an API you just describe which would allow one to implement what I
> just described in a plugin as well as write the funcargs as a plugin.
> But I'm much less comfortable suggesting what that API should be like,
> I do not fully know the innards of py.test like you do.

thanks for the feedback.  I am going to see if i get a day
to play around with an implementation for the suggested api.

best,
holger


From holger at merlinux.eu  Tue Jun 26 16:18:39 2012
From: holger at merlinux.eu (holger krekel)
Date: Tue, 26 Jun 2012 14:18:39 +0000
Subject: [py-dev] Resource providers
In-Reply-To: <CAAWk_DzAZWLzyyY4AochotSWp_+2UG3NwVXE4fbHFanvTMOazQ@mail.gmail.com>
References: <CAAWk_Dzzp0TPsgJAT5gXna1KtxUGYZNbEokD5ZWrObbtKw+3LA@mail.gmail.com>
	<20120625132936.GV11942@merlinux.eu>
	<CAAWk_DzSqd8LyDmieoc_uSrRLDJRwoE7h-C5bEGnAZG0b4Ks6w@mail.gmail.com>
	<20120625152351.GA11942@merlinux.eu>
	<CAAWk_DzAZWLzyyY4AochotSWp_+2UG3NwVXE4fbHFanvTMOazQ@mail.gmail.com>
Message-ID: <20120626141839.GK11942@merlinux.eu>

On Tue, Jun 26, 2012 at 15:13 +0100, Floris Bruynooghe wrote:
> Another remark about this.  If my use-case of dynamically creating
> funcargs/resources is making this too complicated then feel free to
> ignore it for now.  As you rightly point out it is not that cumbersome
> to achieve the same with the existing funcargs.  See it more as a
> nice-to-have but I don't want it to become an ill-thought-out legacy
> you have to provide compatibility for later.

no worries.  I appreciate the use-case perspective a lot.  If i get
into too many details about implementation, feel free to stop me :)

holger

> Regards,
> Floris
> 
> 
> On 25 June 2012 16:23, holger krekel <holger at merlinux.eu> wrote:
> > On Mon, Jun 25, 2012 at 15:21 +0100, Floris Bruynooghe wrote:
> >> On 25 June 2012 14:29, holger krekel <holger at merlinux.eu> wrote:
> >> > On Mon, Jun 25, 2012 at 10:55 +0100, Floris Bruynooghe wrote:
> >> >> The concrete example I have now is that it could be nice in
> >> >> pytest-django to be able to request e.g. "Users" which is a model
> >> >> class used to access the User table in the database. ?Currently this
> >> >> is only possible by someone explicitly defining pytest_funcarg__Users,
> >> >> but Django allows you to dynamically look up all the models in the
> >> >> database so there is no reason this can't be build automatically.
> >> >>
> >> >> I think this is what the API you proposed was for, but as I said I
> >> >> can't remember the details. ?And in this case I might be less
> >> >> enthusiastic in postponing it's implementation to a later release ;-)
> >> >
> >> > It's probably true that we could invent an register-factory API for this.
> >> >
> >> > However, what about a single "models" object (done traditionally
> >> > with a pytest_funcarg__models definition) which itself provides
> >> > an API to give "Users" or others data?
> >>
> >> Yes of course, that is what I currently have in my conftest.py. ?But
> >> it would still be a nice thing to be able to do and a nice example of
> >> functionality I have wished I had before. ?Hence I was wondering if
> >> the API you talked about yesterday would support it.
> >
> > I guess it could, for example, look like this::
> >
> > ? ?def pytest_configure(config): ?# [1]
> > ? ? ? ?def createmodel(name, node):
> > ? ? ? ? ? ?""" return django model object. """
> > ? ? ? ? ? ?# node can be None, Directory, Module, Class, Item, etc.
> > ? ? ? ? ? ?# (code to compute model)
> > ? ? ? ? ? ?return model
> >
> > ? ? ? ?for name in modelnames:
> > ? ? ? ? ? ?config.register_factory(name, createmodel)
> >
> > Getting a resource would work like this::
> >
> > ? ?config.getresource(name)
> >
> > The "--funcargs" option would (remain) able to show the docstring
> > and location of the createmodel function.
> >
> > Another interesting bit is how to use register_factory
> > to connect the existing "pytest_funcarg__..." factories
> > which have a certain scope. ?I guess something like this::
> >
> > ? ?config.register_factory(name, factoryfunc, node)
> >
> > would suffice - it would restrict the scope of the factory
> > function to the specified node and all of its descendents.
> > It could be called from Directory, Module, Class's setup methods
> > to register the respective "pytest_funcarg__" functions scoped as
> > per-directory (conftest.py), per-module or per-class factories.
> >
> > Note that the "node" passed to the createmodel factory function
> > above is probably neccessary for this case because existing
> > funcarg-factories operate on Items (or in the future Nodes).
> >
> > getfuncargvalue() would then be implemented in terms of a
> > call to config.getresource(name, node).
> >
> > In general, register_factory needs to be callable multiple
> > times with the same name. ?accept multiple factories for
> > the same resource will One little issues is that we want to
> >
> > This new resource registration/lookup could work much
> > more efficiently than the current scheme which - upon every getfuncargvalue() -
> > iterates over all plugins, modules and classes to discover matching
> > pytest_funcarg__ factories.
> >
> > hope this all makes some sense.
> >
> > best,
> > holger
> >
> >
> > [1] We really need a new hook like pytest_runtest_init() which
> > ? ?is called once before the runtest loop actually starts it work.
> > ? ?pytest_configure() usually works but it is also called on the
> > ? ?xdist-master process for which setting up resources makes no sense.
> >
> >> Floris
> >>
> >> --
> >> Debian GNU/Linux -- The Power of Freedom
> >> www.debian.org | www.gnu.org | www.kernel.org
> >>
> 
> 
> 
> -- 
> Debian GNU/Linux -- The Power of Freedom
> www.debian.org | www.gnu.org | www.kernel.org
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev


From holger at merlinux.eu  Wed Jun 27 14:57:42 2012
From: holger at merlinux.eu (holger krekel)
Date: Wed, 27 Jun 2012 12:57:42 +0000
Subject: [py-dev] RFC: draft new resource management API (v1)
Message-ID: <20120627125742.GO11942@merlinux.eu>

Hi all,

based on on initial discussions with Ronny and Floris i have now written
a usage-level document for a new test resource management API.  It aims
to better support plugin and test writers in managing cross-test-suite
resources such as databases, temporary directories, etc.  It generalizes
the existing funcarg factory mechanism - currently some knowledge of
such pytest usages is required to understand the document. Also, it does
not fully spell out all details yet - i hope it nevertheless transports
the main ideas.

Happy about any feedback,

holger

V1: Creating and working with test resources
==============================================

pytest-2.3 provides generalized resource management allowing
to flexibly manage caching and parametrization across your test suite.

This is draft documentation, pending refinements and changes according
to feedback and to implementation or backward compatibility issues
(the new mechanism is supposed to allow fully backward compatible
operations for uses of the "funcarg" mechanism).

the new global pytest_runtest_init hook
------------------------------------------------------

Prior to 2.3, pytest offered a pytest_configure and a pytest_sessionstart
hook which was used often to setup global resources.  This suffers from
several problems. First of all, in distributed testing the master would
also setup test resources that are never needed because it only co-ordinates
the test run activities of the slave processes.  Secondly, in large test
suites resources are setup that might not be needed for the concrete test
run.  The first issue is solved through the introduction of a specific
hook::

    def pytest_runtest_init(session):
        # called ahead of pytest_runtestloop() test execution

This hook will only be called in processes that actually run tests.

The second issue is solved through a new register/getresource API which
will only ever setup resources if they are needed.  See the following
examples and sections on how this works.


managing a global database resource
---------------------------------------------------------------

If you have one database object which you want to use in tests
you can write the following into a conftest.py file::

    class Database:
        def __init__(self):
            print ("database instance created")
        def destroy(self):
            print ("database instance destroyed")

    def factory_db(name, node):
        db = Database()
        node.addfinalizer(db.destroy)
        return db

    def pytest_runtest_init(session):
        session.register_resource("db", factory_db, atnode=session)

You can then access the constructed resource in a test like this::

    def test_something(db):
        ...

The "db" function argument will lead to a lookup of the respective
factory value and be passed to the function body.  According to the
registration, the db object will be instantiated on a per-session basis
and thus reused across all test functions that require it.

instantiating a database resource per-module
---------------------------------------------------------------

If you want one database instance per test module you can restrict
caching by modifying the "atnode" parameter of the registration 
call above::

    def pytest_runtest_init(session):
        session.register_resource("db", factory_db, atnode=pytest.Module)

Neither the tests nor the factory function will need to change.
This also means that you can decide the scoping of resources
at runtime - e.g. based on a command line option: for developer
settings you might want per-session and for Continous Integration
runs you might prefer per-module or even per-function scope like this::

    def pytest_runtest_init(session):
        session.register_resource_factory("db", factory_db, 
                                          atnode=pytest.Function)

parametrized resources
----------------------------------

If you want to rerun tests with different resource values you can specify
a list of factories instead of just one::

    def pytest_runtest_init(session):
        session.register_factory("db", [factory1, factory2], atnode=session)

In this case all tests that depend on the "db" resource will be run twice
using the respective values obtained from the two factory functions.


Using a resource from another resource factory
----------------------------------------------

You can use the database resource from a another resource factory through
the ``node.getresource()`` method.  Let's add a resource factory for
a "db_users" table at module-level, extending the previous db-example::

    def pytest_runtest_init(session):
        ...
        session.register_factory("db_users", createusers, atnode=module)

    def createusers(name, node):
        db = node.getresource("db")
        table = db.create_table("users", ...)
        node.addfinalizer(lambda: db.destroy_table("users")

    def test_user_creation(db_users):
        ...

The create-users will be called for each module.  After the tests in
that module finish execution, the table will be destroyed according
to registered finalizer.  Note that calling getresource() for a resource
which has a tighter scope will raise a LookupError because the
is not available at a more general scope. Concretely, if you
table is defined as a per-session resource and the database object as a
per-module one, the table creation cannot work on a per-session basis.


Setting resources as class attributes 
-------------------------------------------

If you want to make an attribute available on a test class, you can 
use the resource_attr marker::

    @pytest.mark.resource_attr("db")
    class TestClass:
        def test_something(self):
            #use self.db 

Note that this way of using resources can be used on unittest.TestCase
instances as well (function arguments can not be added due to unittest 
limitations).


How the funcarg mechanism is implemented (internal notes)
-------------------------------------------------------------

Prior to pytest-2.3/4, pytest advertised the "funcarg" mechanism 
which provided a subset functionality to the generalized resource management.
In fact, the previous mechanism is implemented in terms of the new API
and should continue to work unmodified.  It basically automates the
registration of  factories through automatic discovery of 
``pytest_funcarg_NAME`` function on plugins, Python modules and classes.

As an example let's consider the Module.setup() method::

    class Module(PyCollector):
        def setup(self):
            for name, func in self.obj.__dict__.items():
                if name.startswith("pytest_funcarg__"):
                    resourcename = name[len("pytest_funcarg__"):]
                    self._register_factory(resourcename, 
                                           RequestAdapter(self, name, func))

The request adapater takes care to provide the pre-2.3 API for funcarg
factories, providing request.cached_setup/addfinalizer/getfuncargvalue
methods.


From flub at devork.be  Wed Jun 27 17:59:18 2012
From: flub at devork.be (Floris Bruynooghe)
Date: Wed, 27 Jun 2012 16:59:18 +0100
Subject: [py-dev] RFC: draft new resource management API (v1)
In-Reply-To: <20120627125742.GO11942@merlinux.eu>
References: <20120627125742.GO11942@merlinux.eu>
Message-ID: <CAAWk_Dxk+KJvyB3pvtpxBFyQ3aK7pkqwJqeTSEcqnEYj7_V_9A@mail.gmail.com>

Hello Holger,

Thanks for the detailed document.  As I understand it the vast
majority of the functionality is already possible using funcargs.
Maybe a summary of the benefits over plain funcargs could be helpful?
And some guidance for plugin writers on which of the two to choose
would also be helpful.

Also, as a general observation I think it will become harder to find
where a resource factory lives.  Before you could just grep for
pytest_funcarg__foo which was actually quite nice, certainly when
you're extending a resource at different levels.  This is still
possible but not as easy.

Other then that I've got only one comment really:

On 27 June 2012 13:57, holger krekel <holger at merlinux.eu> wrote:
> Setting resources as class attributes
> -------------------------------------------
>
> If you want to make an attribute available on a test class, you can
> use the resource_attr marker::
>
> ? ?@pytest.mark.resource_attr("db")
> ? ?class TestClass:
> ? ? ? ?def test_something(self):
> ? ? ? ? ? ?#use self.db

I'm not convinced of creating a special purpose mark for this.
Firstly it seems like an anti-pattern in py.test to me, more like
xUnit style.  Secondly if someone wanted an attribute wouldn't this be
easily done with::

   class TestClas(object):
       @classmethod
       def setup_class(cls, item):
           cls.db = item.getresource('db')


Also, I realised this API provides for what is probably most of the
cases of where I want dynamic resources:

def pytest_setup_init(session):
    for item in my_item_generator():
        session.register_resource_factory(item.name, item)

(presuming atnode=session is the default)


Regards,
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org


From holger at merlinux.eu  Wed Jun 27 18:15:54 2012
From: holger at merlinux.eu (holger krekel)
Date: Wed, 27 Jun 2012 16:15:54 +0000
Subject: [py-dev] RFC: draft new resource management API (v1)
In-Reply-To: <4FEB1C12.700@oddbird.net>
References: <20120627125742.GO11942@merlinux.eu>
 <4FEB1C12.700@oddbird.net>
Message-ID: <20120627161554.GP11942@merlinux.eu>

On Wed, Jun 27, 2012 at 08:43 -0600, Carl Meyer wrote:
> I like it! In particular the parametrization support by passing a list
> is a quite intuitive extension of the API.
> 
> "atnode" seems like an opaque arg name - what's wrong with "scope"? The
> latter name seems more intuitive to me. Would this arg have a default value?

"scope" makes sense - it's just that in the current API scope is a
"class", "module", ... string.  Existing users might easily get a bit of
type clash - especially if you have a mixed funcarg/resource scenario.
Maybe "scopenode"?

The default scopenode would be the one on which you are calling
"register_factory".  So in the first documented example call:

    session.register_factory("db", createdb, scopenode=session)

the "scopenode" call would actually be superfluous.  (Sidenote: the session 
object is also a node - the root node from which all collection and item 
nodes are descendants.  Each node has a ".session" reference back to this
root node).

> In the long run, if funcarg-style is considered a useful shortcut and
> will not be deprecated, it would be nice if there were a bit more naming
> and API consistency between funcarg-style and new-style resource
> handling -- it would make them feel more aspects of one system rather
> than two different systems. I think this would really just require
> switching from pytest_funcarg__foo to pytest_resource__foo, renaming
> cached_setup to register_factory (and having it use the same API), and
> renaming getfuncargvalue to getresource. Of course I don't know whether
> this consistency is really worth the backwards-compatibility/deprecation
> hassles.

* getresource/getfuncargvalue: makes sense to me to go for advertising and
  documenting getresource() instead of getfuncargvalue() and keeping
  the latter as an alias with or without deprecation.

* addfinalizer would remain unmodified - it's just that the "request"
  object passed to funcarg-factories adds finalizers with test function 
  invocation scope, whereas node.addfinalizer() does it for the respective
  node scope (so e.g. called from a Class node it would register a per-class 
  finalizer)

* cached_setup: i hope that we do not need to offer this method anymore
  other than for compatibility.  It's internal caching-key is not easy 
  to explain and more than once users have stumbled about understanding it.
  cached_setup is required as long as pytest_funcarg__ factories are called
  _each_ time a resource is requested. (By contrast the new getresource()
  only triggers a factory call once for the registered scope - thus
  the factory implementation itself does not need to care for caching).

  Note that register_factory is a different beast than cached_setup: 
  it does not create a value, just registers a factory. So i don't see 
  how we can unify this.

As to a possible resource-factory auto-discovery, i can imagine it to
work with introducing a marker::

    # example content in a test module or in a conftest.py file

    @pytest.mark.resourcefactory("db", scope=pytest.Class)
    def myfactory(name, node):
        # factory called once per each requesting class (methods
        # on this class will share the returned value)

this declaration would trigger a register_factory("db", myfactory) call. 
If we want to extend this to parametrization (multiple db factories)
we probably need something like this::

    @pytest.mark.resourcefactory("db", scope=pytest.Class, multi=True)
    def make_db_factories(name, node):
        factoryfuncs = [compute list of factory funcs]
        return factoryfuncs

This would be called at collection time and the scope and the number
of to-be-created values would be known in advance.  It's basically
equivalent to a classnode.register_factory([list of factory funcs]) call.
(we could auto-magically recognize yield-generating functions but i'd
like to avoid it).

To go the full circle, the signature of factory functions could rather
accept a "request" object instead of (name, node). Actually today, a 
request object has this internal state anyway. pytest_funcarg__ would thus 
only look slighly special in that it skips the marker and has a fixed scope
of "pytest.Function".

Hope this thought train makes some sense :)
holger


From Ronny.Pfannschmidt at gmx.de  Wed Jun 27 18:32:53 2012
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Wed, 27 Jun 2012 18:32:53 +0200
Subject: [py-dev] RFC: draft new resource management API (v1)
In-Reply-To: <20120627161554.GP11942@merlinux.eu>
References: <20120627125742.GO11942@merlinux.eu> <4FEB1C12.700@oddbird.net>
	<20120627161554.GP11942@merlinux.eu>
Message-ID: <4FEB35B5.60200@gmx.de>

i noticed that there is no way to name items in those lists

On 06/27/2012 06:15 PM, holger krekel wrote:
> On Wed, Jun 27, 2012 at 08:43 -0600, Carl Meyer wrote:
>> I like it! In particular the parametrization support by passing a list
>> is a quite intuitive extension of the API.
>>
>> "atnode" seems like an opaque arg name - what's wrong with "scope"? The
>> latter name seems more intuitive to me. Would this arg have a default value?
>
> "scope" makes sense - it's just that in the current API scope is a
> "class", "module", ... string.  Existing users might easily get a bit of
> type clash - especially if you have a mixed funcarg/resource scenario.
> Maybe "scopenode"?
>
> The default scopenode would be the one on which you are calling
> "register_factory".  So in the first documented example call:
>
>      session.register_factory("db", createdb, scopenode=session)
>
> the "scopenode" call would actually be superfluous.  (Sidenote: the session
> object is also a node - the root node from which all collection and item
> nodes are descendants.  Each node has a ".session" reference back to this
> root node).
>
>> In the long run, if funcarg-style is considered a useful shortcut and
>> will not be deprecated, it would be nice if there were a bit more naming
>> and API consistency between funcarg-style and new-style resource
>> handling -- it would make them feel more aspects of one system rather
>> than two different systems. I think this would really just require
>> switching from pytest_funcarg__foo to pytest_resource__foo, renaming
>> cached_setup to register_factory (and having it use the same API), and
>> renaming getfuncargvalue to getresource. Of course I don't know whether
>> this consistency is really worth the backwards-compatibility/deprecation
>> hassles.
>
> * getresource/getfuncargvalue: makes sense to me to go for advertising and
>    documenting getresource() instead of getfuncargvalue() and keeping
>    the latter as an alias with or without deprecation.
>
> * addfinalizer would remain unmodified - it's just that the "request"
>    object passed to funcarg-factories adds finalizers with test function
>    invocation scope, whereas node.addfinalizer() does it for the respective
>    node scope (so e.g. called from a Class node it would register a per-class
>    finalizer)
>
> * cached_setup: i hope that we do not need to offer this method anymore
>    other than for compatibility.  It's internal caching-key is not easy
>    to explain and more than once users have stumbled about understanding it.
>    cached_setup is required as long as pytest_funcarg__ factories are called
>    _each_ time a resource is requested. (By contrast the new getresource()
>    only triggers a factory call once for the registered scope - thus
>    the factory implementation itself does not need to care for caching).
>
>    Note that register_factory is a different beast than cached_setup:
>    it does not create a value, just registers a factory. So i don't see
>    how we can unify this.
>
> As to a possible resource-factory auto-discovery, i can imagine it to
> work with introducing a marker::
>
>      # example content in a test module or in a conftest.py file
>
>      @pytest.mark.resourcefactory("db", scope=pytest.Class)
>      def myfactory(name, node):
>          # factory called once per each requesting class (methods
>          # on this class will share the returned value)
>
> this declaration would trigger a register_factory("db", myfactory) call.
> If we want to extend this to parametrization (multiple db factories)
> we probably need something like this::
>
>      @pytest.mark.resourcefactory("db", scope=pytest.Class, multi=True)
>      def make_db_factories(name, node):
>          factoryfuncs = [compute list of factory funcs]
>          return factoryfuncs
>
> This would be called at collection time and the scope and the number
> of to-be-created values would be known in advance.  It's basically
> equivalent to a classnode.register_factory([list of factory funcs]) call.
> (we could auto-magically recognize yield-generating functions but i'd
> like to avoid it).
>
> To go the full circle, the signature of factory functions could rather
> accept a "request" object instead of (name, node). Actually today, a
> request object has this internal state anyway. pytest_funcarg__ would thus
> only look slighly special in that it skips the marker and has a fixed scope
> of "pytest.Function".
>
> Hope this thought train makes some sense :)
> holger
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev



From holger at merlinux.eu  Wed Jun 27 20:36:47 2012
From: holger at merlinux.eu (holger krekel)
Date: Wed, 27 Jun 2012 18:36:47 +0000
Subject: [py-dev] RFC: draft new resource management API (v1)
In-Reply-To: <CAAWk_Dxk+KJvyB3pvtpxBFyQ3aK7pkqwJqeTSEcqnEYj7_V_9A@mail.gmail.com>
References: <20120627125742.GO11942@merlinux.eu>
	<CAAWk_Dxk+KJvyB3pvtpxBFyQ3aK7pkqwJqeTSEcqnEYj7_V_9A@mail.gmail.com>
Message-ID: <20120627183647.GR11942@merlinux.eu>

Hi Floris,

On Wed, Jun 27, 2012 at 16:59 +0100, Floris Bruynooghe wrote:
> Hello Holger,
> 
> Thanks for the detailed document.  As I understand it the vast
> majority of the functionality is already possible using funcargs.
> Maybe a summary of the benefits over plain funcargs could be helpful?

makes sense.  Maybe some X versus Y examples would help.

> And some guidance for plugin writers on which of the two to choose
> would also be helpful.

Yip.  I think the examples should make it clear that probably the
new API is best fitting in most cases.

> Also, as a general observation I think it will become harder to find
> where a resource factory lives.  Before you could just grep for
> pytest_funcarg__foo which was actually quite nice, certainly when
> you're extending a resource at different levels.  This is still
> possible but not as easy.

Right, the grep-ability was intended behaviour.  It would remain
possible with the new resourcefactory markers i pondered in my
reply to Carl.  Otherwise you would need to invoke "py.test --funcargs"
to get the locations.

> Other then that I've got only one comment really:
> 
> On 27 June 2012 13:57, holger krekel <holger at merlinux.eu> wrote:
> > Setting resources as class attributes
> > -------------------------------------------
> >
> > If you want to make an attribute available on a test class, you can
> > use the resource_attr marker::
> >
> > ? ?@pytest.mark.resource_attr("db")
> > ? ?class TestClass:
> > ? ? ? ?def test_something(self):
> > ? ? ? ? ? ?#use self.db
> 
> I'm not convinced of creating a special purpose mark for this.
> Firstly it seems like an anti-pattern in py.test to me, more like
> xUnit style.

unittest/xUnit-compat is the main idea for this new marker. It would
work on pytest and unittest.TestCase classes alike.  It's also reminiscent
of Rob Collin's testscenario unittest-extension.

> easily done with::
> 
>    class TestClas(object):
>        @classmethod
>        def setup_class(cls, item):
>            cls.db = item.getresource('db')

Not really.  Here we would need to check if the setup_class() 
accepts an item parameter and setup_class methods do not follow
the hook-keyword-arg-calling convention.  Also passing an
item would be slightly arbitrary as the setup_class would
only be called once for all of its test items (functions).

> Also, I realised this API provides for what is probably most of the
> cases of where I want dynamic resources:
> 
> def pytest_setup_init(session):
>     for item in my_item_generator():
>         session.register_resource_factory(item.name, item)

Not sure i understand this idea.  Is it intended as a mixture of 
collection (my_item_generator) and setup (as the hook name suggests)? 

Note that the doc is currently wrong a bit as well - the register_factory
would need to happen at collection-time, not setup-time as the Module.setup()
wrongly suggested.

best,
holger

> (presuming atnode=session is the default)
> 
> 
> Regards,
> Floris
> 
> 
> -- 
> Debian GNU/Linux -- The Power of Freedom
> www.debian.org | www.gnu.org | www.kernel.org
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev


From holger at merlinux.eu  Wed Jun 27 20:41:47 2012
From: holger at merlinux.eu (holger krekel)
Date: Wed, 27 Jun 2012 18:41:47 +0000
Subject: [py-dev] RFC: draft new resource management API (v1)
In-Reply-To: <4FEB35B5.60200@gmx.de>
References: <20120627125742.GO11942@merlinux.eu> <4FEB1C12.700@oddbird.net>
	<20120627161554.GP11942@merlinux.eu> <4FEB35B5.60200@gmx.de>
Message-ID: <20120627184147.GS11942@merlinux.eu>

On Wed, Jun 27, 2012 at 18:32 +0200, Ronny Pfannschmidt wrote:
> i noticed that there is no way to name items in those lists

could you insert this comment in context?

If you refer to the resourcefactory(multi=True) example, then
the name is known at factory-list construction time.

A a sidenote, i now notice that it's unclear how this whole api
discussion relates to the recently introduced @parametrize decorator and
the pytest_generate_tests hook and metafunc.parametrize() call.

hum'ly yours,
holger



> On 06/27/2012 06:15 PM, holger krekel wrote:
> > On Wed, Jun 27, 2012 at 08:43 -0600, Carl Meyer wrote:
> >> I like it! In particular the parametrization support by passing a list
> >> is a quite intuitive extension of the API.
> >>
> >> "atnode" seems like an opaque arg name - what's wrong with "scope"? The
> >> latter name seems more intuitive to me. Would this arg have a default value?
> >
> > "scope" makes sense - it's just that in the current API scope is a
> > "class", "module", ... string.  Existing users might easily get a bit of
> > type clash - especially if you have a mixed funcarg/resource scenario.
> > Maybe "scopenode"?
> >
> > The default scopenode would be the one on which you are calling
> > "register_factory".  So in the first documented example call:
> >
> >      session.register_factory("db", createdb, scopenode=session)
> >
> > the "scopenode" call would actually be superfluous.  (Sidenote: the session
> > object is also a node - the root node from which all collection and item
> > nodes are descendants.  Each node has a ".session" reference back to this
> > root node).
> >
> >> In the long run, if funcarg-style is considered a useful shortcut and
> >> will not be deprecated, it would be nice if there were a bit more naming
> >> and API consistency between funcarg-style and new-style resource
> >> handling -- it would make them feel more aspects of one system rather
> >> than two different systems. I think this would really just require
> >> switching from pytest_funcarg__foo to pytest_resource__foo, renaming
> >> cached_setup to register_factory (and having it use the same API), and
> >> renaming getfuncargvalue to getresource. Of course I don't know whether
> >> this consistency is really worth the backwards-compatibility/deprecation
> >> hassles.
> >
> > * getresource/getfuncargvalue: makes sense to me to go for advertising and
> >    documenting getresource() instead of getfuncargvalue() and keeping
> >    the latter as an alias with or without deprecation.
> >
> > * addfinalizer would remain unmodified - it's just that the "request"
> >    object passed to funcarg-factories adds finalizers with test function
> >    invocation scope, whereas node.addfinalizer() does it for the respective
> >    node scope (so e.g. called from a Class node it would register a per-class
> >    finalizer)
> >
> > * cached_setup: i hope that we do not need to offer this method anymore
> >    other than for compatibility.  It's internal caching-key is not easy
> >    to explain and more than once users have stumbled about understanding it.
> >    cached_setup is required as long as pytest_funcarg__ factories are called
> >    _each_ time a resource is requested. (By contrast the new getresource()
> >    only triggers a factory call once for the registered scope - thus
> >    the factory implementation itself does not need to care for caching).
> >
> >    Note that register_factory is a different beast than cached_setup:
> >    it does not create a value, just registers a factory. So i don't see
> >    how we can unify this.
> >
> > As to a possible resource-factory auto-discovery, i can imagine it to
> > work with introducing a marker::
> >
> >      # example content in a test module or in a conftest.py file
> >
> >      @pytest.mark.resourcefactory("db", scope=pytest.Class)
> >      def myfactory(name, node):
> >          # factory called once per each requesting class (methods
> >          # on this class will share the returned value)
> >
> > this declaration would trigger a register_factory("db", myfactory) call.
> > If we want to extend this to parametrization (multiple db factories)
> > we probably need something like this::
> >
> >      @pytest.mark.resourcefactory("db", scope=pytest.Class, multi=True)
> >      def make_db_factories(name, node):
> >          factoryfuncs = [compute list of factory funcs]
> >          return factoryfuncs
> >
> > This would be called at collection time and the scope and the number
> > of to-be-created values would be known in advance.  It's basically
> > equivalent to a classnode.register_factory([list of factory funcs]) call.
> > (we could auto-magically recognize yield-generating functions but i'd
> > like to avoid it).
> >
> > To go the full circle, the signature of factory functions could rather
> > accept a "request" object instead of (name, node). Actually today, a
> > request object has this internal state anyway. pytest_funcarg__ would thus
> > only look slighly special in that it skips the marker and has a fixed scope
> > of "pytest.Function".
> >
> > Hope this thought train makes some sense :)
> > holger
> > _______________________________________________
> > py-dev mailing list
> > py-dev at codespeak.net
> > http://codespeak.net/mailman/listinfo/py-dev
> 
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 


From flub at devork.be  Thu Jun 28 09:47:48 2012
From: flub at devork.be (Floris Bruynooghe)
Date: Thu, 28 Jun 2012 08:47:48 +0100
Subject: [py-dev] RFC: draft new resource management API (v1)
In-Reply-To: <20120627183647.GR11942@merlinux.eu>
References: <20120627125742.GO11942@merlinux.eu>
	<CAAWk_Dxk+KJvyB3pvtpxBFyQ3aK7pkqwJqeTSEcqnEYj7_V_9A@mail.gmail.com>
	<20120627183647.GR11942@merlinux.eu>
Message-ID: <CAAWk_DwdZO_p8RBmqV-n30fcAO-Skc8=3ZCr1D3HJFWQe24gjQ@mail.gmail.com>

On 27 June 2012 19:36, holger krekel <holger at merlinux.eu> wrote:
> On Wed, Jun 27, 2012 at 16:59 +0100, Floris Bruynooghe wrote:
>> On 27 June 2012 13:57, holger krekel <holger at merlinux.eu> wrote:
>> > Setting resources as class attributes
>> > -------------------------------------------
>> >
>> > If you want to make an attribute available on a test class, you can
>> > use the resource_attr marker::
>> >
>> > ? ?@pytest.mark.resource_attr("db")
>> > ? ?class TestClass:
>> > ? ? ? ?def test_something(self):
>> > ? ? ? ? ? ?#use self.db
>>
>> I'm not convinced of creating a special purpose mark for this.
>> Firstly it seems like an anti-pattern in py.test to me, more like
>> xUnit style.
>
> unittest/xUnit-compat is the main idea for this new marker. It would
> work on pytest and unittest.TestCase classes alike. ?It's also reminiscent
> of Rob Collin's testscenario unittest-extension.
>
>> easily done with::
>>
>> ? ?class TestClas(object):
>> ? ? ? ?@classmethod
>> ? ? ? ?def setup_class(cls, item):
>> ? ? ? ? ? ?cls.db = item.getresource('db')
>
> Not really. ?Here we would need to check if the setup_class()
> accepts an item parameter and setup_class methods do not follow
> the hook-keyword-arg-calling convention. ?Also passing an
> item would be slightly arbitrary as the setup_class would
> only be called once for all of its test items (functions).

Oh, that will teach me to talk about an API I haven't used in a long
time without looking it up.  I thought a node (not item) was already
passed in.  Still, I think it would look nicer if it was possible to
get to the resources API from within .setup_module(module),
.setup_class(cls) and .setup_method(self, method) rather then needing
a new marker for this.  The first of these should not be a problem I
guess, since it already has a node passed in.  For .setup_method() the
method argument could have an item attribute.  But I guess
.setup_class(cls) is the hardest.  Would it be tricky to inspect the
arguments as done for hooks?


>> Also, I realised this API provides for what is probably most of the
>> cases of where I want dynamic resources:
>>
>> def pytest_setup_init(session):
>> ? ? for item in my_item_generator():
>> ? ? ? ? session.register_resource_factory(item.name, item)
>
> Not sure i understand this idea. ?Is it intended as a mixture of
> collection (my_item_generator) and setup (as the hook name suggests)?

My bad for writing a bad example, I shouldn't have used the word
"item" in there.  Anyway the main point is that thanks to
.register_resource_factory() taking the name of the resource as an
argument I believe most, if not all, the cases where I wanted to
create funcargs/resources without knowing what they where beforehand
are solved.


Regards,
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org


From holger at merlinux.eu  Thu Jun 28 10:15:45 2012
From: holger at merlinux.eu (holger krekel)
Date: Thu, 28 Jun 2012 08:15:45 +0000
Subject: [py-dev] RFC: draft new resource management API (v1)
In-Reply-To: <CAAWk_DwdZO_p8RBmqV-n30fcAO-Skc8=3ZCr1D3HJFWQe24gjQ@mail.gmail.com>
References: <20120627125742.GO11942@merlinux.eu>
	<CAAWk_Dxk+KJvyB3pvtpxBFyQ3aK7pkqwJqeTSEcqnEYj7_V_9A@mail.gmail.com>
	<20120627183647.GR11942@merlinux.eu>
	<CAAWk_DwdZO_p8RBmqV-n30fcAO-Skc8=3ZCr1D3HJFWQe24gjQ@mail.gmail.com>
Message-ID: <20120628081545.GT11942@merlinux.eu>

On Thu, Jun 28, 2012 at 08:47 +0100, Floris Bruynooghe wrote:
> On 27 June 2012 19:36, holger krekel <holger at merlinux.eu> wrote:
> > On Wed, Jun 27, 2012 at 16:59 +0100, Floris Bruynooghe wrote:
> >> On 27 June 2012 13:57, holger krekel <holger at merlinux.eu> wrote:
> >> > Setting resources as class attributes
> >> > -------------------------------------------
> >> >
> >> > If you want to make an attribute available on a test class, you can
> >> > use the resource_attr marker::
> >> >
> >> > ? ?@pytest.mark.resource_attr("db")
> >> > ? ?class TestClass:
> >> > ? ? ? ?def test_something(self):
> >> > ? ? ? ? ? ?#use self.db
> >>
> >> I'm not convinced of creating a special purpose mark for this.
> >> Firstly it seems like an anti-pattern in py.test to me, more like
> >> xUnit style.
> >
> > unittest/xUnit-compat is the main idea for this new marker. It would
> > work on pytest and unittest.TestCase classes alike. ?It's also reminiscent
> > of Rob Collin's testscenario unittest-extension.
> >
> >> easily done with::
> >>
> >> ? ?class TestClas(object):
> >> ? ? ? ?@classmethod
> >> ? ? ? ?def setup_class(cls, item):
> >> ? ? ? ? ? ?cls.db = item.getresource('db')
> >
> > Not really. ?Here we would need to check if the setup_class()
> > accepts an item parameter and setup_class methods do not follow
> > the hook-keyword-arg-calling convention. ?Also passing an
> > item would be slightly arbitrary as the setup_class would
> > only be called once for all of its test items (functions).
> 
> Oh, that will teach me to talk about an API I haven't used in a long
> time without looking it up.  I thought a node (not item) was already
> passed in.  Still, I think it would look nicer if it was possible to
> get to the resources API from within .setup_module(module),
> .setup_class(cls) and .setup_method(self, method) rather then needing
> a new marker for this.  The first of these should not be a problem I
> guess, since it already has a node passed in.  For .setup_method() the
> method argument could have an item attribute.  But I guess
> .setup_class(cls) is the hardest.  Would it be tricky to inspect the
> arguments as done for hooks?

setup_module/setup_class/setup_method all receive native python objects,
not collection nodes.  We could stick node attributes somewhere (not sure if 
on functions - they can be invoked multiple times in case of parametrization).

If we stick attributes e.g. on a pytest.current.item/classnode/... we
are doing side-effect programming - some internals will set those
attributes (and should take care to remove it to avoid
misusage/confusion) and some other places will read it.  These days, i
prefer to design APIs that communicate neccesarry state directly and
to use higher-level declarations to state intents rather than do everything
through imperative programming.

/me does "import this" and sees: Although practicality beats purity ...

I am still fine to consider e. g. the introduction of a pytest.current
namespace.  It could lead to make setup_X methods more powerful::

    import pytest
    def setup_module():  # pytest accepts it to keep nose compat
        db = pytest.current.modulenode.getresource("db")

The "current" namespace could be set by the respective node setup
methods.  For classes it's the same idea::

    class TestClass:
        def setup_class(cls):
            cls.db = pytest.current.classnode.getresource("db")

Due to the non-declarative nature of this approach, however, i don't
see a way to rerun the testclass with multiple "db" instances.

On a side note, many Java programmers have gone from the old JUnit
approach to TestNG, see the wikipedia entries.  py.test rather
goes for similar ideas as TestNG.

best,
holger

> 
> >> Also, I realised this API provides for what is probably most of the
> >> cases of where I want dynamic resources:
> >>
> >> def pytest_setup_init(session):
> >> ? ? for item in my_item_generator():
> >> ? ? ? ? session.register_resource_factory(item.name, item)
> >
> > Not sure i understand this idea. ?Is it intended as a mixture of
> > collection (my_item_generator) and setup (as the hook name suggests)?
> 
> My bad for writing a bad example, I shouldn't have used the word
> "item" in there.  Anyway the main point is that thanks to
> .register_resource_factory() taking the name of the resource as an
> argument I believe most, if not all, the cases where I wanted to
> create funcargs/resources without knowing what they where beforehand
> are solved.
> 
> 
> Regards,
> Floris
> 
> 
> -- 
> Debian GNU/Linux -- The Power of Freedom
> www.debian.org | www.gnu.org | www.kernel.org
> 


From holger at merlinux.eu  Thu Jun 28 10:22:52 2012
From: holger at merlinux.eu (holger krekel)
Date: Thu, 28 Jun 2012 08:22:52 +0000
Subject: [py-dev] RFC: draft new resource management API (v1)
In-Reply-To: <20120628081545.GT11942@merlinux.eu>
References: <20120627125742.GO11942@merlinux.eu>
	<CAAWk_Dxk+KJvyB3pvtpxBFyQ3aK7pkqwJqeTSEcqnEYj7_V_9A@mail.gmail.com>
	<20120627183647.GR11942@merlinux.eu>
	<CAAWk_DwdZO_p8RBmqV-n30fcAO-Skc8=3ZCr1D3HJFWQe24gjQ@mail.gmail.com>
	<20120628081545.GT11942@merlinux.eu>
Message-ID: <20120628082252.GU11942@merlinux.eu>

On Thu, Jun 28, 2012 at 08:15 +0000, holger krekel wrote:
> I am still fine to consider e. g. the introduction of a pytest.current
> namespace.  It could lead to make setup_X methods more powerful::
> 
>     import pytest
>     def setup_module():  # pytest accepts it to keep nose compat
>         db = pytest.current.modulenode.getresource("db")
> 
> The "current" namespace could be set by the respective node setup
> methods.  For classes it's the same idea::
> 
>     class TestClass:
>         def setup_class(cls):
>             cls.db = pytest.current.classnode.getresource("db")
> 
> Due to the non-declarative nature of this approach, however, i don't
> see a way to rerun the testclass with multiple "db" instances.

Actually i see a way :)

    @pytest.mark.uses_resource("db")
    class TestClass:
        ...

This would signal pytest that this class is (somehow) using
the parameter "db" and thus collect multiple variations if the
resource is parametrized at register_factory time.  Of course,
plugins such as pytest-django would be able to declare this resource
usage automatically, reducing boilerplate for test writers.

What do you think?

holger



> On a side note, many Java programmers have gone from the old JUnit
> approach to TestNG, see the wikipedia entries.  py.test rather
> goes for similar ideas as TestNG.
> 
> best,
> holger
> 
> > 
> > >> Also, I realised this API provides for what is probably most of the
> > >> cases of where I want dynamic resources:
> > >>
> > >> def pytest_setup_init(session):
> > >> ? ? for item in my_item_generator():
> > >> ? ? ? ? session.register_resource_factory(item.name, item)
> > >
> > > Not sure i understand this idea. ?Is it intended as a mixture of
> > > collection (my_item_generator) and setup (as the hook name suggests)?
> > 
> > My bad for writing a bad example, I shouldn't have used the word
> > "item" in there.  Anyway the main point is that thanks to
> > .register_resource_factory() taking the name of the resource as an
> > argument I believe most, if not all, the cases where I wanted to
> > create funcargs/resources without knowing what they where beforehand
> > are solved.
> > 
> > 
> > Regards,
> > Floris
> > 
> > 
> > -- 
> > Debian GNU/Linux -- The Power of Freedom
> > www.debian.org | www.gnu.org | www.kernel.org
> > 
> 


From flub at devork.be  Thu Jun 28 14:08:14 2012
From: flub at devork.be (Floris Bruynooghe)
Date: Thu, 28 Jun 2012 13:08:14 +0100
Subject: [py-dev] RFC: draft new resource management API (v1)
In-Reply-To: <20120628081545.GT11942@merlinux.eu>
References: <20120627125742.GO11942@merlinux.eu>
	<CAAWk_Dxk+KJvyB3pvtpxBFyQ3aK7pkqwJqeTSEcqnEYj7_V_9A@mail.gmail.com>
	<20120627183647.GR11942@merlinux.eu>
	<CAAWk_DwdZO_p8RBmqV-n30fcAO-Skc8=3ZCr1D3HJFWQe24gjQ@mail.gmail.com>
	<20120628081545.GT11942@merlinux.eu>
Message-ID: <CAAWk_DyvgOqzvbJX7F=a-aii5kPE+fPWgNycHM5=HfXisL6yog@mail.gmail.com>

On 28 June 2012 09:15, holger krekel <holger at merlinux.eu> wrote:
> /me does "import this" and sees: Although practicality beats purity ...
>
> I am still fine to consider e. g. the introduction of a pytest.current
> namespace. ?It could lead to make setup_X methods more powerful::

I think it would be nice to make setup_X methods more powerful by
giving them access to resources, but it's not a deal breaker.  And I'm
not a fan of pytest.current either for the same reasons you don't like
it.

But you didn't explain why inspecting the arguments like is done for
the hooks is not viable?  To me that would seem like a neat solution.
And I'm tempted to say not to bother if the only alternative is to use
someting pytest.current-like.  It's certainly no regression.


> ? ?import pytest
> ? ?def setup_module(): ?# pytest accepts it to keep nose compat
> ? ? ? ?db = pytest.current.modulenode.getresource("db")
>
> The "current" namespace could be set by the respective node setup
> methods. ?For classes it's the same idea::
>
> ? ?class TestClass:
> ? ? ? ?def setup_class(cls):
> ? ? ? ? ? ?cls.db = pytest.current.classnode.getresource("db")
>
> Due to the non-declarative nature of this approach, however, i don't
> see a way to rerun the testclass with multiple "db" instances.

I don't see how all other uses don't have these issues:

def pytest_funcarg__foo(item):
    item.getresource('db')

or

def factory_foo(name, node):
    pass
def facotry_bar(name, node):
    node.getresource('foo')
.register_resource_factory('foo', factory_foo)
.register_resource_factory('bar', factory_bar)

Don't these suffer the same problem?  Or am I missing someting.


Regards,
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org


From holger at merlinux.eu  Thu Jun 28 17:41:03 2012
From: holger at merlinux.eu (holger krekel)
Date: Thu, 28 Jun 2012 15:41:03 +0000
Subject: [py-dev] RFC: draft new resource management API (v1)
In-Reply-To: <CAAWk_DyvgOqzvbJX7F=a-aii5kPE+fPWgNycHM5=HfXisL6yog@mail.gmail.com>
References: <20120627125742.GO11942@merlinux.eu>
	<CAAWk_Dxk+KJvyB3pvtpxBFyQ3aK7pkqwJqeTSEcqnEYj7_V_9A@mail.gmail.com>
	<20120627183647.GR11942@merlinux.eu>
	<CAAWk_DwdZO_p8RBmqV-n30fcAO-Skc8=3ZCr1D3HJFWQe24gjQ@mail.gmail.com>
	<20120628081545.GT11942@merlinux.eu>
	<CAAWk_DyvgOqzvbJX7F=a-aii5kPE+fPWgNycHM5=HfXisL6yog@mail.gmail.com>
Message-ID: <20120628154102.GV11942@merlinux.eu>

On Thu, Jun 28, 2012 at 13:08 +0100, Floris Bruynooghe wrote:
> On 28 June 2012 09:15, holger krekel <holger at merlinux.eu> wrote:
> > /me does "import this" and sees: Although practicality beats purity ...
> >
> > I am still fine to consider e. g. the introduction of a pytest.current
> > namespace. ?It could lead to make setup_X methods more powerful::
> 
> I think it would be nice to make setup_X methods more powerful by
> giving them access to resources, but it's not a deal breaker.  And I'm
> not a fan of pytest.current either for the same reasons you don't like
> it.
> 
> But you didn't explain why inspecting the arguments like is done for
> the hooks is not viable?  To me that would seem like a neat solution.
> And I'm tempted to say not to bother if the only alternative is to use
> someting pytest.current-like.  It's certainly no regression.

It is in some sense logical to extend the funcarg-idea to setup-methods.
I used to think that the scoping is a problem, but given the new
node.register_factory/getresource() API it could be done somewhat
sanely.  It will remain a bit of a heuristic approach, though, because
setup_module/class/method have traditionally not required exact names -
for example, some people wrongly use:

    def setup_class(self):
        self.xyz = ...

Of course this works.  And I guess we could start funcarg/resource-requesting
based on all previously not possible arguments.  So

    def setup_class(xyz, tmpdir):
        xyz.tmpdir = tmpdir

would work because the first argument does not take part in discovery.
The tmpdir argument would lead to a classnode.getresource("tmpdir") call.
It wouldn't matter if tmpdir is created through a pytest_funcarg__tmpdir or a
register_factory() function.  Do you like this?

> > ? ?import pytest
> > ? ?def setup_module(): ?# pytest accepts it to keep nose compat
> > ? ? ? ?db = pytest.current.modulenode.getresource("db")
> >
> > The "current" namespace could be set by the respective node setup
> > methods. ?For classes it's the same idea::
> >
> > ? ?class TestClass:
> > ? ? ? ?def setup_class(cls):
> > ? ? ? ? ? ?cls.db = pytest.current.classnode.getresource("db")
> >
> > Due to the non-declarative nature of this approach, however, i don't
> > see a way to rerun the testclass with multiple "db" instances.
> 
> I don't see how all other uses don't have these issues:
> 
> def pytest_funcarg__foo(item):
>     item.getresource('db')
> 
> or
> 
> def factory_foo(name, node):
>     pass
> def facotry_bar(name, node):
>     node.getresource('foo')
> .register_resource_factory('foo', factory_foo)
> .register_resource_factory('bar', factory_bar)
> 
> Don't these suffer the same problem?  Or am I missing someting.

The latter would work::

    node.register_factory("foo", [fac1, fac2])
    
this makes it clear that there are two "foo" parameter values.

best,
holger

> Regards,
> Floris
> 
> 
> -- 
> Debian GNU/Linux -- The Power of Freedom
> www.debian.org | www.gnu.org | www.kernel.org
> 


From flub at devork.be  Fri Jun 29 09:41:28 2012
From: flub at devork.be (Floris Bruynooghe)
Date: Fri, 29 Jun 2012 08:41:28 +0100
Subject: [py-dev] RFC: draft new resource management API (v1)
In-Reply-To: <20120628154102.GV11942@merlinux.eu>
References: <20120627125742.GO11942@merlinux.eu>
	<CAAWk_Dxk+KJvyB3pvtpxBFyQ3aK7pkqwJqeTSEcqnEYj7_V_9A@mail.gmail.com>
	<20120627183647.GR11942@merlinux.eu>
	<CAAWk_DwdZO_p8RBmqV-n30fcAO-Skc8=3ZCr1D3HJFWQe24gjQ@mail.gmail.com>
	<20120628081545.GT11942@merlinux.eu>
	<CAAWk_DyvgOqzvbJX7F=a-aii5kPE+fPWgNycHM5=HfXisL6yog@mail.gmail.com>
	<20120628154102.GV11942@merlinux.eu>
Message-ID: <CAAWk_Dy6_ve=S5Wpcer=ogtZWUnx_ZusOHu_OwYa8kbR+N7YoA@mail.gmail.com>

On 28 June 2012 16:41, holger krekel <holger at merlinux.eu> wrote:
> It is in some sense logical to extend the funcarg-idea to setup-methods.
> I used to think that the scoping is a problem, but given the new
> node.register_factory/getresource() API it could be done somewhat
> sanely. ?It will remain a bit of a heuristic approach, though, because
> setup_module/class/method have traditionally not required exact names -
> for example, some people wrongly use:
>
> ? ?def setup_class(self):
> ? ? ? ?self.xyz = ...
>
> Of course this works. ?And I guess we could start funcarg/resource-requesting
> based on all previously not possible arguments. ?So
>
> ? ?def setup_class(xyz, tmpdir):
> ? ? ? ?xyz.tmpdir = tmpdir
>
> would work because the first argument does not take part in discovery.

I think it's fair enough to say that the first argument of setup_class
or setup_module and the first two arguments for setup_method should
always be ignored for funcarg discovery.  So you can only use funcargs
if you add more arguments.

> The tmpdir argument would lead to a classnode.getresource("tmpdir") call.
> It wouldn't matter if tmpdir is created through a pytest_funcarg__tmpdir or a
> register_factory() function. ?Do you like this?

Yes, that is nice enough way to get to funcargs/resources from inside setup_x

Regards,
Floris


From holger at merlinux.eu  Fri Jun 29 12:55:23 2012
From: holger at merlinux.eu (holger krekel)
Date: Fri, 29 Jun 2012 10:55:23 +0000
Subject: [py-dev] RFC: V2 of the new resource setup/parametrization
	facilities
Message-ID: <20120629105523.GW11942@merlinux.eu>

Hi all, particularly Floris and Carl,

i have finally arrived at the V2 resource-API draft based on the very valuable
feedback you gave to the first version.  The document implements a largely
changed approach, see the "Changes from V1 to V2" at the beginning, and
focuses on usage-level documentation instead of internal details.

I have also uploaded this doc as HTML which makes it a bit more colorful
to read, and also contains some cross-references:

    http://pytest.org/dev/resources.html

Please find the the source txt-file also attached for your
inline-commenting usage.  Before i target the actual (substantial)
refactoring, i'd actually be very grateful for some more of your time
and comments on this new version.

I believe that the new resource parametrization facilities are a major
step forward - they should allow test writers to much more seldomly having
to resort to pytest_* hooks, and make access and working with parametrized 
resources straight forward, irrespective of previous xUnit/pytest background.
Plugin writers, of course, may still use the hooks for good value.

best & thanks,
holger

-------------- next part --------------

V2: Creating and working with parametrized test resources
===============================================================

Abstract: pytest-2.X provides generalized scoping and parametrization
of resource setup.  It does so by introducing new scoping and parametrization
capabilities directly to to funcarg factories and by enhancing
xUnit-style setup_X methods to directly accept funcarg resources.
Moreover, new xUnit setup_directory() and setup_session() methods allow
fixture code (and resource usage) at previously unavailable scopes.
Pre-existing test suites and plugins written to work for previous pytest
versions shall run unmodified.

This V2 draft is based on incorporating feedback provided by Floris Bruynooghe, 
Carl Meyer and Ronny Pfannschmidt. It remains as draft documentation, pending 
further refinements and changes according to implementation or backward 
compatibility issues. The main changes to V1 are:

* changed approach: now based on improving ``pytest_funcarg__``
  factories and extending setup_X methods to directly accept
  funcarg resources, also including a new per-directory
  "setup_directory()" and setup_session() function for respectively
  scoped setup.
* the "funcarg" versus "resource" naming issue is disregarded in favour
  of keeping with "funcargs" and talking about "funcarg resources" 
  to ease a later possible renaming (whose value is questionable)
* The register_factory/getresource methods are moved to an
  implementation section for now, drawing a clear boundary between
  usage-level docs and impl-level ones.
* use "2.X" as the version for introduction (might be 2.3, else 2.4)

.. currentmodule:: _pytest


Shortcomings of the previous pytest_funcarg__ mechanism
---------------------------------------------------------

The previous funcarg mechanism calls a factory each time a
funcarg for a test function is requested.  If a factory wants
t re-use a resource across different scopes, it often used 
the ``request.cached_setup()`` helper to manage caching of 
resources.  Here is a basic example how we could implement 
a per-session Database object::

    # content of conftest.py 
    class Database:
        def __init__(self):
            print ("database instance created")
        def destroy(self):
            print ("database instance destroyed")

    def pytest_funcarg__db(request):
        return request.cached_setup(setup=DataBase, 
                                    teardown=lambda db: db.destroy,
                                    scope="session")

There are some problems with this approach:

1. Scoping resource creation is not straight forward, instead one must
   understand the intricate cached_setup() method mechanics.

2. parametrizing the "db" resource is not straight forward: 
   you need to apply a "parametrize" decorator or implement a
   :py:func:`~hookspec.pytest_generate_tests` hook 
   calling :py:func:`~python.Metafunc.parametrize` which
   performs parametrization at the places where the resource 
   is used.  Moreover, you need to modify the factory to use an 
   ``extrakey`` parameter containing ``request.param`` to the 
   :py:func:`~python.Request.cached_setup` call.

3. the current implementation is inefficient: it performs factory discovery
   each time a "db" argument is required.  This discovery wrongly happens at 
   setup-time.

4. there is no way how you can use funcarg factories, let alone 
   parametrization, when your tests use the xUnit setup_X approach.

5. there is no way to specify a per-directory scope for caching.

In the following sections, API extensions are presented to solve 
each of these problems. 


Direct scoping of funcarg factories
--------------------------------------------------------

Instead of calling cached_setup(), you can decorate your factory
to state its scope::

    @pytest.mark.factory_scope("session")
    def pytest_funcarg__db(request):
        # factory will only be invoked once per session - 
        db = DataBase()
        request.addfinalizer(db.destroy)  # destroy when session is finished
        return db

This factory implementation does not need to call ``cached_setup()`` anymore
because it will only be invoked once per session.  Moreover, the 
``request.addfinalizer()`` registers a finalizer according to the specified
factory scope on which this factory is operating.  With this new
scoping, the still existing ``cached_setup()`` should be much less used
but will remain for compatibility reasons and for the case where you
still want to have your factory get called on a per-item basis.


Direct parametrization of funcarg factories 
----------------------------------------------------------

Previously, funcarg factories could not directly cause parametrization.
You needed to specify a ``@parametrize`` or implement a ``pytest_generate_tests`` hook to perform parametrization, i.e. calling a test multiple times
with different value sets.  pytest-2.X introduces a decorator for use
on the factory itself::

    @pytest.mark.factory_parametrize(["mysql", "pg"])
    def pytest_funcarg__db(request):
        ...

Here the factory will be invoked twice (with the respective "mysql" 
and "pg" values set as ``request.param`` attributes) and and all of 
the tests requiring "db" will run twice as well.  The "mysql" and 
"pg" values will also be used for reporting the test-invocation variants.

This new way of directly parametrizing funcarg factories should
in many cases allow to use already written factories because effectively
``@factory_parametrize`` sets the same ``request.param`` that a 
:py:func:`~_pytest.python.Metafunc.parametrize()` call causes to be set.

Of course it's perfectly to combine parametrization and scoping::

    @pytest.mark.factory_parametrize(["mysql", "pg"])
    @pytest.mark.factory_scope("session")
    def pytest_funcarg__db(request):
        if request.param == "mysql":
            db = MySQL()
        elif request.param == "pg":
            db = PG()
        request.addfinalizer(db.destroy)  # destroy when session is finished
        return db

This would execute all tests requiring the per-session "db" resource twice,
receiving the values respectively created by the two invocations to the
``db`` factory.


Using funcarg resources in xUnit setup methods
------------------------------------------------------------

For a long time, pytest has recommended the usage of funcarg resource
factories as a primary means for managing resources in your test run.
It is a better approach than the jUnit-based approach in many cases, even 
more with the new pytest-2.X features, because the funcarg resource factory
provides a single place to determine scoping and parametrization.  Your tests 
do not need to encode setup/teardown details in every test file's 
setup_module/class/method.  

However, the jUnit methods originally introduced by pytest to Python,
remain popoular with nose and unittest-based test suites.  And in any
case, there are large existing test suites using this paradigm.  pytest-2.X
recognizes this fact and now offers direct integration with funcarg resources.  Here is a basic example for getting a per-module tmpdir::

    def setup_module(mod, tmpdir):
        mod.tmpdir = tmpdir

This will make pytest's funcarg resource mechanism to create a value of
"tmpdir" which can then be used through the module as a global.

Note that the new extension to setup_X methods also works in case a 
resource is parametrized. Let's consider an setup_class example using
our "db" resource::

    class TestClass:
        def setup_class(cls, db):
            cls.db = db
            # perform some extra things on db
            # so that test methods can work with it

With pytest-2.X the setup* methods will be discovered at collection-time,
allowing to seemlessly integrate this approach with parametrization.
Note again, that the setup_class itself does not itself need to 
be aware of the fact that "db" might be a mysql/PG database.
Note that if the specified resource is provided only as a per-testfunction
resource, collection will already report a ScopingMismatch error.

support for setup_session and setup_directory
------------------------------------------------------

pytest for a long time offered a pytest_configure and a pytest_sessionstart
hook which are often used to setup global resources.  This suffers from
several problems:

1. in distributed testing the master process would setup test resources
   that are never needed because it only co-ordinates the test run
   activities of the slave processes.  

2. if you only perform a collection (with "--collectonly") 
   resource-setup will still be executed.  

3. If a pytest_sessionstart is contained in some subdirectories
   conftest.py file, it will not be called.  This stems from the
   fact that this hook is actually used for reporting, in particular
   the test-header with platform/custom information.

4. there is no direct way how you can restrict setup to a directory scope.

It follows that these hooks are not a good place to implement session
or directory-based setup.  pytest-2.X offers new "setup_X" methods, accepting
funcargs, which you can put into conftest.py or plugins files::
    
    # content of conftest.py
    def setup_session(db):
        ... use db resource or do some initial global init stuff
        ... before any test is run.
        
    def setup_directory(db):
        # called when the first test in the directory tree is about to execute

For obvious reasons, the used funcarg-resources be provided on a per-directory
or per-session basis.

the "directory" caching scope
--------------------------------------------

All API accepting a scope (:py:func:`cached_setup()`  nd
@mark.factory_scope currently) now also accepts a "directory"
specification.  This allows to restrict/cache resource values on a
per-directory level.

funcarg and setup discovery now happens at collection time
---------------------------------------------------------------------

pytest-2.X takes care to discover resource factories and setup_X methods
at collection time.  This is more efficient especially for large test suites. 
Moreover, a call to "py.test --collectonly" should be able to show
a lot of setup-information and thus presents a nice method to get an
overview of resource management in your project.

Implementation level 
===================================================================

To implement the above new features, pytest-2.X grows some new hooks and
methods.  At the time of writing V2 and without actually implementing
it, it is not clear how much of this new internal API will also be
exposed and advertised e. g. for plugin writers. 


the "request" object incorporates scope-specific behaviour
------------------------------------------------------------------

funcarg factories receive a request object to help with implementing
finalization and inspection of the requesting-context.  If there is
no scoping is in effect, nothing much will change of the API behaviour.
However, with scoping the request object represents the according context.
Let's consider this example::

    @pytest.mark.factory_scope("class")
    def pytest_funcarg__db(request):
        # ...
        request.getfuncargvalue(...)
        #
        request.addfinalizer(db)

Due to the class-scope, the request object will:

- provide a ``None`` value for the ``request.function`` attribute. 
- default to per-class finalization with the addfinalizer() call.
- raise a ScopeMismatchError if a more broadly scoped factory
  wants to use a more tighly scoped factory (e.g. per-function)

In fact, the request object is likely going to provide a "node" 
attribute, denoting the current collection node on which it internally
operates.  (Prior to pytest-2.3 there already was an internal
_pyfuncitem).

As these are rather intuitive extensions, not much friction is expected 
for test/plugin writers using the new scoping and parametrization mechanism. 
It's, however, a serious internal effort to reorganize the pytest 
implementation.


node.register_factory/getresource() methods
--------------------------------------------------------

In order to implement factory- and setup-method discovery at
collection time, a new node API will be introduced to allow
for factory registration and a getresource() call to obtain
created values.  The exact details of this API remain subject
to experimentation. The basic idea is to introduce two new
methods to the Session class which is already available on all nodes
through the ``node.session`` attribute::

    class Session:
        def register_resource_factory(self, name, factory_or_list, scope):
            """ register a resource factory for the given name.

            :param name: Name of the resource.
            :factory_or_list: a function or a list of functions creating
                              one or multiple resource values.
            :param scope: a node instance. The factory will be only visisble
                          available for all descendant nodes.
                          specify the "session" instance for global availability
            """

        def getresource(self, name, node):
            """ get a named resource for the give node.

            This method looks up a matching funcarg resource factory 
            and calls it.
            """

.. todo::

    XXX While this new API (or some variant of it) may suffices to implement
    all of the described new usage-level features, it remains unclear how the
    existing "@parametrize" or "metafunc.parametrize()" calls will map to it.
    These parametrize-approaches tie resource parametrization to the 
    function/funcargs-usage rather than to the factories. 


.. todo::

    Will this hook be called  


From flub at devork.be  Sat Jun 30 02:23:04 2012
From: flub at devork.be (Floris Bruynooghe)
Date: Sat, 30 Jun 2012 01:23:04 +0100
Subject: [py-dev] RFC: V2 of the new resource setup/parametrization
 facilities
In-Reply-To: <20120629105523.GW11942@merlinux.eu>
References: <20120629105523.GW11942@merlinux.eu>
Message-ID: <20120630002304.GB26143@laurie.devork.be>

Hello Holger,

On Fri, Jun 29, 2012 at 10:55:23AM +0000, holger krekel wrote:
[...]
> Direct scoping of funcarg factories
[...]
> Direct parametrization of funcarg factories 

These two seem fine, but personally I would prefer them to use the
same marker with keyword-only arguments::

   @pytest.mark.factory(scope='session', parametrize=['mysql', 'pg'])
   def pytest_funcarg__db(request):
       ...

This seems like a more natural API which collects the different
functions, certainly when using both for one funcarg.


However it bothers me that funcargs now have two types of scope: an
implied scope derived from where it is defined and which defines their
visibility (e.g. only inside a class, module, directory).  And then
this new scope which is essentially a caching/teardown scope.  The
fact that the ScopeMismatch exception is needed is a result of this I
think.

The previous resource/funcarg split avoided this confusion.


Lastly, when do scoped funcarg resources get invoked?  Only at the
time a test function requests it or always at the time when the scope
is entered?


> support for setup_session and setup_directory
> ------------------------------------------------------
[...]
>     # content of conftest.py
>     def setup_session(db):
>         ... use db resource or do some initial global init stuff
>         ... before any test is run.
>         
>     def setup_directory(db):
>         # called when the first test in the directory tree is about
> to execute

I think the naming of these functions break the py.test convention,
normally the only functions picked up from conftest.py start with
pytest_.  I can certainly imagine a conftest.py or plugin already
having a setup_session function.  These are new functions and do not
provide a compatibility API with other testing frameworks, so I think
they would be better named pytest_setup_session and
pytest_setup_directory.

It also feels slightly weird that they do not get their respective
Node passed in.  This is a little inconsistent with the current
setup_X method which all take a module, class or method argument.  I
can't think of an immediate use for it as you can push out pretty much
everything you need to do to a properly scoped funcarg resource.  And
following that reasoning the setup function would end up having no
body at all, which also seems weird.



> Implementation level 
> ===================================================================
[...]
> the "request" object incorporates scope-specific behaviour
> ------------------------------------------------------------------
[...]
> In fact, the request object is likely going to provide a "node" 
> attribute, denoting the current collection node on which it internally
> operates.  (Prior to pytest-2.3 there already was an internal
> _pyfuncitem).

Does this mean you will revert the currently checked-in behaviour
where a Node is actually a Request subclass and is the object passed
to the funcarg resource factories?



Hope this was helpful feedback,
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org


From holger at merlinux.eu  Sat Jun 30 10:08:41 2012
From: holger at merlinux.eu (holger krekel)
Date: Sat, 30 Jun 2012 08:08:41 +0000
Subject: [py-dev] RFC: V2 of the new resource setup/parametrization
 facilities
In-Reply-To: <20120630002304.GB26143@laurie.devork.be>
References: <20120629105523.GW11942@merlinux.eu>
	<20120630002304.GB26143@laurie.devork.be>
Message-ID: <20120630080839.GY11942@merlinux.eu>

Hi Floris,

some preliminary notes, i'll probably think some more about your feedback ...

On Sat, Jun 30, 2012 at 01:23 +0100, Floris Bruynooghe wrote:
> Hello Holger,
> 
> On Fri, Jun 29, 2012 at 10:55:23AM +0000, holger krekel wrote:
> [...]
> > Direct scoping of funcarg factories
> [...]
> > Direct parametrization of funcarg factories 
> 
> These two seem fine, but personally I would prefer them to use the
> same marker with keyword-only arguments::
> 
>    @pytest.mark.factory(scope='session', parametrize=['mysql', 'pg'])
>    def pytest_funcarg__db(request):
>        ...
> 
> This seems like a more natural API which collects the different
> functions, certainly when using both for one funcarg.

I'll consider it, probably under the name of "factoryattr" or so. 

> However it bothers me that funcargs now have two types of scope: an
> implied scope derived from where it is defined and which defines their
> visibility (e.g. only inside a class, module, directory).  And then
> this new scope which is essentially a caching/teardown scope.  The
> fact that the ScopeMismatch exception is needed is a result of this I
> think.

previously, the scope-mismatch could happen as well and go unnoticed::

    def pytest_funcarg__Y(request):
        return request.function.__name__

    def pytest_funcarg__X(request):
        def setup():
            return request.getfuncargvalue("Y")
        return request.cached_setup(setup, scope="session")

The result will depend on which test function is first requested.
In the future, we might want to try raise a ScopeMismatchError here
as well.

> The previous resource/funcarg split avoided this confusion.

a) What about just naming it "cachescope"?
b) i moved register_factory/getresource to implementation details
   not the least because Carl Meyer as a relatively recent pytest user
   expressed his expectation of a consistent pytest_funcarg__ factory
   story - and if we are going to anyway have to support the existing ones, 
   i'd now like to focus on extending it and only go for a usage-level visible
   paradigm change if it's really needed. Does this make general
   sense to you?
 
> Lastly, when do scoped funcarg resources get invoked?  Only at the
> time a test function requests it or always at the time when the scope
> is entered?

factories are invoked when a test function or one of its involved setup 
methods needs it.  A scope is only "entered" if there is a test to be executed
within it. Does this clarify?

> > support for setup_session and setup_directory
> > ------------------------------------------------------
> [...]
> >     # content of conftest.py
> >     def setup_session(db):
> >         ... use db resource or do some initial global init stuff
> >         ... before any test is run.
> >         
> >     def setup_directory(db):
> >         # called when the first test in the directory tree is about
> > to execute
> 
> I think the naming of these functions break the py.test convention,
> normally the only functions picked up from conftest.py start with
> pytest_.  I can certainly imagine a conftest.py or plugin already
> having a setup_session function.  These are new functions and do not
> provide a compatibility API with other testing frameworks, so I think
> they would be better named pytest_setup_session and
> pytest_setup_directory.

I think using pytest_* hooks also has consistency problems:

* hooks cannot usually receive arbitrary funcargs
* xUnit-style consistency: consider explaining the new functions
  to someone only knowing setup_module/ class etc.

I am wondering, however, do we even need a "setup_session"? setup_directory
should usually be enough, i guess, and it's more unlikely people used
that name already (and we could warn about setup_session in 2.X to
reserve introducing it in 2.X+1).

And what what about putting setup_directory into an __init__.py file?
I don't really like requiring __init__ files, but am fine to go with it if
you and others prefer that.  I would guess, that using the already 
directory-scoped conftest.py file feels fine to someone coming new to pytest.

> It also feels slightly weird that they do not get their respective
> Node passed in.  This is a little inconsistent with the current
> setup_X method which all take a module, class or method argument.  I
> can't think of an immediate use for it as you can push out pretty much
> everything you need to do to a properly scoped funcarg resource.  

We can certainly add modulenode, classnode etc. to the respective
setup-methods because they participate in the funcarg-protocol 
(which allows accepting less parameters than are available).

> And following that reasoning the setup function would end up having no
> body at all, which also seems weird.

If a setup-function has no body, then tests could just require it themselves
and that'd be enough.  If there is a need, we could introduce a marker for 
requiring funcarg-resources such that tests do not need to require it 
in their signature.

> > Implementation level 
> > ===================================================================
> [...]
> > the "request" object incorporates scope-specific behaviour
> > ------------------------------------------------------------------
> [...]
> > In fact, the request object is likely going to provide a "node" 
> > attribute, denoting the current collection node on which it internally
> > operates.  (Prior to pytest-2.3 there already was an internal
> > _pyfuncitem).
> 
> Does this mean you will revert the currently checked-in behaviour
> where a Node is actually a Request subclass and is the object passed
> to the funcarg resource factories?

Yes, probably.  Request-state basically consists of "(requested_funcargname,
node)" info currently.  There probably would be a request.node attribute 
which allows access to node information if needed.

> Hope this was helpful feedback,

Yes, certainly.  Hope i understood it correctly and my reply made 
sense so far.  

best,

holger


> Floris
> 
> 
> -- 
> Debian GNU/Linux -- The Power of Freedom
> www.debian.org | www.gnu.org | www.kernel.org
> 


From flub at devork.be  Sat Jun 30 13:26:05 2012
From: flub at devork.be (Floris Bruynooghe)
Date: Sat, 30 Jun 2012 12:26:05 +0100
Subject: [py-dev] RFC: V2 of the new resource setup/parametrization
 facilities
In-Reply-To: <20120630080839.GY11942@merlinux.eu>
References: <20120629105523.GW11942@merlinux.eu>
	<20120630002304.GB26143@laurie.devork.be>
	<20120630080839.GY11942@merlinux.eu>
Message-ID: <20120630112605.GA32749@laurie.devork.be>

On Sat, Jun 30, 2012 at 08:08:41AM +0000, holger krekel wrote:
> On Sat, Jun 30, 2012 at 01:23 +0100, Floris Bruynooghe wrote:
> > On Fri, Jun 29, 2012 at 10:55:23AM +0000, holger krekel wrote:
> previously, the scope-mismatch could happen as well and go unnoticed::
> 
>     def pytest_funcarg__Y(request):
>         return request.function.__name__
> 
>     def pytest_funcarg__X(request):
>         def setup():
>             return request.getfuncargvalue("Y")
>         return request.cached_setup(setup, scope="session")
> 
> The result will depend on which test function is first requested.
> In the future, we might want to try raise a ScopeMismatchError here
> as well.

Oh, never noticed this.  That's an improvement then.

> > The previous resource/funcarg split avoided this confusion.
> 
> a) What about just naming it "cachescope"?

Maybe.  I wouldn't take my word for it that just "scope" is not
sufficient, see what other people say.  I'd probably get annoyed at
the extra typing for cachescope after a while, maybe even
@pytest.mark.factory(cache="session") is an option?  It would avoid
having two things called "scope".


> b) i moved register_factory/getresource to implementation details
>    not the least because Carl Meyer as a relatively recent pytest user
>    expressed his expectation of a consistent pytest_funcarg__ factory
>    story - and if we are going to anyway have to support the existing ones, 
>    i'd now like to focus on extending it and only go for a usage-level visible
>    paradigm change if it's really needed. Does this make general
>    sense to you?

Yes this does make sense, in general I do like this approach.


> > Lastly, when do scoped funcarg resources get invoked?  Only at the
> > time a test function requests it or always at the time when the scope
> > is entered?
> 
> factories are invoked when a test function or one of its involved setup 
> methods needs it.  A scope is only "entered" if there is a test to be executed
> within it. Does this clarify?

It does.

> > > support for setup_session and setup_directory
> > > ------------------------------------------------------
> > [...]
> > >     # content of conftest.py
> > >     def setup_session(db):
> > >         ... use db resource or do some initial global init stuff
> > >         ... before any test is run.
> > >         
> > >     def setup_directory(db):
> > >         # called when the first test in the directory tree is about
> > > to execute
> > 
> > I think the naming of these functions break the py.test convention,
> > normally the only functions picked up from conftest.py start with
> > pytest_.  I can certainly imagine a conftest.py or plugin already
> > having a setup_session function.  These are new functions and do not
> > provide a compatibility API with other testing frameworks, so I think
> > they would be better named pytest_setup_session and
> > pytest_setup_directory.
> 
> I think using pytest_* hooks also has consistency problems:
> 
> * hooks cannot usually receive arbitrary funcargs

This is why a signature with a request/node for these might be better::

   def pytest_setup_session(session):
       session.getresource('db')  # or .getfuncargvalue()?
       ...

> * xUnit-style consistency: consider explaining the new functions
>   to someone only knowing setup_module/ class etc.

As I tried to say before, they do not come for xUnit so I don't think
this is too important.  I think the consistency inside conftest.py is
more important.


> I am wondering, however, do we even need a "setup_session"? setup_directory
> should usually be enough, i guess, and it's more unlikely people used
> that name already (and we could warn about setup_session in 2.X to
> reserve introducing it in 2.X+1).

Maybe not, but if you don't provide setup_session (or
pytest_setup_session) then pytest_sessionstart will be used again
when someone thinks of a reason to use it.  And that's what you wanted
to avoid.

> And what what about putting setup_directory into an __init__.py file?
> I don't really like requiring __init__ files, but am fine to go with it if
> you and others prefer that.  I would guess, that using the already 
> directory-scoped conftest.py file feels fine to someone coming new to pytest.

I agree, requiring __init__.py is worse then just putting it in
conftest.py.  I think it would be best if it fits inside conftest.py.


> If a setup-function has no body, then tests could just require it themselves
> and that'd be enough.  If there is a need, we could introduce a marker for 
> requiring funcarg-resources such that tests do not need to require it 
> in their signature.

I'm not sure what that would save, either the test function must
request the resource or must be marked to need the resource.  If
anything the second takes more work.

As an aside however, one of my usecases for merged request/item
objects was so I could put setup in a session-wide scoped funcarg but
also automatically request this funcarg based on a mark::

   def pytest_runtest_setup(item):
       if 'needsdb' in item.keywords:  # or a more explicit API
          item.getresource('db')

I understand that this will still be possible via::

   def pytest_runtest_setup(item):
       if 'needsdb' in item.keywords:
           item.session.getresource('db')

Or something similar to that.


Regards,
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org