[tahoe-dev] [tahoe-lafs] #1258: having Tahoe or any dependency installed in site-packages (or any other shared directory) can cause us to run or test the wrong code

tahoe-lafs trac at tahoe-lafs.org
Sat Jan 1 03:45:38 UTC 2011


#1258: having Tahoe or any dependency installed in site-packages (or any other
shared directory) can cause us to run or test the wrong code
------------------------------------+---------------------------------------
     Reporter:  davidsarah          |       Owner:  davidsarah          
         Type:  defect              |      Status:  new                 
     Priority:  major               |   Milestone:  1.8.1               
    Component:  dev-infrastructure  |     Version:  1.8.0               
   Resolution:                      |    Keywords:  setuptools test docs
Launchpad Bug:                      |  
------------------------------------+---------------------------------------

Comment (by davidsarah):

 Replying to [comment:6 davidsarah]:
 > I will investigate tomorrow why {{{test_the_right_code}}} didn't detect
 this.

 This is a really confusing bug.

 {{{python setup.py trial}}} is importing the right code in its own
 process. The problem is that the subprocess created by
 [source:src/allmydata/test/test_system.py at 4895#L1777
 _run_cli_in_subprocess] in {{{test_system.py}}} (called from the
 [source:src/allmydata/test/test_system.py at 4895#L1601 test added] for
 #1253) is importing the wrong code, from a version installed before #1253
 was fixed.

 However, that situation -- where we import the wrong code when running
 {{{bin/tahoe}}} in a subprocess -- should have been picked up by
 [source:src/allmydata/test/test_runner.py at 4853#L85 test_path] in
 {{{test_runner.py}}}.

 {{{_run_cli_in_subprocess}}} does not run {{{bin/tahoe}}} in exactly the
 same way as {{{test_path}}} (they differ in whether the command uses
 {{{sys.executable}}}, and in the passed environment), but the differences
 seem not to be significant. In fact adding code to run {{{bin/tahoe
 --version-and-path}}} using {{{_run_cli_in_subprocess}}}, like this:
 {{{
         def _subprocess_tahoe_version(ign):
             env = os.environ
             env['http_proxy'] = env['HTTP_PROXY'] =
 "http://127.0.0.0:12345"  # invalid address
             return self._run_cli_in_subprocess(["--version-and-path"],
 env=env)
         d.addCallback(_subprocess_tahoe_version)

         def _check_subprocess_tahoe_version(res):
             print repr(res)
         d.addCallback(_check_subprocess_tahoe_version)
 }}}
 gives output showing a version of
 {{{
 allmydata-tahoe: 1.8.1-r4908 (d:\\tahoe\\tahoe-clean\\src)
 }}}
 which is correct. (The difference between r4908 here and r4900 in
 comment:6 is not significant, I committed a few patches.) The value of the
 PYTHONPATH variable set by {{{d:\tahoe\tahoe-clean\bin\tahoe.pyscript}}}
 is {{{d:\tahoe\tahoe-clean\support\Lib\site-packages}}}, which is also
 right.

 So, I have no explanation of why the {{{--version-and-path}}} output from
 the subprocess is correct, but it is still importing the wrong code.
 ({{{c:\python26\lib\site-packages\allmydata\_version.py}}} is present, so
 it is not the case that it is falling back to a later {{{sys.path}}} entry
 because that file is missing.)

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1258#comment:7>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage


More information about the tahoe-dev mailing list