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

[PJ Eby]

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?


> There is an interesting but long discussion at
> http://python.6.n6.nabble.com/Re-Python-Dev-PEP-365-Adding-the-pkg-resources-module-td1995421.html
>
> GvR starts off by wishing it wasn't 1700 lines long. It seems "easy to
> review" was a more important factor than the specific name of any
> particular feature, except for "easy_install" which was seen as too
> much of a setuptools brand name.

He also said egg support in the stdlib was controversial, in part
because there were so many individual things that would be being
blessed.  However, there are now PEPs covering a lot of those things,
like versioning standards, metadata, etc.  In any case, I doubt that
distlib would be a problem just because it can be *extended* to
support eggs.  In fact, he was fine with PEP 365 supporting
*installing* setuptools, just not *including* setuptools.


> 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.  ;-)