- process by which tcl loads one or more binary or script files designed to extend the tcl functionality - see package.
- process that the developer follows in creating binary or script distributions (sometimes known as packages or extensions) designed to extend tcl functionality - see TEA2
- formats chosen by developers in bundling up the parts of the code developed for extending tcl functionality - see freewrap, prowrap, starkit, Tcl Modules
- process by which some central repository registers and manages source and/or binary distributions of software designed to extend the tcl functionality - see CANTCL or TEAPOT
- [add additional meanings for the term here]
- TIP55  is a proposed standard directory structure for packages
DGP: It needs to be understood that the four examples listed above are not alternatives. They all tackle different aspects of creating and delivering Tcl-based functionality to users.
The keyword is simple. Basically just moving files around in a (yet to be defined) filesystem structure.-- AKBryan, I believe that this is more your area to work on.
JCW: Would it be an idea to extend the "unknown" handler so it also tries a "package require"? The scenario I'm thinking of is:
foo::bar 1 2 3When the proc "bar" does not exists *AND* the namespace "foo" does not exist, the "unknown" handler tries a "package require foo" first? With nested naming, i.e. "foo::two::bar" it might even try a "package require foo.two" and then "foo".My reason for asking is that I find the current options too overwhelming (read: too many ways to do the same, and too many ways to mix package/namespace/filename capitalization). With the above, I'd never explicitly have to use package require again (for my own stuff).
DGP: Somebody remind me to explain in detail why this is the wrong idea. Briefly, in your example, you just do a [package require foo], instead of a [package require foo $someVersion]. Seems you don't care about versions? Then don't use package at all then. Auto-loading exists, and is apparently adequate for your needs.
LV: This sure seems reasonable to me. It seems like a conceptual parallel to the interactive mode's ability to try a command as a shell command if it isn't a Tcl command.SC TIP55 suggests (and vfs now uses I believe) package names like vfs::mk so the above would become "package require foo::two". However, I can't see that package require is a bad thing to write, it does make the requirement explicit in your code which makes it easier for readers to see where things are coming from.
XOTclIDE extend Tcl packages to components that have additional functionality:
- recreation (produce package scripts from interpreter)
- introspection of package content (corresponding to info proc on procedures level)
- additional metainformation (comments to structures) based on XOTcl @ command
- initialization (controlled scripts on load), deinitialization is todo point
PYK 2014-09-28: According to CMcC, there is a sophisticated package manager in wub/utilities
See Also edit
- How to build good packages
- a simple package example
- package equivalences
- tcl2002 bof on package issues
- a package proto