Purpose: This would be a good place to point to pages for the various package management schemes available, and perhaps an objective pros and cons discussion.
package management is defined as:
I would, for instance, really like see a discussion of why we would not continue to use the currently supported mechanism.
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.
-- AK
Bryan, 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 3
When 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:
The full power of XOTclIDE componets are visible only in XOTclIDE for another tcl they are normal tcl packages.
I think this additional functions should be adopted in standard tcl package system but only on demand to avert storing unnecessary information in interpreter memory.
It is possible to store all content information of a package by using tracking procedures by sourcing scripts. With procedure info script and renaming procedure proc you can get all procedures that are loaded by package require. This information can be used to implement unload functions. XOTcl use pseudo method (object) @ to code metainformations. In normal case @ do nothing but it can be also used (be redefining @) for tracking meta information also for generating package documentation. It is more practical then # that can be no active tracked and need special reparsing.
The problem of normal tcl packages are that there is no difference about defining proc (or class methods) und running scripts that can both start program or initialize package context. Another system have explicit places for initialize and deinitialize packages.
In my opinion works on tcl package management should be toward more dynamical behaviour and more metainformations. The packages should be more that pieces of scripts.
PYK 2014-09-28: According to CMcC, there is a sophisticated package manager in wub/utilities