Author:         Andreas Kupries <akupries@shaw.ca>
Author:         Joe English <jenglish@users.sourceforge.net>
Author:         Larry Virden <lvirden@yahoo.com>
State:          Draft
Type:           Informative
Vote:           Pending
Created:        24-Mar-2004
Post-History:

Abstract

This document is an informational adjunct to [189] "Tcl Modules", describing a number of choices for the management of Tcl Modules in environments with more than one version of the Tcl core installed. It lists these choices and then discusses their relative merits and problems.

Background and Motivation

A regular package can perform checks in its "pkgIndex.tcl" file regarding the environment the package would be loaded into should it be requested, and make the creation of its "provide script" dependent on the result. In other words, it is able to prevent its registration, making it invisible to the Tcl interpreter in question if the environment is not right (for example, if the interpreter is too old a version of Tcl).

A Tcl module cannot do this as its "provide script" is generated by the module system.

In a controlled environment, like wrapped applications of any form this is a complete non-issue as we can assume that only those modules are installed which are not only required, but needed.

This is no problem either for installations with only one version of the Tcl core. It is believed that this is currently the majority of cases.

The change breaks only environments with several coexisting Tcl installations which share package directories among them and rely on the index scripts to prevent the registration of packages in unsuitable interpreters.

Another situation where the change can break things is an environment with a single version of the interpreter, and the version of that interpreter is changed, upgraded, or downgraded. Packages for one version may not work anymore with the new version, or a different version of the package has to be selected from among the installed versions. This situation can be viewed as having multiple version of Tcl, however over time instead of space.

For the environments with multiple versions of Tcl in space a number of possible solutions are explained in the next section.

Choices

All solutions are done outside of the Tcl interpreter, in the filesystem.

Each interpreter has its own part of the filesystem. Modules required in several of them are copied around. Modules not required are not copied. This is easy. It requires more disk space; however that is cheap.
Same as above, but use hard- and/or soft-links instead of copying. Modules not eligible somewhere are not linked.

This schema can also be used to maintain a central repository, which is just a directory tree containing all module files in their proper locations. Then link the packages which should be visible to an interpreter into their respective directory trees.

This makes the creation of test environments with a known set of packages very easy as well.
Keep the modules in several directory trees as wanted and/or needed by sharing requirements and then set the list of search paths used by an interpreter to exactly those trees which have the modules required/usable by it.

Changes over Time

Note that the default paths set down in [189] ease the management, as each Tcl shell will not only have its own space, but also access to extensions for all minor versions which came before it. This means that placing an extension into the directory for the smallest version of Tcl supporting it will make this extension available to this minor version and all the versions which come after and share the major version. This is the right thing almost all of the time.

Only extensions using internal interfaces will have to be dealt with separately.

Questions

Comments

[ Add comments on the document here ]

According to Don Porter the given solutions will not scale.

Copyright

This document has been placed in the public domain.