Packaging packages?

[Michael P. Reilly]

Gordon McMillan <gmcm at hypernet.com> wrote:
: Michael P. Reilly wrote:

:> 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)].

My first point was that mine is a native _or_ C implimentation
(read/write compatibility).  Last summer you would only make the docs
and a win32 installer available (I even asked and just got that info),
so I just had the docs to go on; you still only mention Windows and
Linux.  My second point that your format implimentation in CArchive was
more usable than mine.

I didn't object to your module, or publish mine, last summer because I
thought CArchive had potential, just not complete (considering I could
only get design specs).  Mine was more akin to your ZlibArchive, which
is also why I didn't mention mine last summer.

You concentrate too much on encapsulating everything into one file -
archive, executable, etc.  As you say, this is only useful for Windows,
useless for anything else.  Mine concentrated in encapsulating modules
and packages into one or more "cans" to allow transparent loading
(adding the filename to sys.path directly).  Different approaches.

I do not care at all for imputil, but made my module compatable with
it.

  -Arcege