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

Login
Bounty program for improvements to Tcl and certain Tcl packages.
Tcl 2017 Conference, Houston/TX, US, Oct 16-20
Send your abstracts to tclconference@googlegroups.com
by Aug 21.
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.

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.

History