[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