[Distutils] Re: Package DB: strawman PEP

[Mark W. Alexander]

On Tue, 17 Jul 2001, Andrew Kuchling wrote:

> [Picking up the package-DB thread from last week]
> 
> On Mon, Jul 09, 2001 at 03:17:35AM -0400, Daniel Berlin wrote:
> >This can easily be rebuilt in case of corruption, since *it* was
> >generated initially by scanning the files (you just keep it up to date
> >when you install packages, and if something gets out of whack,
> >completely rebuild it).
> 
> The real package database implementation will very likely build a
> cached version of the data using anydbm or some faster mechanism.  I
> don't think the PEP needs to specify that, though if people disagree
> it could certainly be added.  I 

This is starting to bother me even more than it did at first.

If Distutils has a package database, and you use it to generate a
native binary package, will the generated package update the distutils
database, the native package manager's database, both, or neither?
There's a whole boatload of problems no matter which answer you pick.

The discussions so far have indicated to me that the primary problem
is that the Windows platform has no true "native" manager. Does it
make sense to provide this as part of Distutils for the sake of one
platform, or does it make more sense to standardize on a installer for
Windows that provides package management. Distutils bdist_win*
packages would then be handled through a consistent interface that
would register their contents properly. It could even go further, and
properly manage multiple Python installations on the same machine,
with different Distutils packages in each tree.

Maybe I'm out in left field, here, but what exactly is the problem
that this PEP is trying to solve? Every package manager I'm aware of
covers all the questions in the "Requirements" statement, with the
possible exception of "Where can I download a new version?" I always
manage to find a place to stick that info (VENDOR, HOTLINE, or some
such), so it _can_ be grafted into the PEP241 metadata usage for
binary packaging. This is exactly why I wrote bdist_packager (patch
#415226).  So that module authors could provide metadata in a single
unified manner which Distutils bdist commands can slice and dice
appropriately for each supported package manager.

Think about this, please. If you are going to continue a python
repository of this scale, are you going to discontinue support for
native binaries? It just doesn't make sense to do both.

mwa