[Catalog-sig] Withdrawing PEP 262

Chris Liechti cliechti@gmx.net
Sun, 13 Oct 2002 23:55:56 +0200


Am 13.10.2002 22:40:29, schrieb "A.M. Kuchling" <amk@amk.ca>:

>PEP 262 is a proposal for a database of installed Python packages.  I
>wrote it as a step toward implementing automatic installation of
>Python software.  After playing with Fink on MacOS X a bit, I've
>decided to withdraw the PEP, because I now think that Python shouldn't
>invent its own database; package handling and dependency tracking
>should be the operating system's job.  

i use Debian Linux, which has a great package management system too
and it's very nice when all the dependencies are installed along with
a python extension. i understand you're exitement.

but... not all systems have a package management system, e.g. on
windows rules chaos. what can we do there?
and there are some many different packaging systems...

the problem of different package management systems can be partly
soved by distutils. there are some packaging types already there (but
i miss deb). the other problem is that a extension creator need to make
all those formats and provide the downloads.
and how about dependecies to onther packages. it's impossible
for an author to cope with all of them for all different systems.
(simplest to do will be to create a package with no dependecies, that way
a bit confort goes away but its more motivating for the maintainer to create
different package downloads, so that they're at least there.)

i admit that i'm less interested in an installed files database (within python)
rather than in a good way to download modules from a repository.
if there was a browser that lets one select the extensions one wishes and
then just press OK, that would be great. (maybe that could even be called
within a running python application to request the user to install an addon.
run in a separete process to solve the problem with different GUI systems)

i think it would be a pythonic solution when that browser would integrate
with the systems package manager. as a fallback it could still use
"setup.py install" (loosing remove capability but that's not too important as
systems without a package manager have a mess anyway ;-)

that would mean that there must be a repository of modules (at python.org?)
with downloads of zip, rpm, deb, etc access through http and ftp and easy
upload (for a quick growth). and maybe some hierarchical package naming
system should be developed for that.

what do you think of such an approach?

chris