Tcl Package Developer Guide

The Tcl Package Developer Guide, part of the Tcl Developer Guide, provides information on developing packages for Tcl.

See Also

Packaging Extensions
Information specific to the packaging of extensions
How to build good packages
TEA 2 documentation
"The Tcl Extension Architecture", Brent Welch, Michael Thomas, 1999

See Also

C-like include in tcl
A minimal helper for source.
Tcl Package User Guide
Tips for writing quality software


A packages combines Extensions and scripts into a single unit that can be provided to an interpreter.

JCW was once heard to conclude, Package require is a contract to make a certain API available, not a procedural-call-with-side-effects in disguise - IMNSHO.

Building reusable libraries - packages and namespaces, Official Tcl Tutorial
On Namespaces and Packages , by William Duquette
Highly recommended reading.
How to build good packages
General best practices.
A simple package example, by Richard Suchenwirth
Don Porter's Presentation at the 8th Tcl/Tk Conference
A presentation by Don Porter about how package unknown works
Programmation modulaire en Tcl/Tk
Packaging of the Tcl world
Ideas about further development of a standard package system for Tcl.
into what directory should one install the various pieces of a tcl application or extension


A drop-in replacement for the built-in package command, by Don Porter

Runtime Metadata

Don Porter offers

namespace eval ::myIcons {
    # ...
    variable home [file join [pwd] [file dirname [info script]]]
    # ...

# ...

proc ::myIcons::getPath {} {
    variable home
    return $home

DGP: Hmmmm... since someone bothered to record that advice for Wiki posterity, I should add that this is nothing more than an updated version of the advice found in library(n) and tclvars(n) that each package should define a global variable ${package}_library analogous to tcl_library and tk_library storing the directory in which that package is installed.

That original advice came before namespace, back in the bad old days when the only persistent variables that could be defined were global variables. (``Persistent'' in the sense that they live longer than the execution of one proc.) Nowadays, we clearly shouldn't be defining global variables when a namespace variable will do.

Also, I've moved away from a variable named library because I find that word is used to just mean way too many different things. It's just too confusing.

MGS 2004-02-10: In my packages I create a namespace array variable called pkginfo which contains values for package, version, script, directory, name, description, author, email, date, copyright, etc. Perhaps a package source command could be useful here (to return the directory in which the requested package's pkgIndex.tcl file is/was found) ?

LV 2007-11-16: it would seem to me that having some code (in my opinion as part of the core) to which best practices could refer would be ideal. Then it becomes a matter of going from package to package, suggesting that maintainers add a line to their package to register the appropriate information.


Don writes, "The main weakness is that the [package] system does not keep track of what the interdependencies are. We get "can't find package foo" instead of 'could not load package foo 1.3 because it depends on bar 2.1, and that is not installed'." CL agrees with this, and complains that package authorship is clumsy and error-prone. Perhaps more on this subject will appear in October 2001.


LV 2007-08-30:

Is it possible at this time to distribute a Tcl package as a single starkit, and have that single file be recognized by a developer/user's code? If so, what steps would the package developer need to follow, and what steps would the receiver of the starkit have to follow, for this to work?