[Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
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/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.
More information about the Python-Dev
mailing list