This command is invoked to indicate that version version of package package is now present in the interpreter. It is typically invoked once as part of an ifneeded script, and again by the package itself when it is finally loaded. An error occurs if a different version of package has been provided by a previous package provide command. If the version argument is omitted, then the command returns the version number that is currently provided, or an empty string if no package provide command has been invoked for package in this interpreter.
In response to a question about finding out versions of Tcl or Expect, Donald Porter writes:
brentnye <[email protected]> wrote: > There is a tcl command to find the version of tcl, i.e. > info tclversion
Ick. Don't use that. And don't use the even worse $::tcl_version. Use [package provide Tcl]. (RS uses most often "info pa" for the added detail). Several people have asked why I recommend [package provide Tcl] rather than [package require Tcl]. In the particular example of the Tcl package, it really doesn't matter, because the Tcl package is (practically) always provided.
However, I wanted the example to generalize cleanly to other packages. [package provide foo] and [package require foo] differ in how they react when no foo package is currently in the interpreter. [package provide foo] returns an empty string, indicating no version of foo is provided. [package require foo], however, tries to go find the package foo and bring it into the interpreter. This is no longer introspection, but an action. Also, if [package require foo] fails to find foo among the installed packages, it will raise an error. The better choice for simple introspection is [package provide foo].
To add yet another wrinkle, [package present foo] occupies a middle ground. Unlike [package require foo], it will not attempt to load foo, but like [package require foo], it will raise an error if no package foo is provided in the interp. I still prefer [package provide foo] for introspection because I don't have to [catch] it. (Although I do have to be careful about passing its return value to another command expecting a version number.)
CJU - Forgive my skepticism, but I notice that you've provided an argument for [package provide] but nothing in particular against [info tclversion]. (I found the original thread mentioned above and searched the wiki to try to find an explanation but came up empty-handed.) What's so wrong with [info tclversion]? I, like so many newbies, would assume upon seeing [package provide] that the author of the code is trying to provide a package rather than just checking a version number. If I were to use [package provide] in this manner, I would always feel the need to add a comment to explain this non-intuitive use of the command. I'm sure you know what you're doing, but an explanation would greatly help before discarding the much more readable [info tclversion]. Additionally, the Tcl Usage FAQ [L1 ] (question Q.B21) suggests either one of $tcl_version or [info tclversion], with no mention of [package]. The FAQ should be changed if neither of these are the optimal solutions.
DGP 2004 Feb 16 I haven't read the Tcl Usage FAQ in more than 5 years. Has anyone? If it does not mention [package], then it probably has not been updated since Tcl 7.4. Sorry, but it just isn't part of my Tcl world.
I think of Tcl as one of possibly many packages -- that is collections of commands following a documented interface. From that perspective, [package provide Tcl] is the specific instance of the general tool [package provide pkgName] to ask which version of the interface is being provided.
See also: