Deployment Breakthroughs

Another remarkable area of Tcl innovation has to do with "deployment" issues. Deployment has to do with everything between, "It works (on my machine)!" and "We have a consistent, reliable process for delivering applications and their updates to customers."

That might sound simple at first; one tradition under Windows, for example, is to build and exercise .EXEs, and just to pass those same executables on to customers. Do your executables depend on .DLLs, though? Can an end-user have both version 1.13 and 1.38 of your product installed simultaneously, without interfering with each other? Do .INIs need to be installed relative to the application, the user, both, neither?

Many developers leave all these matters to installers, and certainly there are quite a few fine installers that address the topic. While Tcl applications are compatible with all these installers (and a few installers happen themselves to be written in Tcl), the Tcl community has also developed a bundle of unique solutions.

A full treatment of Tcl's deployment story will take a book. This profile can only hint at the depth of "Starkits" and allied technologies. Briefly, Starkits allow distribution of applications as source, or cross-platform binaries, or native single-file executables (Starpackes), with cross-platform persistent configuration information that is specific to any combination of user, application, platform, and session. Starpacks also make automatic updates through a network connection easy.

In your own Tcl programming, you're likely to encounter these technologies first in moving between source and binary distributions. The program examples above were described in terms of their source code: feed a copy of the source to a Tcl "interpreter," and the application runs. You can also turn source into an executable, which you pass on directly to friends or customers who need never know that it's a Tcl program, let alone install their own Tcl runtime.

In some circumstances, you don't need source code or binaries to run Tcl applications successfully. Here's an example:

set script
 "http://cvs.sourceforge.net/viewcvs.py/*checkout*/tcllib/tclapps/apps/asteroids/asteroids.tcl?rev=HEAD"
package require vfs ; # Tcl's virtual filesystem component
vfs::urltype::Mount http
source $script

If you run this, you'll see a clever version of the classic "Asteroids" game.

You don't have the application itself on your own filesystem, though; instead, the five lines above retrieve the latest version of the program from a SourceForge CVS repository, and execute it in Tcl via HTTP.