[Distutils] [Python-Dev] How we can get rid of eggs for 2.6 and beyond

[Alexander Michael]

On Mon, Mar 24, 2008 at 8:33 PM, Floris Bruynooghe
<floris.bruynooghe at gmail.com> 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.