Tcl Package Developer Guide

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

Description edit

Arbitrary combinations of extensions and scripts may be combined into packages, for easy deployment and use.

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 practicies
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

Tools edit

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

Runtime Metadata edit

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.

Interdependencies edit

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.

Starkits edit

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?

Category Documentation

Category Deployment

See Also edit