Packaging packages?

[Gordon McMillan]

Michael P. Reilly wrote:

> Fredrik Lundh <fredrik at pythonware.com> wrote:
> : Jeffrey Kunce <kuncej at mail.conservation.state.mo.us> wrote: :>
> Is there a way to collect all the python modules in a package
> into one file? 

> : you can use Greg Stein's imputil.py [1] for this.  see
> : my reply in the recent "Embedding questions" for a
> : code sample.
> 
> :> I've been a big fan of Fredrik's "Squeeze" and Gordon's "Win32
> Installer", :> but as far as I know, they pakage an entire
> application into one file. :> I'm looking for a little more
> modularity than that, and something that :> can be imported from
> native python.
> 
> : iirc, Gordon's stuff is about as modular as it can be.
> : using it to create library packages shouldn't be much
> : of a problem.

> Last summer I also created a native (or C) implimentation of
> something similar to what was describe in the distutils SIG,
> something I called Spamcan.  It's not as extensive as Gordon's
> Installer but is a little more portable (works on just about any
> platform).  The purpose of this module was to have something
> similar to JAR files, so the can file only stores PYC files.  The
> general consensus on the distutils list was that something more
> generic was needed (pyz) so I didn't really spend more time or
> even announce it (Gordon's technical implimentation was more
> versatile than mine).

Actually, that part of my Installer package is portable. To be 
more precise:
 ZlibArchives (including the "building" stuff) work anywhere that 
you have zlib, and the base Archive class should work 
anywhere, period. This includes building on one machine and 
running on another.
 CArchives (which can contain anything) are inhibited by 
endianness issues (and perhaps alignment issues). But, for 
example, I can build a CArchive on Windows and use it on a 
386 Linux.
 The trick of appending a CArchive to the executable is only 
known to work on ELF / COFF platforms.
 The further trick of sticking binaries into the CArchive and 
unpacking them / loading them on the fly (self extracting 
executables) only works (and is only culturally appropriate) on 
Windows.

 I have the "standalone" configuration working on Linux. In this 
configuration, everything is in one directory: you have an 
executable with all the pure Python resources appended to it, 
and all the C extensions in one directory, with absolutely no 
interference from existing Python installations. I'll be releasing 
this when I get my head above water.

And, to emphasize Fredrik's points, this all relies heavily on 
Greg's imputil, and it comes in three distinct layers, with 
(learning_curve, flexibility) in [(None, tiny), (moderate, 
moderate), (large, large)].

- Gordon