Distribution mechanisms for Tcl source and binaries One of several delivery systems * [Teacup] - a tool for fetching and managing packages from a repository (one can also use ftp or http or mount and other cd-rom, etc. access tools to access source or binary code and use cp, ginstall, etc. to manage the packages. And of course some OSes (for instance, [Debian], MacOSX) etc. have package management tools as well). * [Tcl Modules] - a single file that contains a package and can be [source]d * [starkit] - a single file that contains a [VFS] with source and binary * [package require] - command for loading [package]d code that is usually installed in Tcl's lib directory * [source] - command to load a Tcl source file * [load] - load a shared library (DLL or SO file) * [auto_load] - load a command using the tclIndex files in the auto-load path [KJN] I have started this page because I am beginning to get confused by the number of possible distribution mechanisms. [Neil Madden] pointed out [http://groups.google.co.uk/group/comp.lang.tcl/browse_thread/thread/e68ee93e1fefea7f/] that [package require] delegates actual loading of packages to either [source] (for Tcl scripts) or [load] (for binary extensions). Local repository access by [package] - * When teacup installs a binary package in the (local) installation repository, that package can be loaded using [package require]: auto_path includes the repository's paths for binary packages, e.g. ~/.teapot/repository/package/linux-glibc2.2-ix86/lib, and appropriate pkgIndex.tcl files have been installed. * When teacup installs a Tcl package wrapped as a module in the (local) installation repository, it could in principle be accessed by the documented package mechanism, using auto_path and pkgIndex.tcl; however, the relevant directory in auto_path is ~/.teapot/repository/package/tcl/lib, which does not exist; the module is installed in a different directory, e.g. ~/.teapot/repository/package/tcl/teapot/tcl8/8.2, and there is no pkgIndex.tcl. Loading by [package require] still works, but it appears not to be using the documented mechanism for [package]. ---- [LV] I'm confused by what you mean by ''distribution mechanism''. Do you mean '''formats in which code can be distributed to users''' or do you mean '''mechanisms by which users can locate new extensions''' or do you mean '''means by which a program can invoke other code''' or what? The reason I ask is because Teacup seems different than the other items on the above list - and there are certainly other repositories other than teacup. Also, I don't see listed in the above list things like "zip files", "starkits", "tar files", "opening a file and reading in code", "exec", "opening a pipe", etc. Perhaps after we know better what you are after, more information can be added. ---- [KJN] Sorry for the lack of clarity - I followed [Tcl Modules] which had been placed in [Category Distribution]. I'm interested in the ways that binary or Tcl code can be organised into an extension, so that when a script running on a stock Tcl installation requires an extension's functionality, the script can access the extension either automatically or by issuing a simple command. So I suppose I'm looking for ''means by which a program can locate and invoke extensions that will run in the same interpreter in the same process''. The user who needs to locate a missing extension, and the program that invokes another process (exec) or accesses another process by IPC, are different problems. The simplest way to do this when organising one's own Tcl code is to use [source]; but when a piece of code has well-defined functionality, and is intended for re-use in different projects, it is convenient to organise it as a [package]: this is how most libraries are provided at present. [Tcl Modules] and [Teacup] are innovations, and I would be glad of any comments on how these fit in with the older commands. [Teacup] appears to differ from package require by fetching modules from a repository, rather than looking in the system's Tcl installation. ---- [LV] Actually, teacup sets up a [teapot] environment whereby one can manage a couple of variants of local repositories, or access a variety of remote repositories. '''HOWEVER''', the teapot repository framework is a delivery mechanism. The other items on your list are language file formats and processes. There is really a fundamental difference, in my mind, between the two. Teacup is a program which manages how stuff gets into a directory. Why not list cp, unzip, gtar, etc. as they are parallels to teacup? The other things on your list are the various file formats that people have used to create [package]s (a.k.a modules or extensions) that, when loaded, provide new tcl commands. ---- [auto_load] appears to be an older mechanism, but it is still used by the Tcl and Tk cores and a few libraries. Should it be deprecated? Please discuss. [LV] Good question. I would think that some of the criteria for deprecating a command would be: * Does the command provide any functionality that is unique - that cannot be replicated by the other packages? * Is the command used by any other language extending mechanisms? * Is the command used by any of the major language extensions? ---- [KJN] It would be feasible to modify ''tclPkgUnknown'' so that a running script would automatically use teacup to try to fetch missing packages from the archive repository. Clearly a network connection would be needed, and user feedback might be requested; but if the alternative is that the script fails because of a missing package, perhaps these hardships can be tolerated. [LV] For that matter, it would be possible to modify the unknown proc to go out to sf.net or some other site, ftp down code, unzip/untar it, etc. There would be a variety of social issues that one should consider before trying to extend teapot - for instance, how safe is it to download an extension for use in a running program, without any idea what license it uses, what permissions it requires, etc. Then there is the situation that, in a commercial setting, security and system admins generally don't want all users to have write permissions in these types of directories ... it makes security audit trails, etc. more difficult. [KJN] OK, I see the distinction you are making - it is generally a bad idea to autoload packages from a teapot (remote) archive repository, and therefore teapot is a distribution mechanism and not a language extending mechanism. The issue remains of how a Tcl script accesses the (local) installation repository - see question near the top of the page about [package]. It would be possible for a script to access the installation repository using the existing [package] mechanism, if [auto_path] is defined appropriately and if teacup installs or generates suitable files pkgIndex.tcl. It indeed seems to work this way for binary packages (e.g. udp) and "traditional" packages in multiple files (e.g. BWidget), but not for modules (e.g. uuencode): in that case the package is placed in a directory that is not in auto_path, and there is no file pkgIndex.tcl. ---- [KJN] Should [starkit]s be in the main list? They are not quite an extension mechanism, but a complete application that can be run by a basekit. However, [stardll]s are extensions, and seem to be similar to modules. ---- ''See also:'' * [unknown] * [auto_path] * [Secrets of the init.tcl library file] ---- [Category Distribution]