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

[Phillip J. Eby]

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/the_data
>    (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.