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

[Eric Smith]

M.-A. Lemburg wrote:
> On 2009-03-27 17:07, P.J. Eby wrote:
>> 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.
> 
> This functionality is one of the more annoying setuptools
> "features". It causes each and every user of e.g. Trac to have
> their own little version of the same piece of software in their
> home dir cache.
> 
> The solution to this is simple: don't use ZIP files for installed
> packages, instead unzip them into normal directories on sys.path.
> 
> This makes all these problems go away and allows users to access
> embedded documentation, configuration, etc.
> 
> Zip files are great for shipping packages to the end-user, but
> there's no need to keep them zipped once they get there.
> 

I also think the feature should go. If you want functionality that's so 
difficult to provide when you install as a zip file, the answer is not 
to make things more complex, but to not install as zip files.