[Python-Dev] "setuptools has divided the Python community"
pje at telecommunity.com
Thu Mar 26 22:33:10 CET 2009
At 03:28 PM 3/26/2009 -0500, Guido van Rossum wrote:
>2009/3/26 Barry Warsaw <barry at 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.
More information about the Python-Dev