[Python-Dev] PEP 365 (Adding the pkg_resources module)

Paul Moore p.f.moore at gmail.com
Mon Mar 17 18:48:45 CET 2008


On 17/03/2008, Guido van Rossum <guido at python.org> wrote:
> On Mon, Mar 17, 2008 at 11:55 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> >  Is it *wanted* that eggs are being supported by core Python?
>
> No. There will be no egg support in the standard library.

This bothers me somewhat. At a certain level, all that egg files are
is zip files with a different extension - and the zipimport module and
PEP 302 certainly do support them. There is a lot more conceptual
baggage associated with the egg "brand name", but unless that extra is
clearly specified, a statement like "there will be no egg support"
doesn't mean much.

My view on PEP 365 is that it offers a standard way of doing

    from pkg_resources import resource_string
    foo_config = resource_string(__name__, 'foo.conf')

which is basically a version of

    foo_config = open(os.path.join(os.path.dirname(__file__),'foo.conf').read()

which also supports PEP 302 importers such as zipimport. This has
nothing to do with eggs, and everything to do with solidifying the
support for cleanly handling PEP 302 importers.

For me, that would be far more useful that a package
download&installer (as I'm on Windows, I tend to use bdist_wininst
installers, and a bootstrap module which gave no uninstall capability
would suck for me).

The sticking point here, is deciding what parts of pkg_resources are
OK, and which constitute "egg support". It may not be possible to come
to a clear understanding of this.

But I remain -1 on any module that just does download and install,
with no uninstall capability. I don't like *eggs* for precisely this
reason!

Paul.


More information about the Python-Dev mailing list