Add .par functionality (like Java .jar)

Paul Moore gustav at morpheus.demon.co.uk
Thu May 23 06:29:34 EDT 2002


Johann Höchtl <big.john at bigfoot.com> writes:

> As SourceForge doesn't allow to add a featur erequest without beeing
> logged in, i post it here:

Why not log in? It's not hard...

> Summary:Add .par functionality (like Java .jar)
> 
> Detailed Description:
> This feature would make people extremely happy to be
> able to download a single file, double-klick (either on
> windows or gnome/kde) and see what python can do for them.
> 
> (Assuming, that a python interpreter is installed)

This has come up a number of times. Most of the pieces are already in
place. You can write an import hook now, to allow import from Zip
files. PEP 273 formalises this and makes it part of Python, but that's
all.

Loading data from a zip file is a little harder, but here's a class
that (mostly) works.

class Resource:
    def __init__(self, filename):
        self.zip = ZipFile(filename)
    def __del__(self):
        self.zip.close()
    def read(self, filename):
        return self.zip.read(filename)
    def open(self, filename):
        return StringIO(self.zip.read(filename))

Just use as

    z = Resource("test.zip")

Then to get the complete data from a particular file in the zip, just
do data = z.read("filename") or to get a file-like object, just do f =
z.open("filename"). You have problems with stuff that needs a *real*
file, but there isn't much around that you can't work round one way or
another...

The main lack is the ability to handle compiled extensions, but you're
never going to get that without OS support. Just ship the necessary
.dll/.so files separately, and manipulate sys.path, if you need to.

For true one-file-to-run functionality like JAR files, all you really
need is to package the main driver script plus the zip file
together. As zip files can have arbitrary content tacked on the front,
just concatenating the script and the zip file should
work. Unfortunately, the Python interpreter chokes on trailing garbage
:-(

You can work around *this* on Windows by embedding a CTRL-Z character
(Python opens scripts in text mode, and CTRL-Z is EOF in text mode)
but I don't know how to do it on Unix.

So the only remaining pieces of the puzzle are:

1. Find a way of combining a driver script plus a zip file.
2. Formalise this, if you want, to come up with a "standard".

There are a number of options for part 1 (custom executable with
Python embedded, encode the zipfile as text and decode on the fly at
script startup, etc etc). Gordon McMillan's Installer does all this,
but it takes it a few steps further, by searching out dependencies,
rather than relying on an installed Python interpreter. So there are
ideas there, if you want to look.

It would be nice to have an option in the existing Python interpreter,
but I'm not sure it's needed. With PEP 273, all you need may be

    python -c "import sys; sys.path.insert(sys.argv[1]); import Main; Main.main()" myfile.zip

Part 2 is the important one. If you really care about making this a
*standard* feature, you have to persuade people to do it in the same
way each time, rather than reinventing the wheel. Personally, I would
like to see one-file Python applications which worked like jar files
become common - it irks me that people view this as something clever
that only Java can do - but I'm not motivated enough to push what is
essentially a "political" issue rather than a technical one.

So, in summary: You have my support, but it's not so much a feature
request as an (informational) PEP describing a standardised
technique. If the standard becomes popular, I can see Python growing a
command line switch to simplify the process, just like Java did
(executable Jars came with JDK 1.2, IIRC, but jarfile technology was
there from day 1...)

Hope this helps,
Paul.




More information about the Python-list mailing list