At 03:28 PM 3/26/2009 -0500, Guido van Rossum wrote:
2009/3/26 Barry Warsaw <ba...@python.org>:
> BTW, under a better name, I would support putting pkg_resources in the
> stdlib.
Last time I looked it was an incredibly complicated piece of code that
would have to be refactored considerably before it would be
maintainable by the core developers. I never did manage to get a good
understanding of the code, but I expect that a lot of the complexity
exists so that it works for all Python versions. The stdlib version
shouldn't need this -- it should only care about providing a stable
API that works with the current version.
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.)
The other significant source of complexity is dynamic management of
namespace packages; specifically, trying to handle the situation
where new sys.path entries (e.g. .egg files added as plugins) need to
have their contents added to existing sys.modules __path__
entries. This is perhaps another feature that could be dropped from
the stdlib version, given a way to interop with pkg_resources or a replacement.
_______________________________________________
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
