[Distutils] distlib updated to include "entry point" functionality

Daniel Holth dholth at gmail.com
Thu Oct 11 01:05:24 CEST 2012

On Wed, Oct 10, 2012 at 6:15 PM, PJ Eby <pje at telecommunity.com> wrote:
> On Tue, Oct 9, 2012 at 7:53 PM, Daniel Holth <dholth at gmail.com> wrote:
>> would also like to be able to store my installed package database in
>> sqlite3 by implementing an appropriate distlib/pkg_resources backend
>> and defining a standard post-(un)install "index this new package" hook
>> but I doubt I will have the (unfunded) time.
> How would a database even work in that scenario (given multiple
> independent directories on sys.path), and why would you expect it to
> perform better than a modern filesystem?

I don't know, but it would be interesting to try. For example the
operation that parses every RECORD (list of installed files) to do
reference counts on uninstall would probably be much faster in a

>> Wheels are designed to be valid sys.path entries in the simple case.
>> We don't encourage you to do so mostly because we don't want to
>> include .pyc files for all the Pythons you might use,
> Wait...  isn't wheel a binary format?  Oh, I see what you mean, wheels
> are a *fat* binary format, so they can include multiple Python
> versions and multiple platforms.
> However, for the application platform plugins use case, wheels can
> potentially be quite awesome, because you can build one fat wheel for
> all your supported platforms.  "We don't want to inlcude .pyc files
> for all the Pythons you might use" doesn't apply to the "we" who
> already build and release different platform-specific eggs to cover
> multiple platforms and Python versions.  ;-)

If you were using wheels to implement a plugin system you could append
.pyc files to the archive later, put up with slower start times, or
unpack each wheel into a separate folder.

A frustrating thing about eggs was that you had to replace them all
even for pure-Python distributions when a new Python was released. A
single wheel could mark itself as being compatible with Python
2.6-3.3, and we just let the user create the .pyc.

The "fat" part has been left out of the implementation so far. The
tags just mark a single wheel as working with several Pythons, usually
only true for pure-Python dists. There is no provision for installing
a different set of files based on the installation platform.

More information about the Distutils-SIG mailing list