[Catalog-sig] (no subject)

[Maurice Ling]

Ian Bicking wrote:

> richardjones at optusnet.com.au wrote:
>
>> Another point that I'd like to make is that I believe we should avoid 
>> reimplementing
>> RPM, DEB, fink, whatever. Or at least we should not ignore them. We 
>> can produce
>> meta-data that supports those packaging formats. Thus a user has the 
>> opportunity to
>> install Python software using the existing package management 
>> mechanisms installed
>> in their system, rather than something new and independent just for 
>> Python. The
>> latest PEP I've proposed adds some meta-data that makes the DEB-alike 
>> packagers more
>> happy, and should also help out RPM packagers.
>>
>> Distutils already does a fairly good job of handling the actual 
>> installation of
>> Python software -- it compiles things, can install data files, with a 
>> little extra
>> effort other stuff can be done too. It generates RPMs, DEBs, Windows 
>> Installers.
>> There's a desire from the Ubuntu packagers to add a doc_files option 
>> to the setup()
>> args, but that's for another discussion.
>>
>> Anyway, I'm rambling. My point is clear though: I believe we should 
>> avoid developing
>> Yet Another Packaging System just for the sake of it. And certainly 
>> we should play
>> well with others where possible.
>
>
> OTOH, there is a place for distutils installs even in the presence of 
> native packaging.  Because Python doesn't have versioned imports, in 
> many situations (at least the kind of stuff I do) a system-wide 
> installation isn't appropriate.  And most native packagers don't do 
> well at localized installations.
>
>> I guess we need to ask what it is that our database of installed 
>> Python modules will
>> achieve that the existing packaging systems don't.
>
>
> Of course, I don't know what a database would achieve exactly in this 
> case either, except perhaps in the presence of versioned imports.  
> Which I guess Eggs provide, in a way.  But then Eggs mix it up too, 
> since wouldn't be "installed" either, they just get put in the right 
> place, and so there's no chance for a database to recognize them.
>
Hi,

Thank for all your pointers.

I see my proposed work to solve one very fundamental issue. (Please take 
a look at the thread "bytecode non-backcompatibility" started in April 
2005 in python-list)

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?

Building on that, if say I distribute a software which requires 5 
3rd-party libraries. Currently, I can only tell the user which libraries 
are necessary and hopefully they don't get too frustrated (imagine if 
each of the 5 libraries depends on 2 libraries each). If my work is 
around (PEP 262 and 314), I can then ask the user to just install ONE 
system and in my software distribution, calls that one system to install 
all the necessary libraries.

I've not done anything substantial yet.... still feeling around my way.

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/20050503/2a6166cb/mauriceling.vcf