Re: [Distutils] Package DB: strawman PEP
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.
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
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 well there is stuff in the registry related to installations and shared
In article <Pine.LNX.4.21.0107111642190.8041-100000@llave.eproinet.com>, Mark W. Alexander <slash@dotnetslash.net> writes ... dlls have some kind of user count there too. There's also a registry folder containing information about uninstall info. In my Win2K for example I can't find python21.dll in the shared modules list. Somewhere there must be an explanation of how and what is supposed to be done by an installer. -- Robin Becker
From: "Robin Becker" <robin@jessikat.fsnet.co.uk>
well there is stuff in the registry related to installations and shared dlls have some kind of user count there too. There's also a registry folder containing information about uninstall info.
In my Win2K for example I can't find python21.dll in the shared modules list. Somewhere there must be an explanation of how and what is supposed to be done by an installer.
All this is only a convention on windows, there is no package manager enforcing these things. - The registry contains reference counts of shared dlls, the installers and uninstallers have to maintain them and observe them. - The registry contains some entries which will show up in the add/remove programs control panel applet, and a command line which will start the deinstaller. The deinstaller itself has to be provided by the installer, and the installer always has to feed the deinstaller with information about files to delete, registry entries to remove, and so on. The WISE installer, for example, has this information in the INSTALL.LOG file, Installshield has something like uninst.isu, and so on. bdist_wininst installers write 'Remove<package>.exe' as the uninstaller, and '<package>-wininst.log' has the list of files and directories installed. (All this may be different with the new windows installer service, but I don't know much about that) Thomas
participants (4)
-
Mark W. Alexander -
Mats Wichmann -
Robin Becker -
Thomas Heller