Features for a Python package manager?

[Georg Brandl]

Robert Kern wrote:
> Georg Brandl wrote:
>> Robert Kern wrote:
>> 
>>>Mike Meyer wrote:
>>>
>>>>Nick Coghlan <ncoghlan at iinet.net.au> writes:
>>>>
>>>>
>>>>
>>>>>I don't know enough about Portage to answer that question. I do know
>>>>>any package manager which made it into the standard distribution would
>>>>>need to work for at least the big three platforms (Windows/Mac/*nix) :)
>>>>
>>>>
>>>>Being written in python - and hopefully integrated into Distutils -
>>>>why shouldn't it work on any platform that Python worked on?
>>>
>>>Assumptions about directory structures, and the like.
>> 
>> 
>> That is already taken care by the distutils.
> 
> More or less. I'm in the middle of packaging up ~40 Python packages for 
> the Mac[1]. For a "standard" packaging mechanism, distutils allows for 
> some bloody idiosyncratic ways to say "put these files there". This is a 
> hard problem, and it's not solved entirely by distutils.
> 
> I don't think anyone has satisfactorily solved the problem of 
> distributing data with libraries. Well, okay, the *distribution* isn't 
> the problem. Having the library be able to locate that data on all 
> platforms is difficult. Some packages will more-or-less hardcode 
> *nix-type paths which may be inappropriate even on some *nix-type 
> platforms (yes, PyX, I'm looking at you :-)). A general package system 
> like Portage has the freedom of being able to dictate these things. A 
> Python package manager does not. You can establish a standard for each 
> of the Big Three platforms, but it may not do you much good if the 
> libraries don't know about it.
> 
> CPAN is a closer analogue in this regard and would probably be a better 
> tool to study and copy from than Portage. I don't know much about it, 
> but how it responds to these issues will probably more instructive than 
> how Portage does.

CPAN, as I understand it, is a mirror system for packages, which
downloads packages and manages those. Correct me if I'm wrong, but the
actual installation is done by each package's Makefile.PL script and not
by CPAN itself.

This is also Portage's philosopy. It only issues those commands needed
to build and install the package (ideally "tar xzf package; cd package;
make install"). Of course one can do additional steps such as applying
patches, but where the files go etc. is the author's responsibility, not
the package system's.

[Problems with dependencies]

I am aware of these problems - however I feel like the package author
has to be the one to address them. There must be a cooperation between
author and packager to clear these issues.

About non-Python-dependencies: The plan is to add a "Non-Py-Requires:"
(or so) field to the metadata that is displayed to the user, and it will
be his responsibility to install these libraries/headers/files first.

>> The various PEPs already
>> describe a simple method how to store package metadata, and I will try
>> to follow these standards as close as possible. Of course, the PyPI
>> would have to be adapted for that.
> 
> Fair enough. What parts of Portage do you intend to steal, then?

Right, that's my weak point. I do not overly like the PEPs' way, but
integrating with distutils is the way to go.

regards,
Georg