package forget ?package package ...?
package ifneeded package version ?script?
package present ?-exact? package ?version?
package provide package ?version?
package require ?-exact? package ?version?
package unknown ?command?
package vcompare version1 version2
package versions package
package vsatisfies version1 version2
http://www.purl.org/tcl/home/man/tcl8.4/TclCmd/package.htm
See also A simple package example.
How would one find the source to the package one is using? 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) ?
[Is there no succinct reference that explains the crucial role of pkgIndex.tcl?!? CL will return to this, if no one else does.]
DGP --- The man page for pkg_mkIndex, http://www.purl.org/tcl/home/man/tcl8.4/TclCmd/pkgMkIndex.htm covers the basics in the HOW IT WORKS section.
[Good point.] It's crucial that package authors understand pkgIndex.tcl as a keyword in package preparation.
DGP --- For now, yes, but stay tuned for better ideas. We don't want to be chained to pkgIndex.tcl files forever.
See also pkg_mkIndex pitfalls.
[One summary statement: package use currently requires comprehension of pkgIndex.tcl (see Magic names).]
Don Porter advises, "Anyone writing packages should read William Duquette's tutorial on 'Namespaces and Packages' [L1 ] first."
Also, note that Don made a presentation on how package unknown works and you can find the slides at [L2 ]. A current version of the work appears at http://math.nist.gov/~DPorter/tcltk/package/ .
[Distinguish package users and authors.]
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.
Using Tk as a loadable package
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."
See also On Namespaces And Packages [L3 ] and Programmation modulaire en Tcl/Tk [L4 ].
List of currently loaded packages:
proc packages {} {
# returns the list of presently loaded packages
set res {}
foreach i [package names] {
if {[string length [package provide $i]]} {
lappend res $i
}
}
set res
} ;# RSStarted a new page on package equivalences to sort out issues regarding packages which need to co-exist, such as binaries with a fallback to a pure Tcl implementation. -jcw