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

P.J. Eby 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 mailing list