[Python-Dev] magic in setuptools (Was: setuptools in the stdlib) (original) (raw)

Phillip J. Eby pje at telecommunity.com
Sat Apr 22 00:32:48 CEST 2006

At 06:43 PM 4/21/2006 +0200, Martin v. Löwis wrote:

They might need to be available outside "Python". Two use cases:

1. The application embeds an sqlite database. Even though it knows how to get at the data, it can't use it, because the sqlite3 library won't accept .../foo-1.0.egg/resources/thedata (or some such) as a database name, if foo-1.0.egg is a ZIP file. If the installed application was a set of files, that would work. 2. The application embeds an SGML DTD (say, HTML). In order to perform validation, it invokes nsgmls on the host system. It cannot pass the SGML catalog to nsgmls (using the -C option) since you can't refer to DTD files inside ZIP files inside an SGML catalog. If this was a bunch of installed files, it would work. 3. The application includes an SSL certificate. It can't pass it to socket.ssl, since OpenSSL expects a host system file name, not a fragment of a zip file. If this was installed as files, it would work.

In all of these cases, the applications could use pkg_resources.resource_filename(), which returns a true OS filename, even for files inside of .zip files. Of course, it does this by extracting to a cache directory in such cases, and is only suitable for read-only access. But it works fine for such cases as these. Passing a resource directory name results in an operating system directory name being returned as well, with all the contents (recursively extracted) therein.

If the application is not in a zip file, then resource_filename() simply returns the obvious results by file manipulation, so the author need not concern him or herself with this in code. They just use resource_string() or resource_string() wherever possible, and resort to resource_filename() when working with tools such as the above, that cannot handle anything but files.

More information about the Python-Dev mailing list