This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Buildbot failures in test_site
Type: behavior Stage: needs patch
Components: Library (Lib), Tests Versions: Python 3.1, Python 2.7
process
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: tarek Nosy List: eric.smith, ocean-city, pitrou, tarek
Priority: high Keywords: patch

Created on 2009-02-19 15:37 by pitrou, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
part_of_fix.patch ocean-city, 2009-02-25 20:38
Messages (6)
msg82477 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-02-19 15:37
Recently, some buildbot failures have started appearing on trunk and
py3k with the following error:

======================================================================
FAIL: test_s_option (test.test_site.HelperFunctionsTests)
----------------------------------------------------------------------

Traceback (most recent call last):
  File
"/home/pybot/buildarea/3.x.klose-ubuntu-i386/build/Lib/test/test_site.py",
line 105, in test_s_option
    self.assertEqual(rc, 1)
AssertionError: 0 != 1

make: *** [buildbottest] Error 1
msg82606 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-02-22 18:19
I manage to reproduce it by running test_site just after test_distutils:

./python -E -tt -m test.regrtest -uall -l -w test_distutils test_site

It could be related to test_distutils modifying an environment variable
without restoring it at the end.
msg82607 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2009-02-22 19:20
Trial and error shows it's test_sdist.py.
msg82717 - (view) Author: Hirokazu Yamamoto (ocean-city) * (Python committer) Date: 2009-02-25 20:38
Probably attached patch will fix this issue. But this patch doesn't
cover other similar problematic codes.

It seems this is multi inheritance problem. Following code shows B.setUp
and B.tearDown are called twice respectively. (In this issue, B
represents PyPIRCCommandTestCase)

class A(object): # LoggingSilencer
    def setUp(self):
        print "A setup"
        super(A, self).setUp()
    def tearDown(self):
        print "A tearDown"
        super(A, self).tearDown()

class B: # PyPIRCCommandTestCase
    def setUp(self):
        print "B setup"
    def tearDown(self):
        print "B tearDown"

class C(A, B): # sdistTestCase
    def setUp(self):
        A.setUp(self)
        B.setUp(self)
    def tearDown(self):
        A.tearDown(self)
        B.tearDown(self)

c = C()
c.setUp()
c.tearDown()

"""
A setup
B setup
B setup # called twice
A tearDown
B tearDown
B tearDown # ditto
"""

P.S. This is first time I saw the behavior of super in multi
inheritance. Movement of code flaw is interesting and fresh for me. :-)
msg82723 - (view) Author: Tarek Ziadé (tarek) * (Python committer) Date: 2009-02-25 22:27
right, subclasses must use super if their superclasses do.

I'll apply Hirozaku patch (thanks). 

I might also simplify distutil base test class to avoid Mixins.
msg82725 - (view) Author: Tarek Ziadé (tarek) * (Python committer) Date: 2009-02-25 22:33
applied in r69976 and r69977
History
Date User Action Args
2022-04-11 14:56:45adminsetgithub: 49566
2009-02-25 22:33:15tareksetstatus: open -> closed
messages: + msg82725
2009-02-25 22:27:27tareksetmessages: + msg82723
2009-02-25 20:38:04ocean-citysetfiles: + part_of_fix.patch
keywords: + patch
messages: + msg82717
nosy: + ocean-city
2009-02-22 19:20:21eric.smithsetnosy: + eric.smith
messages: + msg82607
2009-02-22 18:19:37pitrousetassignee: tarek
messages: + msg82606
nosy: + tarek
2009-02-19 15:37:19pitroucreate