On 16 September 2012 18:41, Daniel Holth <dho...@gmail.com> wrote: >> This is easy to work around in brand new code using pkg_resources, so >> it's generally only a problem with older code, or code which can depend >> only on the stdlib. Unfortunately, the stdlib doesn't have much to help >> here. There's pkgutil.get_data but it doesn't really work well if you >> need to get a filelike handle to a resource, or you need to list the >> contents of a directory, and other things which pkg_resources does very >> nicely, so it seems like Python isn't really serious about allowing code >> in zipfiles to be a viable alternative to file-and-directory-based code. > > I got the impression that killing zip imports is an explicit goal of > packaging. This is sure to be a contentious issue.
I think packaging possibly only considered installing *to* filesystem locations. But that's no different from distutils - at worst, packaging explicitly ignored the setuptools features around creating eggs (importable zip formats). It's not that you can't do it, just that packaging didn't want to get sucked into that area and so you're on your own. Python *itself* very definitely supports zip imports. And with the new implementation of the core import machinery using importlib in Python 3.3, it goes a lot further, supporting imports from any locations you care to write the code for. There's no core support for putting your package into (say) a sqlite database, but once it's in there, the core supports you adding hooks in so you can put that sqlite database on sys.path and have it "just work". That's a huge amount of flexibility, and no-one has even scratched the surface of it yet. Paul. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig