At 12:33 AM 3/25/2008 +0000, Floris Bruynooghe wrote:
On Mon, Mar 24, 2008 at 04:57:44PM -0400, Alexander Michael wrote:
With that preamble, here's my attempt at an explicit rationale for a database of installed packages (A.K.A. The New PEP 262):
Nice effort, thanks.
Rationale ========= It is often necessary during the course of managing a python installation for an administrator to determine the following things:
1. If the current installation state satisfies the requirements of a new package being considered for installation. 2. If it is safe for the administrator to upgrade or remove a package, and if so, how (e.g. use a system-level package management tool). 3. What files to remove in order to uninstall the package (if a system-level package management tool was not used to install it). 4. If the current installation was modified in-place or custom configured in an way, so that such changes can be noted before upgrading.
I agree with 1 and 2, but 3 and 4 are optional I think. They are not important for the different tools to interact AIUI. As long as everyone only removes files they own all is fine.
Not quite - it's necessary to know which files are owned by a given package or tool in order to do this. If you are installing a package, you need to know who owns any files that you're about to overwrite.
Something that this requirement should probably explicitly describe: does this database only concern modules, i.e. installed in a directory that's on sys.path?
It will probably need to include scripts, data, etc.
My understanding is that it does. However I'm unsure as to how that can be combined with supporting applications that require certain modules. Would every tool need to keep track of the apps it installed separately to make sure that, when it's used to uninstall a module, it doesn't render an app that it installed useless?
To tie in another part of this discussion, this could mean that module installation is forced to be a simple list of files while still allowing a Turing complete installer for applications.
These are currently open issues.