Gordon McMillan's Installer - Data files in the archive

[David Bolen]

Paul Moore <gustav at morpheus.demon.co.uk> writes:

> Given that you can do this, how do you get at the file from within
> your application?
> 
> In a --onedir build, the data files are part of the directory, so you
> can just find them via sys.executable. But in a --onefile build, how
> do you get at them?

In a onefile build, all the auxiliary files are automatically unpacked
(into the directory with the executable I believe) as the executable
starts up, and then removed at the end.  So you should be able to
assume the data file will be in the executable directory in either
case.

> Also, can you make a --onedir build include data files in the
> generated EXE, not as separate files?

There's probably two ways I can think of doing it:

* The default launch routines always unpack binary (type "b") TOC
  entries in the executable CArchive upon startup.  So if you define
  your data files as type BINARY instead of DATA, and include them as
  arguments to your EXE() class they'll get included.  Oh, don't
  forget to to set exclude_binaries to 0 in the EXE() call (which may
  be the default for --onedir).  I just tried this myself and it seems
  to work fine, although my preference would be to keep them as DATA
  but that would require modifying the launch routines to extract data
  (type "x") as well.

* Include the files as DATA modules into the archive (again by
  supplying them to the EXE() construction), but access the files
  directly from the archive during run time.  You can open your own
  executable using the CArchive routines from installer, and simply
  access whatever entries you want.  Of course, this assumes that the
  files are reasonable to decompress/load into memory.  Otherwise you
  could extract them yourself when needed to disk.

> On a (semi-) related note, is it possible to make Installer *not*
> track dependencies back into the installed copy of Python, and so
> produce executables which assume the existence of an installed copy of
> Python on the target system? For a simple test application using
> wxPython, the base EXE in a --onedir build was 350K, whereas the
> support DLLs were nearly 8M. If I'm only distributing to people who I
> can rely on to have Python and wxPython installed, the saving in
> bandwidth is enormous. (OK, so I could send out a ZIP of the
> application plus data files, but a single-file "just run this EXE"
> distribution really is a good thing...)

I've also wanted to do this but haven't had a chance to run tests, so
this is just my thinking on how I would do it when I get time.

The stuff that locks down the Python environment to the executable
directory is all part of the launch.c module (mostly in startPython())
included with installer.  So modifying that slightly (e.g., not
completely resetting sys.path) should permit it to locate modules
elsewhere on the system.

For more detailed discussions you might also try the installer mailing
list at installer at mi5t.com (see
http://trixie.triqs.com/mailman/listinfo/installer for subscriptions).

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/