[Distutils] [Python-Dev] how to easily consume just the parts of eggs that are good for you

[Phillip J. Eby]

At 09:42 PM 4/9/2008 +0100, Floris Bruynooghe wrote:
>On Wed, Apr 09, 2008 at 03:57:13PM -0400, Phillip J. Eby wrote:
> > At 10:30 AM 4/9/2008 -0700, zooko wrote:
> > >where I would prefer either:
> > >    a.  Doing away with database files entirely and relying on the
> > >filesystem alone to hold that information, or
> >
> > ...which is what PEP 262 *does*.
> >
> > Unfortunately, PEP 262's title is bad for marketing, as you've
> > effectively pointed out.  It would be better titled something
> > "package installation manifests" or "package contents files", or
> > something of that sort.
>
>Heh, *package* appears in both of your suggestions.  Surely this means
>tools that want to support installing script or data files need to
>keep their own manifests separately.  This would greatly simplify any
>PEP 262 style implementation.

Sadly, "package" has the additional meaning of "thing you distribute" 
in a distutils "distribution".

At this point, btw, I've pretty much come to the conclusion that the 
simplest way to solve the installdb problem is just going to be for 
setuptools to do its own thing, yet again.  :(

The only piece of the puzzle left, then, is the namespace package 
bit, but at least there the problem space has narrowed 
considerably.  The only issue there will be how to make the new 
(non-egg) installation method interoperate with the existing 
nspkg.pth solution.

And even there, the only problem to resolve is if you install 
something to a PYTHONPATH directory that shares a namespace with a 
system package.  Currently, the only way I know of to fix that would 
be to ensure that the PYTHONPATH directory supports .pth files, and 
to install an appropriate .pth there as well.  (Where "appropriate" 
means, an even hairier hack than today's nspkg.pth files.)

I'd really like to avoid that, if possible.

It would be best if we could solve the virtual-package thing in 
co-operation with the major system packagers (meaning the people, not 
just the tools).