$env(TCLLIBPATH) is a list of directories to add to $auto_path, which in turn is used by facilities such as package unknown to search for packages.

See Also edit

auto_path

magic names

$env(TCL_LIBRARY)

Description edit

$env(TCLLIBPATH) is a Tcl list, not some platform-specific colon-separated or semi-colon separated format, of paths to prepend to $auto_path. Regardless of platform, each item in $env(TCLLIBPATH) should use / to delimit parts of a path.

Example:

set env(TCLLIBPATH) [list /opt/tcl/site-lib /users/pat/working]

$env(TCLLIBPATH) is often not set by Tcl, and is designed to be set on a case-by-case basis depending on the needs of the site or the individual user to provide Tcl with additional site-specific locations to search for packages, or to test a package without installing it.

Example: Personal site-lib directory edit

PT 2004-07-20:

I like to keep all my local packages separate from the ActiveTcl installation that I use as a base. So I install all additional packages to a site-lib directory and then set $env(TCLLIBPATH) to this directory path. With this in place package require XYZ searches ActiveTcl and my site-lib directory for the most recent version of XYZ.

Determining which directory to add to TCLLIBPATH edit

LV 2009-06-29:

I download a package onto my machine. The package has a README, a demo directory, a lib directory, etc. Within the lib directory I see 3 sub-directories, and within the sub-directories are the pkgIndex.tcl file, etc.

So the basic layout is:

Installation directory/
 README.txt
 demos/
 lib/
  package1/
    pkgIndex.tcl 
  package2/
    pkgIndex.tcl
  package3/
    pkgIndex.tcl
 src/
 tests/

So, what path(s) go into TCLLIBPATH? the path to the lib/, or each of the individual packages?

Thanks!

PT: the lib directory.

LV PT, thank you for the answer. I tried using that, and ran into my long time nemesis - Windows folders with spaces in the names. So eventually, when I have time, I need to change to using file join to set $env(TCLLIBPATH) rather than just hard coding it, so that it has some chance of working.

Example: Windows with Git version 1.7.10-preview20120409 edit

LGT:

I ran git, then do 'cd' to be in HOME directory and then add file .bashrc with these lines:

$ cd
$ cat .bashrc
TCLLIBPATH=" . C:/Tcl/lib"
export TCLLIBPATH
$ 

Then at the next start of git, you will be able to use library packages from external (to git) Tcl installation (for instance Activestate Tcl).

Space character seems to be required at the beginning of $env(TCLLIBPATH): you can try the following lines on command line to experience it

$ unset TCLLIBPATH
$ TCLLIBPATH=". C:/Tcl/lib"
$ export TCLLIBPATH
$ tclsh
% package require Expect
can't find package Expect
% exit
$ TCLLIBPATH=" . C:/Tcl/lib "
$ export TCLLIBPATH
$ tclsh
% package require Expect
5.43.2
% exit
$

PYK 2014-05-23: This statement about the space character doesn't sound plausible. Could someone confirm or deny ? APN Works for me without the space. At least for 8.6.0.

DKF: It's a Tcl list. That should tell you exactly how to make things work, and should also indicate that leading and trailing whitespace will be ignored.

Bad interaction with Tclkit edit

AMG: I'm having serious trouble with TCLLIBPATH being ignored by Tclkit. Does anyone else have this issue?

APN I believe this is by design. Tclkits are intended to work without being affected by the host environment where the user may have other Tcl distributions installed.

AMG: An override would be most welcome. I'm trying to use my own bundled tclkit to run the tcllib and critcl build/install scripts in an automated overarching build script for my application, and I need to not rely on the system tclsh and Tcl libraries which may not exist. Yet, I'm also not bundling tcllib inside my bootstrap tclkit because that's a chicken-and-egg situation. The final tclkit does end up containing pieces of tcllib and packages built with the aid of critcl, but I obviously can't use it in the process of building itself. Right now, my solution is to patch critcl's build.tcl between unpacking and running it, adding a line to point auto_path to my libraries. Naturally, I'd prefer to avoid the maintenance burden imposed by digging into critcl internals, but I see no alternative at this time.

---