Updated 2006-06-28 22:58:58 ▲

Or STAN for short is my attempt at a package installer and auto downloader.

  • Simple: If you want install a package, a single command (GUI to come) will do it for you.
  • Simple: If you want to start your own archive, all you need is a webserver and some files.
  • Tcl: It should work with Pure-Tcl 8.3+
  • Archive: Lots of packages available (about 20, for now)
  • Network: Archives point to each other. Forming a network where each publisher can maintain their own library of binaries and pure tcl software.

Once stan is installed you can just:
 stantool install somepackage

To install somepackage.

The current library holds a few packages already, namely stan, snack (windows/linux-i386/macosx), zlib (windows/linux-i386) and dict (windows/linux-i386). Additionally, a secondary (linked!) archive lists all the cantcl packages. Not all cantcl packages will install at the moment (because pkg_mkIndex doesn't work for them!).

-- 10Sept2004 PS

Getting stan

The simplest way to get started is to fetch the stantool.kit from [1]. Alternatively, you can directly download http://pascal.scheffers.net/stan/stan/stan-0.9.tar.gz and http://pascal.scheffers.net/stan/stantool.tcl.txt. Stantool.tcl.txt requires that the package stan is already installed, whereas the kit is bundled with package stan. For the curious, take a peek at the directory listing too [2].

Listing available packages:
 $ tclkit stantool.kit list

This will show all packages (supported by your platform!)

Installing:
 # tclkit stantool.kit install -libdir /usr/lib zlib

Will install zlib in /usr/lib/zlib-1.1

Getting some help:
 $ tclkit stantool.kit

If you use stantool outside tclkit, you will not have zlib available (Trf and the others are not supported yet). On unix platforms, this is not a big deal, as stan will try to use gzip, bzip2 and unzip. On windows you should really make your first stan command:
 c:\>tclsh stantool.tcl.txt install -libdir c:\tcl\lib zlib

Otherwise most packages will fail to install.

Using auto-fetch

My original plan was to have have an overloaded package require, which turned out to be a package unknown handler. That code works rather well. What you can do with stan is build a very basic .kit file, with just stan and the other pure tcl extensions you need, and use stan to auto fetch the binary packges:

What you do is this:
 package require stan
 stan archive append http://my.server/myStan
 stan autofetch 1

 package require qPureTcl
 package require foobin

And stan will download and install foobin for the users platform (if available, obviously) on first load. The package will be installed in ~/.stan/foobin-0.0/ (or the windows documents and settings equivalent). ~/.stan is added to the ::auto_path by [package require stan], so the next run will just use the installed package. For console applications, I think it may be undesirable for stan to interact with the user by default, but for Tk apps, stan should probably pop-up some dialogs, maybe even with options to make it a system wide install.

If you do it like this, your users should not even need to choose their platform on the download page (well, unless you make a kit.exe, obviously...)

Shortly after writing the package unknown handler I realised that stantool would be an even better idea.

SEH -- Aha, you have read my mind in the matter of the overloading of package require. One of the reasons I have been working on virtual filesystem was to give a prospecitve enhanced package require utility maximal transport options; now you've gone and written it for me.

May I thus suggest that you make it possible for STAN to search for package archives in a local directory; then a virtual directory can be specified, which could have ftp, http, BitTorrent or whatever is next to come down the pike as its transport basis.

a collate/broadcast virtual filesystem could also be used to collate multiple archive locations into what appears to STAN as a single master archive, without the need for adding complexity to the STAN codebase itself.

Also, the stability and cross-platform excellence of Tcl could be leveraged to make STAN a general distribution and installation tool for any kind of file sets, not just Tcl packages. STAN combined with an array of virtual filesystems could become apt-get on steroids: cross-platform, easy to use and deploy, with multiple network transport options and version control.

LV Great step forward! Question 1: when I do a stantool.kit list on my machine, I see two copies of vfs listed; however, there is no obvious difference between the two (the versions are the same). Also, it would really be helpful if the name column was as close to the commonly used name as possible - I see something listed as "soap" and "vfs" - are these really tclsoap and tclvfs? Question 2: is work proceeding to get cantcl and stan working better together? Question 3: does stan currently support the tcl module tip?

PS these are probably slightly inaccurate names from cantcl. Only the first four packges are mine, the rest are cantcl! And only by seeing the stan output, I saw my dict an zlib is also amis. vfs is actually tclvfs and soap I don't know. I don't know why you see two copies of vfs, but the display of that package list is very rudementary and doesn't do anything fancy, like lsort... On my way home I though of another deficiency - the tclkit version doesn't know the lib-path of the ordinary tclsh installed and therefore also does not know which packages it has installed. This is just the start, I hope. A GUI is one if the other things I have on my shopping list.

I have not talked to Steve C about cantcl, but I see stan and cantcl as highly complementary - so I'd like them to work together as well as possible. Q3: You mean TIP#55? Yes. A work in progress. Try installing 'la', from cantcl.

Sarnold adds on 24 June 2006 : would Stan and Cantcl be included as plugins into Tcl-Pkg, which provides a GUI to list packages ? Right now, Tcl-Pkg offers basic downloads of tarballs and starkits, and it does nothing else when the files are on the disk. With these plugins, the user would be able to install them from Stan and Cantcl repositories...

jmn On my platform; FreeBSD, I just see:
 Available packages:
         Name Version Installed Title

with no indication that it's either found none, or still searching.. I assume that's just because there's nothing for this platform, but in the general case of searches with no results, is there a more satisfying "not found" type response?

Also - have you considered implementing some sort of license filter? For me it's an important consideration when browsing for software, and it's a pain to have to download & install/extract a package to see how it's licensed.

ps 1. Odd, it should at least list the pure tcl packages. I'll check; can you post an [array get ::tcl_platform] for me? 2. No - good point. Cantcl has license info, my packages do not - I'll add the info. STAN itself is licensed under the same license as Tcl.
 %tclkit
 %array get ::tcl_platform
 osVersion 5.2.1-RELEASE byteOrder littleEndian machine i386 platform unix os FreeBSD user julz wordSize 4
 % set tcl_patchLevel
 8.4.6

I get the same behaviour running under tclsh.

PS It is probably in the http::geturl that it goes wrong. I have limited error checking there, as yet. Are you behind a web proxy? Try doing stantool list -debug.

jmn stantool -debug hangs at "debug Getting packages list from http://pascal.scheffers.net/stan"

I suspect it may be an MTU/MSS issue. Are you behind a firewall that is blocking ICMP type3 code4 packets?

Using http::geturl I can manually retrieve the small redirection page at http://pascal.scheffers.net/stan but the larger actual page with the trailing slash hangs. If I use http::config to set a proxy, I can retrieve the list ok.

Maybe I can fix it by mucking about with MSS/MTU settings in the network here.. or if you can ensure ICMP responses are getting through, but perhaps it would also be a good idea to supply a proxyhost (etc) option for stantool that is just passed through to http::config -proxyhost (?).

PT 10-Sep-2004: I suggest having a look at how the sdx.kit uses the autoproxy code from this wiki to try and autoconfigure the http package for any local proxy setup. It currently doesnt deal with authenticating proxies, but I have a half finished version somewhere that should do that too.

PS Adding those options is trivial to do. I knew I had to add them, I just expected that the first testers would not need it. Oh well, you live and learn :) I'll take a look at how sdx.kit does it and add that. I've been swiping (BSD licensed) code left and right ;-) As for the ICMP packets - My site is home-hosted on a 8M/512K ADSL line and I know the ISP is dropping some ICMP packets - so these may be on their list too, or it is my Draytek router. Either way - this is the first time I see those problems.

Anyhow, in the long run, it will not be very important - I want to include tools for easy mirroring (of at least the packages file, which may need to be rewritten a bit for a mirror) and the stan package itself should have more than one archive url embedded by default. But best wait with that untill the major features are somewhat stable.

LV Is stan set up to perform updates on itself as needed? PS 15Sept04: I have that very high on my wishlist, but it does not do it yet. However [stantool install stan] will always install the latest version.

LV Well
 stantool install stan

might be helpful - except this is what I get when I try:
 $ stantool.kit install stan

 can't read "p(autoproxy 1.1.maintainer)": no such element in array
     while executing
 "lappend pkginfo maintainer $p($name $v.maintainer)"
     (procedure "parsePackages" line 127)
     invoked from within
 "parsePackages $packages"
     (procedure "fetch" line 24)
     invoked from within
 "fetch $package $version $exact"
     (procedure "stan::install" line 5)
     invoked from within
 "stan::install stan {} {} 0 0"
     ("eval" body line 1)
     invoked from within
 "eval [list stan::$command] $args"
     (procedure "stan" line 3)
     invoked from within
 "stan install $package $libdir $version $exact $force"
     ("install" arm line 18)
     invoked from within
 "switch [string tolower [lindex $argv 0]] {
     install {
         set force [scan_opt -force]
         set libdir [scan_opt_value -libdir]
         switc..."
     (file "/volws/lwv28/ldatae/bin/stantool.kit/lib/app-stantool/stantool.tcl" line 127)
     invoked from within
 "source /volws/lwv28/ldatae/bin/stantool.kit/lib/app-stantool/stantool.tcl"
     ("package ifneeded" script)
     invoked from within
 "package require app-stantool"
     (file "/volws/lwv28/ldatae/bin/stantool.kit/main.tcl" line 4)
     invoked from within
 "source /volws/lwv28/ldatae/bin/stantool.kit/main.tcl"
     ("uplevel" body line 1)
     invoked from within
 "uplevel [list source [file join $self main.tcl]]"

RLH How are packages verified? I think CPAN uses an MD5 checksum or some such.

Category Application | Category Deployment | Category Repository