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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
