TIP #191: Managing Tcl Packages and Modules in a Multi-Version Environment

TIP:	191
Title:	Managing Tcl Packages and Modules in a Multi-Version Environment
Version:	$Revision: 1.3 $
Authors:	Andreas Kupries <akupries at shaw dot ca> Joe English <jenglish at users dot sourceforge dot net> Larry Virden <lvirden at yahoo dot com>
State:	Draft
Type:	Informative
Vote:	Pending
Created:	Wednesday, 24 March 2004

Please enter your e-mail address (required), your name (optional), make your edits to this TIP and its Abstract, and Submit them. See TIP 3 for a description of the TIP format.

You are advised to copy the text of the TIP into an editor, make your edits there, and then paste back.

E-mail:
Name:

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.
Body:	~ 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.
Log:	This is a supplement to the main log message to allow you to add extra notes if you wish.

Note that when you submit this form, the server will attempt to store your personal details (i.e. name and email address) as cookies in your browser so that next time you edit a TIP, you do not need to retype this info. We do not retain the information on our server (other than as logged in the TIP itself and in the CVS log) and you can delete it without ill-effect if you wish. You are invited to study the implementation code if you wish to understand exactly how the information is stored in your browser.

TIP AutoGenerator - written by Donal K. Fellows