contents

Introduction - 1

Background - 2

Deployment - 3

Starkits - 4

Tclkit - 5

Advanced topics - 6

Repositories - 7

Server apps - 8

Who uses this - 9

Examples - 10

Conclusion - 11

Acknowledgements

References

3 - Deployment

Users have come to accept that computers can be enormous time wasters - especially when it comes to installation of software products and updates. When you think about it, the whole concept of “installation” is artificial and unnatural. When was the last time you installed an appliance like a toaster or kettle? More importantly, why do you need to navigate through a labyrinth of jargon and acronyms just to try a package? And why should you care where it is installed? And when you decide you don’t want it, why is it so difficult to get rid of it and its detritus?

Perhaps the answer is that deployment has been viewed from the perspective of the developer. Consider what is needed when deploying a scripted application:

• a language interpreter for the target platform
• any compiled packages/extensions for the target platform
• any scripted packages/extensions, and finally
• the application scripts themselves

Note that this mirrors the developer’s installation environment - individual components installed into the host filesystem.

With Tcl/Tk, getting these onto the target machine originally involved installing a Tcl/Tk distribution (or, in the case of popular versions of Linux - relying on one being installed). Then one would unload a tar or zip file into a known location - hardly a general end-user solution.

On Windows it was a little nicer - Tcl/Tk was deployed using a proprietary installer, and the same could be done with application code. But no matter how much eye-candy one adds to it, the concept of having to set up a runtime environment in addition to the application itself can be a stumbling block for many end users.

More recently there have been a number of “wrapper” tools produced for Tcl/Tk - most notably ProWrap (part of TclPro) and freeWrap. These address the problem of installing a Tcl/Tk runtime by taking a Tcl/Tk interpreter, application scripts, compiled extensions and data files then producing an executable file.

They also provide other benefits:

• since the application is self contained, it won’t be broken by the installation of newer components (e.g. a more recent version of Tcl/Tk or an extension)
• they can provide a degree of code privacy - freeWrap through (admittedly) simple encryption and ProWrap through bytecodes

Yet despite their benefits, such wrappers have their limitations:

• they don’t address multi-platform deployment scenarios
• the only update option is full replacement (of what is a rather large executable)
• wrapped applications tend to run in a different context to the development environment, and so need additional careful testing

This is not to devalue these programs - freeWrap in particular has a number of satisfied users. But in many situations it is important to go further and address the above limitations.

What is needed is a deployment model that provides:

• platform independence
• supports source and binary distributions
• supports compiled extensions
• supports single file deployment or can use an installed Tcl/Tk interpreter
• supports compression to reduce size
• supports a mechanism for code privacy
• can be launched without unpacking - i.e. an executable archive
• run in the same or similar context as the development environment
• support incremental updates as the product matures

It is this set of requirements that has driven the evolution of Starkits - whose purpose is to package Tcl/Tk applications as a single executable file for easy distribution and use.

see also

• Starkit Home Page

• Tclkit Home Page

• Metakit Home Page

• SDX Utility

• Wikit Home Page

• Tclers' Wiki

• Author's Website

Updated paper, by Steve Landers, as presented at Tcl/Tk 2002 conference - see also original PDF.