Re: PEP 262: Database of Installed Python Packages
On Wed, 27 Mar 2002, A.M. Kuchling wrote:
A package database is a necessary prequisite for managing the Python packages installed on a system. PEP 262 lists the requirements for such a database and specifies a storage format for it.
I'd like to get this into Python 2.3, hopefully with a still-to-be-specified package management tool. Assuming no one points out some requirement or use case missing from this draft of the PEP, my next step will be to write a proposed interface, post that draft, and then implement the PEP and integrate it with the Distutils.
Comments can be posted to comp.lang.python or to the Distutils SIG.
Here is an item for the wishlist: Installing a new package and recording its name and file-list in a database is one thing. RPM does that. Easily maintaining a package-based system is another. APT+DPKG does that thanks to all the features it has over RPM (downloading the list of available packages from a mirror of the unified repository, checking integrity, calculating dependencies, etc.), but also thanks to the work of hundreds of debian developers that take care of all the dependencies between packages and upload their packages to a central coherent repository. I would be cool to have the equivalent for Python. We more or less already have that with Debian, for Python extension packages are packaged as Debian packages and can be upgraded on one debian host with a single ATP command. To my knowledge, APT has nothing DPKG-specific. If what we are after is to let people manage and upgrade their installed python packages. What about replacing DPKG with its Python couterpart and let APT handle the rest of the trouble? Is it really needed to fully implement yet another packaging system? Or is the proposal just about a DPKG-replacement for Python packages and did the mention of APT at the beginning of the PEP lead me to a misunderstanding? My last question: why should we have package management system "internal" to a Python installation. Isn't it the role of the distro to handle packages and should't we focus on helping out the existing distro tools deal with Python extensions instead? My 2 Eurocents. -- Nicolas Chauvat http://www.logilab.com - "Mais où est donc Ornicar ?" - LOGILAB, Paris (France)
On Sat, Apr 06, 2002 at 03:38:08PM +0200, Nicolas Chauvat wrote:
Or is the proposal just about a DPKG-replacement for Python packages and did the mention of APT at the beginning of the PEP lead me to a misunderstanding?
Long-term I would like to see a system which offers much of the same features as APT, so the underlying database needs to store enough information to make that possible, but the PEP only aims at specifying the DPKG-like level of things; a package maintenance interface is left for another PEP.
My last question: why should we have package management system "internal" to a Python installation. Isn't it the role of the distro to handle packages and should't we focus on helping out the existing distro tools deal with Python extensions instead?
What do we do for people on systems without packaging systems such as DPKG or RPM? --amk (www.amk.ca) There are, one presumes, tone-deaf readers. -- Robertson Davies, _A Voice from the Attic_
Nicolas Chauvat asked:
My last question: why should we have package management system "internal" to a Python installation. Isn't it the role of the distro to handle packages and should't we focus on helping out the existing distro tools deal with Python extensions instead?
Then Andrew asked:
What do we do for people on systems without packaging systems such as DPKG or RPM?
I did a bdist_pkgtool for Solaris and a bdist_sdux for HP. The advantage that distutils gives me is that I can get a module and run setup.py for each architecture. After that, everything is native for whatever package system the OS uses. All python packages show up when I list installed packages through the native package manager interface. IIRC, the bdist_wininst is the same. Once installed, packages on Windows show up in Add/Remove programs just like any other installed component. I think this is the way it should be. We don't want to create another layer for admins to manage python packages. For example, if I didn't use native packages on Solaris and HP, but did on Linux, in order to automagically maintain an inventory of installed software on all machines, I'd have to "know" that on certain OS'es to query both the native package manager and the distutils DB. This places an extra burden on administrators should they chose (or be coerced) to support python package users on their systems. If distutils is to help drive the growth of Python to other OS'es, then it needs to make package installation and maintence _exactly_ the same for any other packages on those OS'es. The way to do that is to grow the number of bdist commands until it equals the number of native package managers. By focusing on bdist commands, we don't have to have an "internal" python package management system, and we don't have to deal with non-Python oriented admins that don't care to deal with another way of installing and managing packages. ("Please install this package" is much more likely to be granted than "Can you build this binary for me?") mwa
"Mark W. Alexander" wrote:
Nicolas Chauvat asked:
My last question: why should we have package management system "internal" to a Python installation. Isn't it the role of the distro to handle packages and should't we focus on helping out the existing distro tools deal with Python extensions instead?
Then Andrew asked:
What do we do for people on systems without packaging systems such as DPKG or RPM?
I did a bdist_pkgtool for Solaris and a bdist_sdux for HP. The advantage that distutils gives me is that I can get a module and run setup.py for each architecture. After that, everything is native for whatever package system the OS uses. All python packages show up when I list installed packages through the native package manager interface. IIRC, the bdist_wininst is the same. Once installed, packages on Windows show up in Add/Remove programs just like any other installed component.
I think this is the way it should be.
+1. Also +1 on adding more bdist_* package support e.g. bdist_deb and an extended version of bdist_rpm to accomodate specific settings for various RPM-based distros (if needed).
We don't want to create another layer for admins to manage python packages. For example, if I didn't use native packages on Solaris and HP, but did on Linux, in order to automagically maintain an inventory of installed software on all machines, I'd have to "know" that on certain OS'es to query both the native package manager and the distutils DB. This places an extra burden on administrators should they chose (or be coerced) to support python package users on their systems.
If distutils is to help drive the growth of Python to other OS'es, then it needs to make package installation and maintence _exactly_ the same for any other packages on those OS'es. The way to do that is to grow the number of bdist commands until it equals the number of native package managers. By focusing on bdist commands, we don't have to have an "internal" python package management system, and we don't have to deal with non-Python oriented admins that don't care to deal with another way of installing and managing packages. ("Please install this package" is much more likely to be granted than "Can you build this binary for me?")
Right. -- Marc-Andre Lemburg ________________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
On Tue, Apr 09, 2002 at 05:42:30PM +0200, M.-A. Lemburg wrote:
Also +1 on adding more bdist_* package support e.g. bdist_deb and an extended version of bdist_rpm to accomodate specific settings for various RPM-based distros (if needed).
Ironically bdist_deb is the most significant missing format; apparently it's really difficult to automatically build the right control file. (I don't remember the details; someone interested in taking this on should consult the distutil-sig archives.) --amk (www.amk.ca) Dots [...]: Small marks variously made to indicate infinity, hesitation, duplication, or lack of imagination. -- Peter Greenaway, _Rosa: The Death of a Composer_
On Tue, 9 Apr 2002, Andrew Kuchling wrote:
On Tue, Apr 09, 2002 at 05:42:30PM +0200, M.-A. Lemburg wrote:
Also +1 on adding more bdist_* package support e.g. bdist_deb and an extended version of bdist_rpm to accomodate specific settings for various RPM-based distros (if needed).
Ironically bdist_deb is the most significant missing format; apparently it's really difficult to automatically build the right control file. (I don't remember the details; someone interested in taking this on should consult the distutil-sig archives.)
There's always the functional and completely assinine method of wrapping bdist_rpm with a call to alien. I've considered bdist_deb, but frankly alien has served my needs well enough for the few Debian boxes I have..... ( ^ |____ obligitory dots to comply with amk's sig. Guess which category this proposal falls in) I simply don't have the time for the "right" way, but if an alien wrapper is an acceptable intermediate step, I'll take it on.
--amk (www.amk.ca) Dots [...]: Small marks variously made to indicate infinity, hesitation, duplication, or lack of imagination. -- Peter Greenaway, _Rosa: The Death of a Composer_
mwa
participants (4)
-
Andrew Kuchling -
M.-A. Lemburg -
Mark W. Alexander -
Nicolas Chauvat