On Mon, Mar 24, 2008 at 8:33 PM, Floris Bruynooghe <[EMAIL PROTECTED]> wrote: > 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? 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?
Has the question of "what does it mean to be installed?" been discussed yet? To me it seems that "python setup.py install" constitutes installing something, but what about "python setup.py install --prefix=~/python-packages" or the various schemes (PYTHONPATH, .pth files) to modify sys.path? A possible way to accommodate the possibly distributed nature of a python installation would be for every directory in sys.path to get its own database so that a first-class environment can be constructed from sys.path manipulations. But what about packages that have simply been placed on sys.path without using distutils? Is it even conceivable that they could be registered? One way to be flexible here is to construct the database by scanning the sys.path for packages and modules with PKG-INFO (ignoring the specifics of how they present it for now), caching in each sys.path directory the database of its own local contents. This way, you could rebuild the database to reflect the current state (including any manually copied packages) when and if desired. _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
