Bob Ippolito wrote:
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.
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.
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 really.
Thanks guys.
Cheers Maurice
--
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
resume: http://maurice.vodien.com/maurice_resume.pdf
www: http://www.geocities.com/beldin79/
begin:vcard fn:Maurice Ling n:Ling;Maurice org:The University of Melbourne;Department of Zoology adr:;;Gate 12, Genetics Lane;Parkville;Victoria;3010;Australia email;internet:[EMAIL PROTECTED] title:Probatory Ph.D. Candidate tel;cell:+61 4 22781753 x-mozilla-html:FALSE url:http://www.geocities.com/beldin79/ version:2.1 end:vcard
_______________________________________________ Catalog-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
