Mailman 3 September 2007 - Distutils-SIG

Re: [Distutils] Disabling --single-version-externally-managed
by Phillip J. Eby Sept. 3, 2007

Sept. 3, 2007

At 10:38 PM 9/3/2007 +0100, Robin Bryce wrote: >There are a great many python packages whose source distributions are >perfectly capable of running in place - why should I have to "install" >such software before I'm satisfied it makes a useful addition to my >system ? In something of a fit of frustration I wrote this ~1000 line >python module: > >http://svn.wiretooth.com/svn/open/pyrun/trunk/pyrun.py > >http://svn.wiretooth.com/svn/open/pyrun/trunk/pyrun.html > >wget is all the installation it needs. The -i -d and -p modes of >operation are the ones I think might address "quick & dirty scripting" >and "experimentation" from Toshios scenario. AFAICT, pyrun doesn't handle dependencies between packages, let alone manage version conflicts, so I'm not clear on how it relates to the present discussion.

1 0

Re: [Distutils] Disabling --single-version-externally-managed
by Phillip J. Eby Sept. 3, 2007

Sept. 3, 2007

At 09:20 PM 8/31/2007 -0700, Toshio Kuratomi wrote: >Just to illustrate what I'm trying to achieve. I've updated the Fedora >Packaging Guidelines[1]_ to allow two versions of a package to coexist. > I'll list here the sqlalchemy-0.4 and -0.3 build steps, filelists, and >the output of the test-sql.sh script using this procedure. The end >result is what we want but the build step to get there seem a tad >fragile and kludgey. Since these are going to become guidelines for all >of our python packages, I'd like to know if either: 1) there's a better >way to do this or 2) the results I'm achieving are not expected and >could disappear with a random upgrade of setuptools. > >.. _[1]: http://fedoraproject.org/wiki/PackagingDrafts/PythonEggs Here's the thing: if you want multiple installed versions of a package, *and* you want there to be a default version, then you *have* to have easy_install (or zc.buildout, or some similar tool) generate the startup scripts for anything that wants to use a non-default version. This is true irrespective of the formats of the versions involved, whether they're zipfiles, directories, single-version, or whatever. It's just the nature of the beast, due to the fact that there is a global 'working_set' that lists the projects that are currently on sys.path, and it is initialized when pkg_resources is imported. (And currently, there is no way to *remove* a distribution from the working set.) Thus, if you want multiple versions *and* want to be able to select a version after pkg_resources has been imported, you *cannot* have a default version. In other words, the egg must not be on sys.path when pkg_resources is imported. Then, pkg_resources can locate the desired version and add it. (By the way: "on sys.path" means, "is importable", not "is in a directory on sys.path". An .egg file or directory in site-packages is not "on sys.path" unless its filename is actually listed in sys.path. A single-version egg in site-packages, however, *is* on sys.path).

3 18

Disabling --single-version-externally-managed
by Ignacio Vazquez-Abrams Sept. 1, 2007

Sept. 1, 2007

I have some packages that I'm using the following with: %{__python} setup.py install -O1 --skip-build --root $RPM_BUILD_ROOT I now need to install multiple versions of one of the packages and so need to disable the implicit --single-version-externally-managed. How can I do so and still use setup.py install? -- Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>

3 7