Ian Bicking wrote:
[EMAIL PROTECTED] 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/
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
