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). _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
