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. _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
