This is not necessarily the current version of this TIP.
|Title:||Managing Tcl Packages and Modules in a Multi-Version Environment|
|Version:||$Revision: 1.1 $|
Andreas Kupries <akupries at shaw dot ca>|
Joe English <jenglish at users dot sourceforge dot net>
Larry Virden <lvirden at yahoo dot com>
|Created:||Wednesday, 24 March 2004|
This document is an informational adjunct to TIP #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.
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. Like a too old 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. Currently the majority.
The change breaks only environments with several coexisting Tcl installations which share the 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 is like 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.
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 into three. This is easy. It requires more disk space, that however is already 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.