In the effort to port the component architecture to Python 3, some progress has been done. I think zope.interface and zope.exception is ready for some serious testing and zope.event is so trivial it doesn't need any testing. :) Time had therefore come to zope.testing. Why zope.testing? Because most components in zope.* uses zc.buildout, and zc.buildouts tests uses zope.testing. But of course we here have a bootstrapping problem, zope.testing of course also uses buildout. In zope.interface and zope.exception I fixed this by adding a test_suite parameter to setup(), so that the tests can be run with "python setup.py test". However, with zope.testing this doesn't work, for some reason. Many tests fail when you run the testing through setup.py, even though they work when run with a bin/test generated by setuptools. I'm stumped as to why this is, the changes are very strange, such as two temporary files being created in the buildout case, but only one in the setuptoold case. Very strange. Any insight into breaking this catch 22 is welcome, so we can port zope.testing to Python 3, and then get on to zc.buildout and then zope.component, and then the rest should be (in comparison) easy (although a lot of work). -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
* Lennart Regebro <lregebro@jarn.com> [2009-12-06 21:14]:
Time had therefore come to zope.testing. Why zope.testing? Because most components in zope.* uses zc.buildout, and zc.buildouts tests uses zope.testing. But of course we here have a bootstrapping problem, zope.testing of course also uses buildout.
When I worked on py3 stuff on the DZUG sprint in September, we broke out of that catch-22 by porting zope.testing first, and running its test using <http://pypi.python.org/pypi/discover>, patched[1] to pick up tests via the test_suite() methods. That way we could run the tests of zope.testing under py3 without needing zope.testing itself or zc.buildout to do so, so porting zope.testing could be tackled. Our work from then is on the regebro-python3 branch (which might be familiar ;-). I don't quite remember how far we've come. I *think* most of the porting work is done and we were last working on integrating Distribute/2to3 into the setup.py, but got hung up on the Distribute side of things. Wolfgang [1] @@ -54,9 +54,12 @@ if isinstance(obj, type) and issubclass(obj, unittest.TestCase): tests.append(self.loadTestsFromTestCase(obj)) - load_tests = getattr(module, 'load_tests', None) + load_tests = getattr(module, 'test_suite', None) if use_load_tests and load_tests is not None: - return load_tests(self, tests, None) + tests = load_tests() + if not tests: + return lambda x: None + return tests return self.suiteClass(tests)
On Mon, Dec 7, 2009 at 08:27, Wolfgang Schnerring <ws@gocept.com> wrote:
When I worked on py3 stuff on the DZUG sprint in September, we broke out of that catch-22 by porting zope.testing first, and running its test using <http://pypi.python.org/pypi/discover>, patched[1] to pick up tests via the test_suite() methods. That way we could run the tests of zope.testing under py3 without needing zope.testing itself or zc.buildout to do so, so porting zope.testing could be tackled.
OK, I'll try that, thanks. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On Mon, Dec 7, 2009 at 08:27, Wolfgang Schnerring <ws@gocept.com> wrote:
When I worked on py3 stuff on the DZUG sprint in September, we broke out of that catch-22 by porting zope.testing first, and running its test using <http://pypi.python.org/pypi/discover>, patched[1] to pick up tests via the test_suite() methods. That way we could run the tests of zope.testing under py3 without needing zope.testing itself or zc.buildout to do so, so porting zope.testing could be tackled.
That doesn't seem to work. If I use discover withing setup.py, I get the same problems as using the standard setuptools testrunner. If I have a custom script that I run to run the tests, the tests seem to get stuck in some sort of infinite regression and never end. It's really strange that running tests with setuptools fails. I think the best way forward is to try to figure out why, but I have no idea when or if I'm able to do that. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On Mon, Dec 7, 2009 at 15:46, Lennart Regebro <regebro@gmail.com> wrote:
That doesn't seem to work. If I use discover withing setup.py, I get the same problems as using the standard setuptools testrunner. If I have a custom script that I run to run the tests, the tests seem to get stuck in some sort of infinite regression and never end.
It's really strange that running tests with setuptools fails. I think the best way forward is to try to figure out why, but I have no idea when or if I'm able to do that.
The problem here is that the tests for the test runner assumes that the tests are run via the test script created by the buildout, and must call that script to test itself. This needs to be changed, somehow. I'll think about it, and see if I can come up with a solution. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
FYI: I solved it. As usual the solution was dead simple once it struck me. I made a custom test command for setuptools, that simply create a temporary script modeled after the bin/test script that buildout would create, and call that. Problem solved! On Mon, Dec 7, 2009 at 16:24, Lennart Regebro <regebro@gmail.com> wrote:
On Mon, Dec 7, 2009 at 15:46, Lennart Regebro <regebro@gmail.com> wrote:
That doesn't seem to work. If I use discover withing setup.py, I get the same problems as using the standard setuptools testrunner. If I have a custom script that I run to run the tests, the tests seem to get stuck in some sort of infinite regression and never end.
It's really strange that running tests with setuptools fails. I think the best way forward is to try to figure out why, but I have no idea when or if I'm able to do that.
The problem here is that the tests for the test runner assumes that the tests are run via the test script created by the buildout, and must call that script to test itself. This needs to be changed, somehow. I'll think about it, and see if I can come up with a solution.
-- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
And now it's zc.buildout. It also uses itself, to set up the environment so that you can test it. I did try using distribute instead, but I get strange inconsistent errors, different ones each time I try. :-/ If someone can set up a way of running the tests for zc.buildout without using zc.buildout, I'm sure I can help port it to Python 3, but for now I give up. :-) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On Tue, Dec 15, 2009 at 10:22:03AM +0100, Lennart Regebro wrote:
And now it's zc.buildout. It also uses itself, to set up the environment so that you can test it. I did try using distribute instead, but I get strange inconsistent errors, different ones each time I try. :-/
If someone can set up a way of running the tests for zc.buildout without using zc.buildout, I'm sure I can help port it to Python 3, but for now I give up. :-)
How about virtualenv? svn checkout svn+ssh://svn.zope.org/repos/main/zc.buildout/trunk zc.buildout cd zc.buildout virtualenv tmp tmp/bin/easy_install zope.testing tmp/bin/python setup.py develop cd zc.recipe.egg_ ../tmp/bin/python setup.py develop cd ... tmp/bin/zope-testrunner --test-path=src When I tried this on Python 2.6 I got some failures, e.g. Expected: ... warning: install_lib: 'build/lib' does not exist -- no Python modules to install Got: ... warning: install_lib: 'build/lib.linux-i686-2.6' does not exist -- no Python modules to install and Expected: ... UserError: Couldn't install: nonexisting.tgz Got: ... File "/home/mg/src/zc.buildout/src/zc/buildout/easy_install.py", line 360, in _call_easy_install if d.project_name != dist.project_name: AttributeError: 'str' object has no attribute 'project_name' and a few more. If I weren't extremely hungry and starving, I'd run the tests in the official fashion (bin/buildout && bin/test) and see if I get the same failures. Cheers! Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
On 12/15/09 2:21 PM, Marius Gedminas wrote:
If I weren't extremely hungry and starving, I'd run the tests in the official fashion (bin/buildout&& bin/test) and see if I get the same failures.
Be sure to look at DEVELOPERS.txt in the root (you need pythons without setuptools and you need to run with "-c dev.cfg" if memory serves me). Reinout -- Reinout van Rees - reinout@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets"
On Tue, Dec 15, 2009 at 14:21, Marius Gedminas <marius@gedmin.as> wrote:
On Tue, Dec 15, 2009 at 10:22:03AM +0100, Lennart Regebro wrote:
And now it's zc.buildout. It also uses itself, to set up the environment so that you can test it. I did try using distribute instead, but I get strange inconsistent errors, different ones each time I try. :-/
If someone can set up a way of running the tests for zc.buildout without using zc.buildout, I'm sure I can help port it to Python 3, but for now I give up. :-)
How about virtualenv?
I don't see how that helps. But in any case it's not ported to Python 3 yet afaik.
svn checkout svn+ssh://svn.zope.org/repos/main/zc.buildout/trunk zc.buildout cd zc.buildout virtualenv tmp tmp/bin/easy_install zope.testing tmp/bin/python setup.py develop cd zc.recipe.egg_ ../tmp/bin/python setup.py develop cd ... tmp/bin/zope-testrunner --test-path=src
When I tried this on Python 2.6 I got some failures, e.g.
I do not get a zope-testrunner or even a bin directory when doing this. On Tue, Dec 15, 2009 at 14:38, Reinout van Rees <reinout@vanrees.org> wrote:
On 12/15/09 2:21 PM, Marius Gedminas wrote:
If I weren't extremely hungry and starving, I'd run the tests in the official fashion (bin/buildout&& bin/test) and see if I get the same failures.
Be sure to look at DEVELOPERS.txt in the root (you need pythons without setuptools and you need to run with "-c dev.cfg" if memory serves me).
I have, and it says to run python dev.py. Dev py import zc.buildout. That fails, as zc.buildout isn't ported to Python 3 yet. This is the same bootstrapping problem I had with setuptools (who uses itself to install/build itself) and zope.testing (who uses it's own testrunner to run the tests). For setuptools we fixed it by an ugly hack that means 2to3 is run on all of setuptools as soon as you run setup.py. For zope.testing I made a custom test command for setuptools that creates a test-script in the temp directory "manually", and then calls it, which is possibly a slightly less ugly hack. Possibly that last trick might work for zc.buildout too, I haven't investigated. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64
participants (5)
-
Lennart Regebro -
Lennart Regebro -
Marius Gedminas -
Reinout van Rees -
Wolfgang Schnerring