JAR equivalent in Gordon McMillan's Installer

[Paul Moore]

On Sat, 16 Feb 2002 12:52:55 +0000, Paul Moore
<gustav at morpheus.demon.co.uk> wrote:

>I'll go and work through all the suggestions I have and come up with
>something suitable. I'll report back on what I manage to produce.

I've had a play with the various options, and mulled the whole thing
over a bit. The conclusion I've come to is that it's certainly possible
to do the sort of thing I'm after, but it's probably too messy (at the
moment) to make it worthwhile.

One thing I discovered is PEP 273, which proposes to allow zipfiles on
sys.path. This is proposed for Python 2.3, and would make zipping up
.py[c] files a much more reasonable option - until this gets
implemented, the necessary import hacks to load modules from a zip file
are possible, but messy. I'll wait for the official implementation...

Getting "resources" out of a zipfile is relatively simple. The zipfile
module lets you get at the data, and StringIO lets you wrap it as a
file-like object. There are still a few issues, though...

1. The data is read in "binary" (with \r\n line terminators on Windows).
StringIO wraps this "raw", which could be a problem if you are getting a
textfile resource, and need to read in text mode. The simplest answer is
to do a data = data.replace("\r","") before wrapping the data.

2. All the data gets read into memory, which could be an issue for big
chunks of data. Translating text files as in (1) above creates a second
copy - more memory used.

Looking at specific types of data

Text data - No real problem. Read as a string, or wrap as a StringIO.

Sound - Not a problem on Windows, as the winsound module takes in-memory
data as an option.

Images (PIL) - Not a problem, as PIL constructors can take a file-like
object as well as a filename.

Images (wxPython) - A bit messy, the simplest way is to go via PIL.
(This leads to yet more in-memory copying, so it may be a problem for
big images...) The next version of wxPython is likely to contain
constructors which take file-like objects, so things will be simpler
then...

One obvious point is that you have to code specifically for reading from
a zipfile rather than from the filesystem. This is a nuisance, unless
you write a wrapper class which lets you choose filesystem vs zipfile at
runtime.

Fredrik Lundh's Squeeze package lets you pack up Python code and data
files in a single archive, and read datafiles from the archive at
runtime. It's almost exactly what I'm after. It uses an internal data
format rather than standard zipfiles - a reasonable decision, but not
quite what I was aiming for.

The basic feeling I get is that there are loads of ways of doing this
sort of thing. None of them are too hard, but on the other hand, there
isn't one "off the shelf" standard way of doing this, so it would be
necessary to code what you wanted into your application (or more
sensibly, as a reusable component which you use in your application). In
most cases, I suspect it's not worth the bother for any specific
application.

I could see some value in a PEP to propose a standard way of doing this
sort of thing - probably as a library module, maybe with some sort of
core support. But I don't know that anyone's likely to feel strongly
enough to push it. (I don't think I am...)

Thanks for all the suggestions and comments, it was an interesting
exercise...

Paul.