How Esky Works

When properly installed, the on-disk layout of an app managed by esky looks like this::

prog.exe                     - esky bootstrapping executable. This is the file to run.
                               It will automatically check for updates, and the hand over the execution
appdata/                     - container for all the esky magic
  appname-X.Y.platform/      - specific version of the application
    prog.exe                 - executable(s) as produced by freezer module
    library.zip              - pure-python frozen modules
    pythonXY.dll             - python DLL
    esky-files/              - esky control files
      bootstrap/             - files not yet moved into bootstrapping env
      bootstrap-manifest.txt - list of files expected in bootstrap env
      lockfile.txt           - lockfile to block removal of in-use versions
    ...other deps...
  updates/                   - work area for fetching/unpacking updates

This is also the layout of the zipfiles produced by bdist_esky. The "appname-X.Y" directory is simply a frozen app directory with some extra control information generated by esky.

To install a new version "appname-X.Z", esky performs the following steps: * extract it into a temporary directory under "updates" * move all bootstrapping files into "appname-X.Z.platm/esky/bootstrap" * atomically rename it into the main directory as "appname-X.Z.platform" * move contents of "appname-X.Z.platform/esky/bootstrap" into the main dir * remove the "appname-X.Z.platform/esky/bootstrap" directory

To uninstall an existing version "appname-X.Y", esky does the following * remove files used by only that version from the bootstrap env * rename its "bootstrap-manifest.txt" file to "bootstrap-manifest-old.txt"

Where such facilities are provided by the operating system, this process is performed within a filesystem transaction. Nevertheless, the esky bootstrapping executable is able to detect and recover from a failed update should such an unfortunate situation arise.