Version 5 of package management

Updated 2003-03-16 22:26:17

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 [L1 ] 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).


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