ZConfig 2.5.1 test failures
I'm getting a Traceback when running `python setup.py test` for ZConfig-2.5.1 as per the changelog. Attached is the output, let me know how I can help. I'm not a proficient python programmer; however, I'm more than willing to learn more. --Tim _________________________________________________________________ / They collapsed ... like nuns in the street ... they had no teen \ \ appeal! / ----------------------------------------------------------------- \ \ \ \ /\ ( ) .( o ).
On Tue, Apr 22, 2008 at 6:49 PM, Timothy Selivanow <timothy.selivanow@virtualxistenz.com> wrote:
I'm getting a Traceback when running `python setup.py test` for ZConfig-2.5.1 as per the changelog. Attached is the output, let me know how I can help. I'm not a proficient python programmer; however, I'm more than willing to learn more.
Can you provide the traceback? I'm getting this: Traceback (most recent call last): File "setup.py", line 1, in ? from setuptools import find_packages, setup ImportError: No module named setuptools This is because someone (Tres, IIRC) changed things to assume that setuptools is always available. If you're using zc.buildout, it pretty much is, but probably isn't part of your Python installation (it'll certainly not be part of mine). If that's the problem you're seeing, I'm inclined to fix things so that setuptools is supported if found (required for "python setup.py test", since "test" is from setuptools, not distutils), but otherwise remains optional. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
On Tue, 2008-04-22 at 19:44 -0400, Fred Drake wrote:
Can you provide the traceback?
It's in the attached file at the bottom. I didn't put it in the body of the email 'cause the total output is ~14kB and includes *all* the output from running the tests (so it also shows the last good test that it ran, and everything that led up to it). Here's the Traceback in case someone is interested in just it (I don't think it's useful because it's the unittest module that raises the error...but that's just me ;) Traceback (most recent call last): File "setup.py", line 47, in <module> 'zope.testing', File "/usr/lib64/python2.5/distutils/core.py", line 151, in setup dist.run_commands() File "/usr/lib64/python2.5/distutils/dist.py", line 974, in run_commands self.run_command(cmd) File "/usr/lib64/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/usr/lib/python2.5/site-packages/setuptools/command/test.py", line 119, in run self.with_project_on_sys_path(self.run_tests) File "/usr/lib/python2.5/site-packages/setuptools/command/test.py", line 101, in with_project_on_sys_path func() File "/usr/lib/python2.5/site-packages/setuptools/command/test.py", line 130, in run_tests testLoader = loader_class() File "/usr/lib64/python2.5/unittest.py", line 768, in __init__ self.runTests() File "/usr/lib64/python2.5/unittest.py", line 805, in runTests result = self.testRunner.run(self.test) File "/usr/lib64/python2.5/unittest.py", line 705, in run test(result) File "/usr/lib64/python2.5/unittest.py", line 437, in __call__ return self.run(*args, **kwds) File "/usr/lib64/python2.5/unittest.py", line 433, in run test(result) File "/usr/lib64/python2.5/unittest.py", line 437, in __call__ return self.run(*args, **kwds) File "/usr/lib64/python2.5/unittest.py", line 433, in run test(result) File "/usr/lib64/python2.5/unittest.py", line 281, in __call__ return self.run(*args, **kwds) File "/usr/lib64/python2.5/unittest.py", line 247, in run result.startTest(self) File "/usr/lib64/python2.5/unittest.py", line 649, in startTest self.stream.write(self.getDescription(test)) File "/usr/lib64/python2.5/unittest.py", line 642, in getDescription return test.shortDescription() or str(test) File "/usr/lib64/python2.5/unittest.py", line 232, in shortDescription doc = self._testMethodDoc AttributeError: 'StartUpFailure' object has no attribute '_testMethodDoc' --Tim _______________________________________ / Try to relax and enjoy the crisis. \ \ -- Ashleigh Brilliant / --------------------------------------- \ \ \ \ /\ ( ) .( o ).
On Tue, Apr 22, 2008 at 7:57 PM, Timothy Selivanow <timothy.selivanow@virtualxistenz.com> wrote:
Here's the Traceback in case someone is interested in just it (I don't think it's useful because it's the unittest module that raises the error...but that's just me ;)
What's odd is that there's nothing from ZConfig or it's tests in here. I can't reproduce this, using either Python 2.4.4 or 2.5.2; in both cases I'm using setuptools 0.6c8. I don't think this is a ZConfig problem, but am willing to be enlightened. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fred Drake wrote:
On Tue, Apr 22, 2008 at 6:49 PM, Timothy Selivanow <timothy.selivanow@virtualxistenz.com> wrote:
I'm getting a Traceback when running `python setup.py test` for ZConfig-2.5.1 as per the changelog. Attached is the output, let me know how I can help. I'm not a proficient python programmer; however, I'm more than willing to learn more.
Can you provide the traceback? I'm getting this:
Traceback (most recent call last): File "setup.py", line 1, in ? from setuptools import find_packages, setup ImportError: No module named setuptools
This is because someone (Tres, IIRC) changed things to assume that setuptools is always available. If you're using zc.buildout, it pretty much is, but probably isn't part of your Python installation (it'll certainly not be part of mine).
Not it. ;) $ svn blame svn+ssh://svn.zope.org/repos/main/ZConfig/trunk/setup.py\ | grep setuptools 79390 fdrake from setuptools import find_packages, setup My changes were to add support for running tests using 'setup.py test'. See output from: $ svn diff svn+ssh://svn.zope.org/repos/main/ZConfig/tags/2.5{,.1}
If that's the problem you're seeing, I'm inclined to fix things so that setuptools is supported if found (required for "python setup.py test", since "test" is from setuptools, not distutils), but otherwise remains optional.
- -1. In fact, the setuptools dependency has been there since the initial checkin to a "satellite" direcotry (#72182): $ svn blame -r 76917 \ svn+ssh://svn.zope.org/repos/main/ZConfig/trunk/setup.py \ | grep setuptools 72182 jim from setuptools import setup FWIW, using a python which does have setuptools installed, I get: $ /path/to/python-with-setuptools setup.py test running test Checking .pth file support in \ /home/tseaver/bin/python2.4 -E -c pass Searching for zope.testing Reading http://pypi.python.org/simple/zope.testing/ Reading http://svn.zope.org/zope.testing Best match: zope.testing 3.5.1 Downloading \ http://pypi.python.org/packages/source/z/zope.testing/zope.testing-3.5.1.tar... Processing zope.testing-3.5.1.tar.gz Running zope.testing-3.5.1/setup.py -q bdist_egg --dist-dir \ /tmp/easy_install-1s54Lg/zope.testing-3.5.1/egg-dist-tmp-2bnzUH Installed /home/tseaver/tmp/ZConfig-2.5.1/zope.testing-3.5.1-py2.4.egg running egg_info creating ZConfig.egg-info writing ZConfig.egg-info/PKG-INFO writing top-level names to ZConfig.egg-info/top_level.txt writing dependency_links to ZConfig.egg-info/dependency_links.txt writing manifest file 'ZConfig.egg-info/SOURCES.txt' writing manifest file 'ZConfig.egg-info/SOURCES.txt' running build_ext test_derived_dict \ (ZConfig.components.basic.tests.test_mapping.BasicSectionTypeTestCase)\ ... ok .... test_undefined_names (ZConfig.tests.test_subst.SubstitutionTestCase)\ ... ok ---------------------------------------------------------------------- Ran 155 tests in 1.005s OK Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIDn3r+gerLs4ltQ4RApsxAKCf6+c/jaPzKC/YYiheIZyrtX3yAACeOaNK RPZ5ysJEqt57tuaqxbuRsWE= =fo/G -----END PGP SIGNATURE-----
Hi! On Tue, Apr 22, 2008 at 03:49:07PM -0700, Timothy Selivanow wrote:
I'm getting a Traceback when running `python setup.py test` for ZConfig-2.5.1 as per the changelog. Attached is the output, let me know how I can help. I'm not a proficient python programmer; however, I'm more than willing to learn more.
...
test_undefined_names (ZConfig.tests.test_subst.SubstitutionTestCase) ... ok [?1034hTraceback (most recent call last): File "setup.py", line 47, in <module> 'zope.testing', File "/usr/lib64/python2.5/distutils/core.py", line 151, in setup dist.run_commands() File "/usr/lib64/python2.5/distutils/dist.py", line 974, in run_commands self.run_command(cmd) File "/usr/lib64/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/usr/lib/python2.5/site-packages/setuptools/command/test.py", line 119, in run self.with_project_on_sys_path(self.run_tests) File "/usr/lib/python2.5/site-packages/setuptools/command/test.py", line 101, in with_project_on_sys_path func() File "/usr/lib/python2.5/site-packages/setuptools/command/test.py", line 130, in run_tests testLoader = loader_class() File "/usr/lib64/python2.5/unittest.py", line 768, in __init__ self.runTests() File "/usr/lib64/python2.5/unittest.py", line 805, in runTests result = self.testRunner.run(self.test) File "/usr/lib64/python2.5/unittest.py", line 705, in run test(result) File "/usr/lib64/python2.5/unittest.py", line 437, in __call__ return self.run(*args, **kwds) File "/usr/lib64/python2.5/unittest.py", line 433, in run test(result) File "/usr/lib64/python2.5/unittest.py", line 437, in __call__ return self.run(*args, **kwds) File "/usr/lib64/python2.5/unittest.py", line 433, in run test(result) File "/usr/lib64/python2.5/unittest.py", line 281, in __call__ return self.run(*args, **kwds) File "/usr/lib64/python2.5/unittest.py", line 247, in run result.startTest(self) File "/usr/lib64/python2.5/unittest.py", line 649, in startTest self.stream.write(self.getDescription(test)) File "/usr/lib64/python2.5/unittest.py", line 642, in getDescription return test.shortDescription() or str(test) File "/usr/lib64/python2.5/unittest.py", line 232, in shortDescription doc = self._testMethodDoc AttributeError: 'StartUpFailure' object has no attribute '_testMethodDoc'
StartUpFailure is, I believe, a test-like object the zope.testing testrunner uses to indicate one of the test modules couldn't be imported (most likely because of a missing dependency). It subclasses unittest.TestCase, but doesn't call the inherited __init__, which, in both Python 2.4 and 2.5, initializes the _testMethodDoc attribute. In other words you have found a bug in zope.testing's bug reporting code. By the way, the usual way to run tests in the Zope-3-land is to use bin/test rather than setup.py test. It uses a slightly different test runner that uses a slightly different method of getting the test description and therefore hides this incompatibility. Which probably explains why nobody saw it before. On the other hand, compatibility with setup.py test is desirable, and this bug should be fixed. https://bugs.launchpad.net/zope.testing/+bug/221151 The next step would be to write a unit test to reproduce this in zope.testing's test suite. Marius Gedminas -- How much net work could a network work, if a network could net work?
On Wed, 2008-04-23 at 22:38 +0300, Marius Gedminas wrote:
By the way, the usual way to run tests in the Zope-3-land is to use bin/test rather than setup.py test. It uses a slightly different test runner that uses a slightly different method of getting the test description and therefore hides this incompatibility. Which probably explains why nobody saw it before. On the other hand, compatibility with setup.py test is desirable, and this bug should be fixed.
I assume bin/test is part of zope.testing... If so (I'm going to be installing it soon) how would I go about running the tests then? The ultimate goal of what I'm working on is packaging ZODB3, and I've been working my way through the dependencies. Do all of the zope-ish packages use zope.testing? I'd like to be able to include tests in %check, as I don't usually get to test the built packages right-a-way and this would at least show that it passes basic scrutiny. Also, what was the rationale in making zope.testing instead of just using unittest. Does it extend unittest in a more zope-ish way (similarly for zope.buildout in regards to setuptool)? I'm just trying to understand the dynamics of the zope and python communities so I know areas to focus my attention.
https://bugs.launchpad.net/zope.testing/+bug/221151
The next step would be to write a unit test to reproduce this in zope.testing's test suite.
Thanks for submitting that bug. I'll look into writing a unit test based on the one that uses zope.testing, but while I understand the concepts of writing unit tests, I'm really just a n00b when it comes to all of this. I find that I learn the best by jumping straight in, feet first (not head first...broken legs are easier to deal with than a broken neck ;) --Tim ________________________________________________________________ < If only I could be respected without having to be respectable. > ---------------------------------------------------------------- \ \ \ \ /\ ( ) .( o ).
On Thu, Apr 24, 2008 at 02:03:53PM -0700, Timothy Selivanow wrote:
On Wed, 2008-04-23 at 22:38 +0300, Marius Gedminas wrote:
By the way, the usual way to run tests in the Zope-3-land is to use bin/test rather than setup.py test. It uses a slightly different test runner that uses a slightly different method of getting the test description and therefore hides this incompatibility. Which probably explains why nobody saw it before. On the other hand, compatibility with setup.py test is desirable, and this bug should be fixed.
I assume bin/test is part of zope.testing...
In a matter of speaking. As far as I can tell, the proper procedure is 1. Check out a zope-ish package from Subversion. 2. Run 'buildout bootstrap' if you've installed zc.buildout system-wide (easy_install zc.buildout) or run './bootstrap.py' if you haven't. This creates a script named 'bin/buildout'. 3. Run 'bin/buildout' to install all the necessary dependencies, build any C extension modules, and create any scripts in bin/. This step usually creates the 'bin/test' script. 4. Run 'bin/test' to run the full test-suite. To get a prettier, colourful result with progress indication, pass '-pvc' to the 'bin/test' script.
If so (I'm going to be installing it soon) how would I go about running the tests then? The ultimate goal of what I'm working on is packaging ZODB3, and I've been working my way through the dependencies.
Buildout automates all that for you. On the other hand, if you're working on packaging something for some distribution, maybe you don't want buildout to install the dependencies in a local subdirectory... Brian Sutherland and Ignas Mikalajūnas recently packaged nearly all of Zope 3.4 for Debian/Ubuntu. You may want to discuss packaging matters with them, I assume.
Do all of the zope-ish packages use zope.testing?
Yes.
I'd like to be able to include tests in %check, as I don't usually get to test the built packages right-a-way and this would at least show that it passes basic scrutiny.
Good idea.
Also, what was the rationale in making zope.testing instead of just using unittest. Does it extend unittest in a more zope-ish way (similarly for zope.buildout in regards to setuptool)? I'm just trying to understand the dynamics of the zope and python communities so I know areas to focus my attention.
unittest provides you with a way to write tests, and some automation for collecting all tests in a single Python file. This is not sufficient for Zope's packages that have hundreds of test modules. zope.testrunner builds on top of unittest and gives you automated test collection from multiple test modules, additional output formatting options (such as colorization), support for multiple test layers with expensive setup/teardown that you really want to do once and not once for every test, support for filtering and running just a subset of the tests from the command line, when you're making changes in a single module and want to run just the pertinent tests. I've probably left things out. It is entirely possible for Zope to move to a more-widely-used test runner such as nose, but currently no one seems to be interested in investigating whether nose has all the features that zope packages currently expect from their test runner.
https://bugs.launchpad.net/zope.testing/+bug/221151
The next step would be to write a unit test to reproduce this in zope.testing's test suite.
Thanks for submitting that bug. I'll look into writing a unit test based on the one that uses zope.testing, but while I understand the concepts of writing unit tests, I'm really just a n00b when it comes to all of this. I find that I learn the best by jumping straight in, feet first (not head first...broken legs are easier to deal with than a broken neck ;)
I kind-of wrote the test already, and then instead of comitting it and fixing the bug started flaming on this mailing list (sorry, everyone!). Marius Gedminas -- 1 + 1 = 3 -- from a Microsoft advertisement
participants (4)
-
Fred Drake -
Marius Gedminas -
Timothy Selivanow -
Tres Seaver