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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4