[Catalog-sig] (no subject)
Ian Bicking
ianb at colorstudy.com
Thu May 5 19:38:04 CEST 2005
Martin v. Löwis wrote:
> Maurice Ling wrote:
>
>>Given that (1) there can be multiple versions of Python installed in a
>>system, (2) each version maintains their own site-packages directory and
>>(3) if C modules are installed, they are not compatible with other
>>versions of Python... Imagine a system administrator who had installed
>>50 libraries and their dependencies in site-package of Python 2.3 and
>>now has to do it for Python 2.4, can we make his life better?
>
>
> I'd like to point out that this is a task that the "native" package
> format can solve. For example, in Debian, when I use Debian packages
> to install the 50 libraries, the current Debian Python policy manages
> to update all the libraries from Python 2.3 to Python 2.4, when
> the "official" Debian Python version becomes 2.4.
Just as a reminder, what Maurice talked about actually doesn't relate to
my initial concern. Or, maybe I'll call it my distutils-love, where
distutils does something currently that system packagers don't do. I'm
not so worried about per-python-version installation of packages -- for
the most part this has worked well for some time. It's the support of
multiple *library* versions that keeps me using distutils, and actually
keeps me from using native packages for most things, except those places
where there's already a centralized system (e.g., I don't install more
than one version of Postgres on a server, so I don't need more than one
version of psycopg). Or things that are stable and practically
equivalent to "standard" for me, like mxDateTime.
But for most libraries I'm very reluctant to install them globally; I
don't want to do monolithic upgrades of systems, I'd rather do
incremental upgrades of specific applications, and handle any large
upgrades through centralized tracking of the installations.
In the C world this is more-or-less solved through a system of symlinks,
e.g., libjpeg.so, libjpeg.so.9, libjpeg.so.9.1, etc. But we don't have
that for Python. So if I have one application that needs SQLObject 0.5,
and another that needs SQLObject 0.6, I just can't use any system
package manager.
At first I was thinking, well, that's because of my specific situation
-- multi-client host machines, applications that go quiet for extended
periods of time and shouldn't be disturbed, and my own tendency to use
lots of in-development libraries (my own and other people's). But as I
think about it, it seems like it applies to most situations. Subway,
for instance, is built against a specific version of SQLObject.
UltraGleeper is built against a different version (just to pick two
projects I know of off the top of my head). Well, technically they used
different package names for the different versions, but the general
problem should be fairly obvious. Making the installation robust and
easy for these kinds of things -- both applications and frameworks -- is
what I think we are trying to do. But as long as we have unversioned
package installation and imports, I think it's a bad idea to do
system-wide installation most packages.
--
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Catalog-sig
mailing list