Add .par functionality (like Java .jar)

[Johann Höchtl]

Paul Moore wrote:
> 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...
> 
I was not thinking about any external ressources a python program will 
eventually require like bitmapped data for graphics or architecture 
dependent libraries (.so, dll).

> 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".
> 
I spent some time to see how it is done in java. There, a standardized 
file in a standardized directory within the jar(zip)-archive is read and 
interpreted. This file can carry a bunch of information, for example the 
startup-class or the CLASS-PATH which serves as the startpoint of execution.

http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html


Once this file is loaded, it can import dependencies without knowing 
whether it was started from the file system or jusing the 'jar-lever'.

I think you mean package the main .py- file with all the other modules 
which are now in a zip file together and let the main.py file care about 
it's imports.

IMHO this is bad design as the startup.py has to care whether is is 
loading it's modules from the directory (and relying on standard python 
mechanism) or from a python-zip package.

The consequence is that already python(.exe) has to have the knowledge 
to inspect the archive and see if there is a startup-script in it.

I am a python beginner and i don't yet know if it would be a problem to 
name this file __init__.py like packages in a directory.

> 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.
> 
I visited the site. Packaging the whole interpreter is maybe still 
necessary for MS-Windows, on UNIX-Systems python can already be assumed 
to be available without having especially asked for it. (I wouldn't 
wonder if SuSE or Slackware 8 give a dependency warning when i try to 
deselect python) Reminds me of the time three years ago or so, when java 
applications came with JRE pre-packaged. Nowadays it's assumed to be 
installed.

> 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

That's already near at the goal, but it's not self-contained. You have 
to put this line into a unix semi-executable +x or create a shortcut in 
a GUI.
> 
> 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,

Thank's a lot for your explanations. I am still a Python beginner. After 
a year of language (re-)search I think I finally ended up with Python 
and I'm happy that I didn't get stuck with Java ....

> Paul.
> 
>