[tahoe-lafs-trac-stream] [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]

#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:  zooko                             
         Type:  defect              |      Status:  assigned                          
     Priority:  major               |   Milestone:  1.9.0                             
    Component:  dev-infrastructure  |     Version:  1.8.0                             
   Resolution:                      |    Keywords:  setuptools test docs review-needed
Launchpad Bug:                      |  
------------------------------------+---------------------------------------

Comment (by zooko):

 Replying to [comment:20 davidsarah]:
 > Replying to [comment:18 zooko]:
 > >
 > > 2. If we "solve" this bug by removing the
 {{{pkg_resources.require()}}}, as is done by
 [20110101110141-93fa1-3557bc2136f970fae05c1d20e336c32fec8e3d6d]/ticket1306,
 is it really a full solution? Could it be then that we are relying on the
 {{{zetuptoolz}}}-based dependency-resolution to make sure we have deps of
 the right version number, and there is a bug in {{{zetuptoolz}}}'s
 {{{pkg_resources}}} so that we're actually getting a package of the wrong
 version number, and
 [20110101110141-93fa1-3557bc2136f970fae05c1d20e336c32fec8e3d6d] causes us
 to ignore this fact?
 >
 > The calls to {{{pkg_resources.require()}}} that were removed in
 [4936/ticket1306], were never relied on to perform version checking. It
 was the calls in {{{_auto_deps.require_auto_deps()}}} that were supposed
 to be doing that. But they weren't working either.

 I didn't mean either of those, I meant that {{{python setup.py build}}},
 {{{python setup.py install}}}, and {{{easy_install allmydata-tahoe}}} rely
 on {{{pkg-resources}}}-based dependency resolution. (The former two rely
 on {{{zetuptoolz}}}, the latter relies on either {{{setuptools}}} or
 {{{distribute}}}, depending on which one provides your local
 {{{easy_install}}} executable.)

 So, if {{{pkg_resources.require()}}} is giving us the wrong version of a
 dependency, does that suggest that the setup step that we just did may
 have been satisfied with an extant dependency even though it was of an
 incompatible version?

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