Hi all, I've taken Greg Stein's "small" distribution and (with his advice(*) and help) created a mechanism for building compressed single-file importable python libraries. This is cross-platform, depending only on zlib (and Greg's imputil.py). There are a number of ways you can create these archives - grabbing directories, packages or computing the dependencies of a particular script. Then, for Win32 users, I've taken it a few steps further. I've mixed this with Christian Tismer's sqfreeze (based on /F's squeeze) and freeze and created a compiler-less Python installer. You can also use it much like freeze, except you don't need a compiler. The major difference is that, once installed, it won't be a completely standalone executable. The installer will unpack the dependencies into the exe's directory. There will be no dependencies outside that directory(**). You can pack in extension modules, dlls and anything else you like. The python lib support will be contained in a single archive file. So the equivalent of a frozen pure-python script would be one self-installing exe that expands to 5 files - the "squeezed" main script, python15.dll, zlib.dll, zlib.pyd and your private support lib (something.pyz). Check it out - http://www.mcmillan-inc.com/install.html Oh yes, while the code has my copyright, it's released under a do-what-you-want license. Mostly, I glued together what others had done (freeze, sqfreeze, Greg's stuff...). - Gordon (*) Not always followed. Don't blame Greg. (**) Note that if you want to install something that makes use of Mark's COM extensions (particularly, Python COM servers), you can't get away with this.
Hi Gordon, I had a look - nice thingy. Maybe this is the way to do it. I resisted to unpack everything from the C starter and was more heading into having Python up before the installation process. This would make it possible to be much smarter when it comes to decide which files to pull out, where they should go etc. I think this part should already be Python. Therefore I spent time on how to build Python stand-alone, linked with zlib. But maybe your way is the better one. My target was to keep as many files as possible in the .exe and use is as a repository, acting as a vitual file system. Redirection to a fake file system should be easy with Greg's module. Only the dlls must be pulled out, there is no chance to avoid this. I thought of /windows/temp for them. Your cookie looks funny. I looked at it from a dos window and I'm trying to figure out what the meaning of 'MEI' plus all the male/female symbols could be :-) ciao - chris -- Christian Tismer :^) mailto:tismer@appliedbiometrics.com Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home
Christian Tismer wrote:
... My target was to keep as many files as possible in the .exe and use is as a repository, acting as a vitual file system. Redirection to a fake file system should be easy with Greg's module. Only the dlls must be pulled out, there is no chance to avoid this. I thought of /windows/temp for them.
Yes, a simple variation on a theme uses win32api to read resources out of the .exe. Unmarshal the string to get a code object and return it (maybe decompress before unmarshal). imputil.py takes care of the rest, once you can return a code object. I suspect the Importer to use Win32 resources is a dozen lines or so. Cheers, -g -- Greg Stein, http://www.lyra.org/
Christian wrote:
I had a look - nice thingy.
Thanks. ...
My target was to keep as many files as possible in the .exe and use is as a repository, acting as a vitual file system. Redirection to a fake file system should be easy with Greg's module. Only the dlls must be pulled out, there is no chance to avoid this. I thought of /windows/temp for them.
The only difference between Launch.exe and Run.exe is that Run removes everything it pulls out at end of run. Of course, if you don't reach end of run, it'll leave everything lying around. If you wanted to do a _really_ self contained virtual file system, then the "stuff" should be a valid section in the exe, and the C should get a pointer to the section. No file needed, but you would have to patch the exe. But since they're just tacked together and we open the exe as a file to find everything, it didn't seem worth it to add the smarts for nested packaging.
Your cookie looks funny. I looked at it from a dos window and I'm trying to figure out what the meaning of 'MEI' plus all the male/female symbols could be :-)
MEI stands for "McMillan Enterprises Inc.". The male symbols are an obvious expression of the phallic nature of structs; I'd guess the female symbols are evoked by the matriarchal nature of ANSI societies. or-maybe-it's-the-Freudian-nature-of-Deutche-dos-boxes-ly y'rs - Gordon
participants (3)
-
Christian Tismer -
Gordon McMillan -
Greg Stein