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. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 27 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2009-03-19: Released mxODBC.Connect 1.0.1 http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ 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
