[Catalog-sig] (no subject)

[Maurice Ling]

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  
>> 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.
>
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.

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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mauriceling.vcf
Type: text/x-vcard
Size: 334 bytes
Desc: not available
Url : http://mail.python.org/pipermail/catalog-sig/attachments/20050506/4623bf1d/mauriceling.vcf