RetroSearch Browse

Fri Mar 27 17:07:58 CET 2009 · https://mail.python.org/pipermail/python-dev/2009-March/087814.html

At 11:37 PM 3/26/2009 -0500, Eric Smith wrote:
>P.J. Eby wrote:
> > As someone else suggested, moving some of the functionality to PEP 302
> > interfaces would also help.  Most of the code, though, deals with
> > locating/inspecting installed distributions, resolving version
> > requirements, and managing sys.path.  And most of the nastiest
> > complexity comes from trying to support true filename access to
> > resources -- if that were dropped from the stdlib, there'd be no need
> > for egg caches and the like, along with all the complexity entailed.
> >
> > Application environments such as Chandler, Trac, Zope, etc. that want
> > their plugins to live in .egg files wouldn't necessarily be able to use
> > such an API, but the independent pkg_resources wouldn't be
> > disappearing.  (Of course, they could also implement
> > application-specific file extraction, if the stdlib API included the
> > ability to inspect and open zipped resources.)
>
>Could you comment on why they couldn't use such an API?

If a plugin includes C code (.so/.dll), or uses a library that 
operates on filenames rather than bytes in memory (e.g. gettext), 
then the resources would need to be extracted from the 
.egg.  pkg_resources transparently extracts such resources to a cache 
directory when you ask for a resource's filename, rather than asking 
for a stream or string of its contents.

This feature represents a significant chunk of the complexity and 
code size of pkg_resources -- and I was proposing ways to cut down on 
that complexity and code size, for a (limited) stdlib version of the 
functionality.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2009-March/087814.html below:

[Python-Dev] "setuptools has divided the Python community"