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.
_______________________________________________
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
