The Tcl Package Developer Guide, part of the Tcl Developer Guide, provides information on developing packages for Tcl.
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.
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?