From andreas at pelme.se Wed May 2 11:46:10 2012 From: andreas at pelme.se (Andreas Pelme) Date: Wed, 2 May 2012 11:46:10 +0200 Subject: [py-dev] Change behavior in pytest_runtest_setup hooks based on available funcargs Message-ID: <536400C4C0AA489C8FFCD92D19A7CA42@pelme.se> Hi, I am trying to implement a live_server funcarg, which will manage a Django LiveServerThread, passing in the live server URL to the test function. pytest_runtest_setup is used to start a database transaction, and then pytest_runtest_teardown will rollback the transaction after the test run - this is the standard way Django's TestCase works. I also have a pytest mark: transaction_test_case, when used, instead of running the test in a transaction and rolling back at the end, the database is flushed (this is equivalent to Django's TransactionTestCase). When running tests with the live_server funcarg, the live server is running in another thread, and the data needs to be committed to the database, in order for the live server to see the data. So, transaction_test_case behavior should always be used when the live_server funcarg is used. The relevant code is available here: https://gist.github.com/9a090afd645026b34bfb I would like to change behavior in my pytest_runtest_setup hook, when a certain funcarg is used. The problem is that funcargs are not available in item.keywords in pytest_runtest_setup (since the pytest_funcarg__*() functions have not yet been called). When pytest_runtest_teardown is called however, item.keywords are available, and the database can be teared down in the right way. I am using request.applymarker(transaction_test_case) in pytest_funcarg__live_server(), but as stated above, it won't be visible in pytest_runtest_setup. It would be nice to know *which* funcargs are present in pytest_runtest_setup, even though they are not yet initialized and have gotten their values. One solution would be to manually mark all live_server test-cases with transaction_test_case, but that is a bit too much typing for my taste: :) @pytest.mark.transaction_test_case def test_foo(live_server): pass Is there any way to see what funcargs are specified from within pytest_runtest_setup? If not, is there another way I should approach this problem? Or should I just give up and decorate all live server tests with @pytest.mark.transaction_test_case ? Best regards/Andreas (I am trying to make a complete pytest-django package, I have forked an old package, put it on PyPI and added some docs:https://github.com/pelme/pytest_django , I will post an announcement here later when it has seen some more progress!) From holger at merlinux.eu Wed May 2 15:45:49 2012 From: holger at merlinux.eu (holger krekel) Date: Wed, 2 May 2012 13:45:49 +0000 Subject: [py-dev] Change behavior in pytest_runtest_setup hooks based on available funcargs In-Reply-To: <536400C4C0AA489C8FFCD92D19A7CA42@pelme.se> References: <536400C4C0AA489C8FFCD92D19A7CA42@pelme.se> Message-ID: <20120502134549.GM10174@merlinux.eu> Hi Andreas, thanks for your mail - i am currently still on travel so haven't digested all details yet. However, I'd like to let you know already that we have a plan to unify (function) Item and FuncargRequest interfaces. This should make it easy to access funcargs from pytest_runtest_setup because 'item' would carry the neccessary API. Maybe there is an intermediate solution for your use case, not sure. If also Ronny or others don't have another idea it would be great if you opened an issue on making funcargs available in pytest_runtest_setup. best & thanks, holger On Wed, May 02, 2012 at 11:46 +0200, Andreas Pelme wrote: > Hi, > > I am trying to implement a live_server funcarg, which will manage a Django LiveServerThread, passing in the live server URL to the test function. > > pytest_runtest_setup is used to start a database transaction, and then pytest_runtest_teardown will rollback the transaction after the test run - this is the standard way Django's TestCase works. > > I also have a pytest mark: transaction_test_case, when used, instead of running the test in a transaction and rolling back at the end, the database is flushed (this is equivalent to Django's TransactionTestCase). > > When running tests with the live_server funcarg, the live server is running in another thread, and the data needs to be committed to the database, in order for the live server to see the data. So, transaction_test_case behavior should always be used when the live_server funcarg is used. > > The relevant code is available here: https://gist.github.com/9a090afd645026b34bfb > > I would like to change behavior in my pytest_runtest_setup hook, when a certain funcarg is used. The problem is that funcargs are not available in item.keywords in pytest_runtest_setup (since the pytest_funcarg__*() functions have not yet been called). When pytest_runtest_teardown is called however, item.keywords are available, and the database can be teared down in the right way. > > I am using request.applymarker(transaction_test_case) in pytest_funcarg__live_server(), but as stated above, it won't be visible in pytest_runtest_setup. It would be nice to know *which* funcargs are present in pytest_runtest_setup, even though they are not yet initialized and have gotten their values. > > One solution would be to manually mark all live_server test-cases with transaction_test_case, but that is a bit too much typing for my taste: :) > > @pytest.mark.transaction_test_case > def test_foo(live_server): > pass > > Is there any way to see what funcargs are specified from within pytest_runtest_setup? If not, is there another way I should approach this problem? Or should I just give up and decorate all live server tests with @pytest.mark.transaction_test_case ? > > Best regards/Andreas > > (I am trying to make a complete pytest-django package, I have forked an old package, put it on PyPI and added some docs:https://github.com/pelme/pytest_django , I will post an announcement here later when it has seen some more progress!) > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > From andreas at pelme.se Wed May 2 16:26:58 2012 From: andreas at pelme.se (Andreas Pelme) Date: Wed, 2 May 2012 16:26:58 +0200 Subject: [py-dev] Change behavior in pytest_runtest_setup hooks based on available funcargs In-Reply-To: <20120502134549.GM10174@merlinux.eu> References: <536400C4C0AA489C8FFCD92D19A7CA42@pelme.se> <20120502134549.GM10174@merlinux.eu> Message-ID: On Wednesday 2 May 2012 at 15:45, holger krekel wrote: > Hi Andreas, > > thanks for your mail - i am currently still on travel so haven't > digested all details yet. However, I'd like to let you know already that > we have a plan to unify (function) Item and FuncargRequest interfaces. > This should make it easy to access funcargs from pytest_runtest_setup > because 'item' would carry the neccessary API. Maybe there is an > intermediate solution for your use case, not sure. > > If also Ronny or others don't have another idea it would be great if > you opened an issue on making funcargs available in pytest_runtest_setup. > > best & thanks, > holger Holger, Thanks for your fast reply. :) I opened an issue: https://bitbucket.org/hpk42/pytest/issue/139/make-it-possible-to-access-funcargs-info Are there more info on the unify plan available somewhere? Best regards/Andreas From holger at merlinux.eu Thu May 3 03:09:15 2012 From: holger at merlinux.eu (holger krekel) Date: Thu, 3 May 2012 01:09:15 +0000 Subject: [py-dev] Change behavior in pytest_runtest_setup hooks based on available funcargs In-Reply-To: References: <536400C4C0AA489C8FFCD92D19A7CA42@pelme.se> <20120502134549.GM10174@merlinux.eu> Message-ID: <20120503010915.GN10174@merlinux.eu> Hi Andreas, On Wed, May 02, 2012 at 16:26 +0200, Andreas Pelme wrote: > On Wednesday 2 May 2012 at 15:45, holger krekel wrote: > > > Hi Andreas, > > > > thanks for your mail - i am currently still on travel so haven't > > digested all details yet. However, I'd like to let you know already that > > we have a plan to unify (function) Item and FuncargRequest interfaces. > > This should make it easy to access funcargs from pytest_runtest_setup > > because 'item' would carry the neccessary API. Maybe there is an > > intermediate solution for your use case, not sure. > > > > If also Ronny or others don't have another idea it would be great if > > you opened an issue on making funcargs available in pytest_runtest_setup. > > > > best & thanks, > > holger > > > Holger, > > Thanks for your fast reply. :) you are welcome! If you have any other issues or questions related to the pytest-django plugin i am happy to help. > I opened an issue: https://bitbucket.org/hpk42/pytest/issue/139/make-it-possible-to-access-funcargs-info Thanks. > Are there more info on the unify plan available somewhere? Apart from some IRC chats with Ronny, no ... he played with implementing it in some repository IIRC. The basic idea is simple. Virtually all API of FuncargRequest moves to the Item and FuncargRequest ceases to exist as a separate concept. Existing funcarg factories should continue to work of course. FWIW if somebody else wants to try i am fine to review. I think it's actually a fun change because it simplifies things and opens some new possibilities like introducing a generic "setup_item" function which could do all that current setup_class/module/function can do, it would have access to funcarg resources etc. and issues like https://bitbucket.org/hpk42/pytest/issue/137/expose-an-addfinalizer-to-add-callable would be solved as well. best, holger > Best regards/Andreas > > From mantihor at gmail.com Thu May 3 03:18:11 2012 From: mantihor at gmail.com (Bogdan Opanchuk) Date: Thu, 3 May 2012 11:18:11 +1000 Subject: [py-dev] Performance tests with py.test In-Reply-To: <20120401022159.GZ26028@merlinux.eu> References: <20120401022159.GZ26028@merlinux.eu> Message-ID: Hi Holger, 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 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(): # # return 1.0 @pytest.mark.perf('GFLOPS') def test_fft(): # # 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. > 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 - 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) 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. ----- 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 ----- From erik.tollerud at gmail.com Thu May 17 08:31:02 2012 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Wed, 16 May 2012 23:31:02 -0700 Subject: [py-dev] Pytest 2.2.4 release timeframe? Message-ID: Hello, I was just curious if there's any rough timeline/plan for a 2.2.4 release of pytest? I'm particularly interested in the fix for the pastebin option being in a released version, as we use this in our test reports in a project I work on. We can, of course, use the latest developer version, but it seems better practice to include a released version we bundle in our package... -- Erik Tollerud From holger at merlinux.eu Thu May 17 08:51:49 2012 From: holger at merlinux.eu (holger krekel) Date: Thu, 17 May 2012 06:51:49 +0000 Subject: [py-dev] Pytest 2.2.4 release timeframe? In-Reply-To: References: Message-ID: <20120517065149.GE10174@merlinux.eu> Hi Erik, On Wed, May 16, 2012 at 23:31 -0700, Erik Tollerud wrote: > I was just curious if there's any rough timeline/plan for a 2.2.4 > release of pytest? I'm particularly interested in the fix for the pastebin > option being in a released version, as we use this in our test reports > in a project I work on. We can, of course, use the latest developer > version, but it seems better practice to include a released version we > bundle in our package... sure. I think it makes sense to do a quick release one of these days. There are some pending changes but they can wait for another release. I don't have much time this week. I just packaged py-1.4.8 and pytest-2.4.4 to http://pypi.testrun.org and welcome an outside verification via pip install -i http://pypi.testrun.org -U pytest best, holger From erik.tollerud at gmail.com Sat May 19 08:31:37 2012 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Fri, 18 May 2012 22:31:37 -0800 Subject: [py-dev] Pytest 2.2.4 release timeframe? In-Reply-To: <20120517065149.GE10174@merlinux.eu> References: <20120517065149.GE10174@merlinux.eu> Message-ID: Hi Holger, I just ran the pip command, and it seemed to work without any problem. One tiny cosmetic item I noticed: If I do "py.test --help" I see the pastebin option as: "--pastebin=mode send failed|all info to Pocoo pastebin service." This is not quite correct because it's now bpaste.net that gets the result of the paste rather than the Pocoo pastebin. It works just fine, though - it's only the command-line script help that's incorrect. Thanks! On Wed, May 16, 2012 at 11:51 PM, holger krekel wrote: > Hi Erik, > > On Wed, May 16, 2012 at 23:31 -0700, Erik Tollerud wrote: >> I was just curious if there's any rough timeline/plan for a 2.2.4 >> release of pytest? I'm particularly interested in the fix for the pastebin >> option being in a released version, as we use this in our test reports >> in a project I work on. ?We can, of course, use the latest developer >> version, but it seems better practice to include a released version we >> bundle in our package... > > sure. ?I think it makes sense to do a quick release one of these days. > There are some pending changes but they can wait for another release. > I don't have much time this week. > > I just packaged py-1.4.8 and pytest-2.4.4 to http://pypi.testrun.org and > welcome an outside verification via > > ? ?pip install -i http://pypi.testrun.org -U pytest > > best, > holger -- Erik Tollerud From holger at merlinux.eu Tue May 22 18:31:44 2012 From: holger at merlinux.eu (holger krekel) Date: Tue, 22 May 2012 16:31:44 +0000 Subject: [py-dev] pytest-2.2.4 - bugfixes and better junitxml/unittest/python3 compat Message-ID: <20120522163144.GT10174@merlinux.eu> pytest-2.2.4: bug fixes, better junitxml/unittest/python3 compat =========================================================================== pytest-2.2.4 is a minor backward-compatible release of the versatile py.test testing tool. It contains bug fixes and a few refinements to junitxml reporting, better unittest- and python3 compatibility. For general information see here: http://pytest.org/ To install or upgrade pytest: pip install -U pytest # or easy_install -U pytest Special thanks for helping on this release to Ronny Pfannschmidt and Benjamin Peterson and the contributors of issues. best, holger krekel Changes between 2.2.3 and 2.2.4 ----------------------------------- - fix error message for rewritten assertions involving the % operator - fix issue 126: correctly match all invalid xml characters for junitxml binary escape - fix issue with unittest: now @unittest.expectedFailure markers should be processed correctly (you can also use @pytest.mark markers) - document integration with the extended distribute/setuptools test commands - fix issue 140: propperly get the real functions of bound classmethods for setup/teardown_class - fix issue #141: switch from the deceased paste.pocoo.org to bpaste.net - fix issue #143: call unconfigure/sessionfinish always when configure/sessionstart where called - fix issue #144: better mangle test ids to junitxml classnames - upgrade distribute_setup.py to 0.6.27 From holger at merlinux.eu Tue May 29 16:13:51 2012 From: holger at merlinux.eu (holger krekel) Date: Tue, 29 May 2012 14:13:51 +0000 Subject: [py-dev] pytest documents with Japanese translation In-Reply-To: References: <20120420034520.GG10174@merlinux.eu> Message-ID: <20120529141351.GE10174@merlinux.eu> 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 > 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 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 tetsuya.morimoto at gmail.com Tue May 29 17:07:52 2012 From: tetsuya.morimoto at gmail.com (Tetsuya Morimoto) Date: Wed, 30 May 2012 00:07:52 +0900 Subject: [py-dev] pytest documents with Japanese translation In-Reply-To: <20120529141351.GE10174@merlinux.eu> References: <20120420034520.GG10174@merlinux.eu> <20120529141351.GE10174@merlinux.eu> Message-ID: 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 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 >> ? ? 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 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