[Catalog-sig] (no subject)
mauriceling at acm.org
Fri May 6 01:36:28 CEST 2005
Bob Ippolito wrote:
>> 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
>> 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
>> 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
>> 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
>> 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.
> In other words, Python has "DLL hell" and there isn't a damned thing
> that a system package manager can do about it other than say "sorry,
> you can't install FooBar and CheeseFactory at the same time, because
> FooBar needs BazWibble 1.0 and CheeseFactory needs BazWibble 2.0".
> Therefore, there needs to be some mechanism to install stuff to an
> "app-packages" because it's not always possible or appropriate to put
> everything in "site-packages".
> ... however, the referenced PEP does nothing to help this problem
Yes, I agree that PEP 262 doesn't help to solve local packages
(app-packages) as compared to global packages (site-packages). But it
can be extended into that direction. Given that different applications
may require different versions of a package, and disutils installs newer
versions of the package over older versions (I'm not sure on this one,
although the end results seems pretty much this way), there is a reason
why this feature is useful.
Maurice Han Tong LING, BSc(Hons)(Biochem), AdvDipComp, CPT, SSN, FIFA,
MASBMB, MAMBIS, MACM
Doctor of Philosophy (Science) Candidate, The University of Melbourne
mobile: +61 4 22781753, +65 96669233
mailing address: Department of Zoology, The University of Melbourne
Royal Parade, Parkville, Victoria 3010, Australia
residence: 9/41 Dover Street, Flemington, Victoria 3031, Australia
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 334 bytes
Desc: not available
Url : http://mail.python.org/pipermail/catalog-sig/attachments/20050506/4623bf1d/mauriceling.vcf
More information about the Catalog-sig