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