[JMN] 2005-08-22
----
tarpack is an experimental Tcl-only package for loading & creating [Tcl Modules] that are also valid [tar] archives.

This is done by adding the 1st file in the archive with a special name.. such as the Tcl comment character #  or a short piece of Tcl script. I chose "#tarpack-loadscript" as the 1st file's name and this also acts as a sort of file-type 'signature'.

This first file also contains the ctrl-z  (\u001A) character as a terminator at the end so that Tcl can source the tar archive.

You can examine the .tm files with a text editor and any standard tar archiving programs to get a feel for what's going on.

It is available here: http://vectorstream.com/tcl/packages/ along with some other packages such as Thread, trofs & tdom wrapped using tarpack.. I refer to them as 'tarpacks'.

I've been playing around with Tcl Modules in an attempt to reduce interp startup time. For installations with a large number of packages on auto_path and/or with network connections on the auto_path, load time for packages can be significant.

I don't know how useful tarpack will end up being - It was intended to be tcl-only so that an installation including binary packages can be created such that all packages are Tcl Modules rather than the usual packages on auto_path.

I was initially playing around with [trofs] as an archiver - and presumably trofs as a binary package will be much more efficient, but by wrapping trofs with tarpack, I can at least bootstrap trofs into the system without relying on auto_path. 

Like trofs tarpack doesn't depend on vfs, but unlike trofs, tarpack doesn't actually 'mount' the module as part of the filesystem.


----

Here's a rough example of how the Thread package was wrapped as a tarpack:

 %package require tarpack
 1.0
 %tarpack::create Thread-2.6.1.tm [list ttrace.tcl Windows-x86 FreeBSD-x86]
 Thread-2.6.1.tm
 
At this point the tar archive (and Tcl Module!) Thread-2.6.1.tm has been created with a default basic load-script. 
This default load-script will simply source any .tcl files we gave in the list to tarpack::create above.
If there were .so or .dll files directly listed there it would have called 'load' on them. (after copying out to file system)

The load-script is also left as a separate file in the working directory. It's named #tarpack-loadscript

This separate load-script can now be edited to make  'tarpack::source' & 'tarpack::load' calls to any of the wrapped files.

A subsequent tarpack::create call with the same arguments above will now use the modified load-script instead of the default. Alternatively 
 
 tarpack::update Thread-2.6.1.tm "" 

will read the tar contents list of Thread-2.6.1.tm and re-archive them along with the modified load-script. 
(final arg is an empty list to indicate we are not adding any extra files)

----

Sorry there's no separate documentation  - just some comments in the source.

----
[Category Deployment]