Version 12 of Ultimate Package Blast-o-rama

Updated 2009-11-10 11:41:46 by CMcC


To be the best package management system ever. To change the nature of package creation/distribution. To simplify all aspects of the process of writing and disseminating a library. To speed up parts of the system that are slow.

Subgoals for package writers

It should be easy to submit a package to the repository. The repository should have both a set of trusted, always-available packages (things like Itcl, modules from tcllib, etc), and a set of untrusted/unknown user-provided packages that anyone can contribute to.

Subgoals for application writers

It should be easy to access a package listed in the repository. The repository should handle dependencies automatically. The package shouldn't need to be installed on the local computer to be considered accessible and usable. The package manager should grab a package from a remote source if necessary.

Subgoals for end-users

It should be faster than the current tcl library load times. Root access shouldn't be necessary to add packages to one's local set of packages. The act of installing packages should never be necessary.


Packages, once installed, don't change often. The computer can do tedious work. The internet is available. Package writers have limited patience for boilerplate code/configuration. Simplying the package management system to where most cases just work with minimal effort is better than complicating the system to where all cases work with a lot of effort.


First cut at code

[package require Package]

The code is here:

It completely replaces package with a version which tracks additions to (note: not subtractions from) ::auto_path. First time it ever runs it creates a database under ~/.tclpkg into which it stores all the packages it finds. Thereafter, it satisfies all [package require] calls from that database, never traversing the filesystem again, unless and until ::auto_path changes to include a new, as yet unseen, directory.

This is faster than filesystem traversal, and provides a centralised database of all known/seen packages. This speed comes at a cost, of course: changes to the underlying file system will *not* be noticed by or reflected in Package. As things stand, the database would have to be removed to reflect these changes when it is automatically rebuilt.

Package also has the ability (via [package zip $file]) to mount a .zip file as a vfs, and interpret its contents as a set of packages (the top level, and any sub-directories, which contain pkgIndex.tcl will have their contents added to the db.) Once such a zip archive has been added to the db, subsequent [package require]s on the packages it exports will automatically remount the .zip, and source/load(?) the packages therein.

Supports the following extensions:

  1. [package zip $file] ... treats a zip file (in situ) as a vfs directory containing a package.
  2. [package http $url] ... downloads and installs (in ~/.tclrepo/) the package directory found at $url
  3. [package teapot $package $version {$architecture}] ... downloads and installs (in ~/.tclrepo/) the specified package from ActiveState's teapot server. Complex offerings (those which have an architecture other than "tcl") are installed and treated as for [package zip] on a local copy of the teapot entity.
  4. TBD: [package fossil $file] ... treats a fossil db (in situ) as a vfs(?) directory containing a package. May or may not extract contents to a zip
  5. TBD: [package cvs $file] ... might use the cvs in tcl package
  6. TBD: [package svn $file]
  7. TBD: [package git $file]
  8. TBD: [package tar $file] ... treat a tar (or tar.gz) archive as for zip.

It should be clear that anything capable of exporting something resembling a tcl script file or a directory/archive can be handled by this treatment.