TIP #191: Managing Tcl Packages and Modules in a Multi-Version Environment
From: Andreas Kupries (akupries_at_shaw.ca)
Date: 04/27/04
- Next message: Donald Arseneau: "Re: TIP #188: Add 'string is wide' to the 'string is' Subcommand"
- Previous message: Andreas Kupries: "TIP #190: Implementation Choices for Tcl Modules"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 27 Apr 2004 21:20:23 +0000 (UTC)
TIP #191: MANAGING TCL PACKAGES AND MODULES IN A MULTI-VERSION ENVIRONMENT
============================================================================
Version: $Revision: 1.2 $
Author: Andreas Kupries <akupries_at_shaw.ca>
Joe English <jenglish_at_users.sourceforge.net>
Larry Virden <lvirden_at_yahoo.com>
State: Draft
Type: Informative
Vote: Pending
Created: Wednesday, 24 March 2004
URL: http://purl.org/tcl/tip/191.html
WebEdit: http://purl.org/tcl/tip/edit/191
Post-History:
-------------------------------------------------------------------------
ABSTRACT
==========
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.
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. 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.
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 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.
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 [TIP #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.
-------------------------------------------------------------------------
TIP AutoGenerator - written by Donal K. Fellows
[[Send Tcl/Tk announcements to tcl-announce@mitchell.org
Announcements archived at http://groups.yahoo.com/group/tcl_announce/
Send administrivia to tcl-announce-request@mitchell.org
Tcl/Tk at http://tcl.tk/ ]]
- Next message: Donald Arseneau: "Re: TIP #188: Add 'string is wide' to the 'string is' Subcommand"
- Previous message: Andreas Kupries: "TIP #190: Implementation Choices for Tcl Modules"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
