[Distutils] Package DB: strawman PEP

[Mark W. Alexander]

On Tue, 10 Jul 2001, Mats Wichmann wrote:

> At 02:33 PM 7/9/2001 -0400, Mark W. Alexander wrote:
>  >On Sun, 8 Jul 2001, Andrew Kuchling wrote:
>  >
>  >> It seems time to bite the bullet and actually begin designing and
>  >> implementing a database of installed packages.  As a strawman to get a
>  >> focused discussion started, here's a draft of a PEP, with lots of
>  >> XXX's in it.  Followups to the Distutils SIG, please.
>  >
>  >I'm confused. Why? What does this give us that native package managers
>  >don't. How is it going to keep synchronized with package manager?
> 
> One problem is that native package managers don't make sense for
> everything.  I can't imagine wanting to even deal with many of
> the package managers out there for a smaller Python package. I'm
> not even convinced that one of the major entrants out there - the
> Windows one - does a reasonable job with dependencies, but I'm
> pretty ignorant there.  And even small packages - a few Python source
> files - might want to check for prereqs.

Uhm, ok, I'll admit in my (non)Windows-bias that I didn't consider
_that_ one. Although in my ignorant defense, I have to ask: Does
Windows have what we've come to think of as a package manager? I know
there's information in the registry, and that an installer can check
to see if required dependencies are installed, but is there native
support to prevent the removal of those dependencies once the
dependent package is safely installed. In my experience, if there is,
it doesn't work.

The issue that I have is that when you go to manage software on a
machine, any time there is more than one place software information
may be stored you never know what's there unless you look in both.
Once you've got multiple places, automation goes out the window.
Building a python-specific module-manager is fine from a single-system
viewpoint, but in an enterprise with large numbers of heterogenous
systems, managing another repository on every machine is a nightmare.

Mark