[tahoe-dev] [tahoe-lafs] #1246: figure out why "FreeStorm Win7-amd64-mingw py2.6" is red on the "test-with-fake-pkg" step

tahoe-lafs trac at tahoe-lafs.org
Fri Nov 5 17:25:44 UTC 2010


#1246: figure out why "FreeStorm Win7-amd64-mingw py2.6" is red on the "test-with-
fake-pkg" step
---------------------------+------------------------------------------------
     Reporter:  zooko      |       Owner:  freestorm          
         Type:  defect     |      Status:  new                
     Priority:  major      |   Milestone:  soon               
    Component:  packaging  |     Version:  1.8.0              
   Resolution:             |    Keywords:  buildbot setuptools
Launchpad Bug:             |  
---------------------------+------------------------------------------------

Comment (by davidsarah):

 Replying to [comment:8 zooko]:
 > So if I understand correctly, the problem you are focussing on is that
 sometimes distributions get installed by copying their modules directly
 into some directory which is on {{{sys.path}}}. This makes it so that
 {{{import $MODULENAME}}} will subsequently work but it is a problem, if I
 understand you correctly, if more than one distribution is installed into
 the same directory because then there is no way to prioritize one of the
 distributions without thereby also prioritizing all the other
 distributions in the same directory. By "prioritize" here I guess I mean
 move it closer to the front of {{{sys.path}}}. Other methods of
 manipulating its precedence before importing would be moving it closer to
 the end of the {{{sys.path}}} or removing the directory from the
 {{{sys.path}}} entirely. None of these can be done on only a single
 distribution if more than one distribution has been installed "directly"
 (by dint of copying its modules into place) in a single directory.

 Exactly.

 > One thing to note is that the standard distutils, without
 setuptools/zetuptoolz/distribute, ''always'' installs things in this way!

 However, the problem in this ticket only applies to Tahoe-LAFS
 dependencies (direct or indirect, including the {{{allmydata-tahoe}}}
 package itself) that are installed in this way.

 This could be worked around in several ways:

 a) change zetuptoolz to order "development" dists (directories containing
 Python code and an {{{.egg-info}}} subdirectory) after non-development
 dists when satisfying {{{__requires__}}} lists. Note: the
 {{{pkg_resources}}} code involved is complicated and I don't understand
 it.

 b) change zetuptoolz so that it does not view development dists as
 satisfying a dependency. That would cause a non-development dist to be
 used automatically instead. (pywin32 is a potential spanner in the works
 because it can't currently be installed as an egg, but maybe #142 could be
 fixed.) Fixing #1233 is important here, because otherwise you would have
 regressions where a package is already installed but only as a development
 dist, and building a new version of it fails because it can't be compiled.

 c) change the wrapper scripts not to use the {{{__requires__}}} mechanism
 and to put the dependencies directly at the start of {{{sys.path}}}
 itself. This would still have to avoid viewing development dists as
 satisfying a dependency, or else it would run into the same problem.

 [...]
 > Okay, so now I can appreciate David-Sarah's conclusion: "We should never
 use {{{--single-version-externally-managed}}} to install Tahoe into any
 directory where other distributions might also be installed.". That makes
 sense. We already do avoid that, as far as I know. For example, [http
 ://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/quickstart.html
 quickstart.html] doesn't advise the user to do that.

 As far as I can see, nothing in our docs advises ''against'' installing
 Tahoe using {{{setup.py install}}} or {{{easy_install}}}. That's a
 standard way of installing Python packages.

 Besides, there's no '''good''' reason why that shouldn't work (that is,
 make the installed version the default, but still allow running other
 versions). Design failings in distutils and/or setuptools are a bad
 reason.

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


More information about the tahoe-dev mailing list