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.  I would, for instance, really like see a discussion of why we would not continue to use the currently supported mechanism.


----
   * [CANTCL] is a scheme for managing installation ready files via an internet site.

   * [starkit] is a method that can be used for delivering either application packages or extension packages in a single file.

   * [TEA2] is a TCT maintained guideline for organizing extension packages.
 
   * TIP55 [http://purl.org/tcl/tip/55.html] is a proposed standard directory structure for packages 

----
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. 

----
[Category Package]