Version 15 of Why do you NOT use a tclkit

Updated 2007-09-28 15:06:36 by MG

Purpose: to discuss the reasons why one would not use a tclkit/starkit based solution?

On a different wiki page, where such a discussion would have been off topic, the question "I don't understand why more people don't use tclkit" came up.

Some of the reasons include:

  • ignorance - just not aware that the technology exists
  • no need - a simple tclsh meets a simple script appliation need, and results in a smaller footprint
  • problems building tclkit - the source distribution doesn't always build on every platform without problem, and there are people who don't easily have access to build components
  • lack of familarity in process of building starkit/starpacks

LES: for my own personal use applications, I prefer to rely on ActiveTcl because it is batteries included - I don't have to worry about installing extensions (packages), they're all there already. Also, once I planned to write a commercial application and starkits offer no source protection whatsoever. I gave up on the idea - too much work and not enough time - but I'll bet many developers have a problem with that. Apart from that, yes, I have distributed a couple of applications as starpacks and it all worked just fine for that purpose since they were very simple (no packages needed) and not commercial.

LV: While starpacks have the appealing property of being a single file for distribution, it does limit one to generating versions for the tclkits available. Distributing via starkit at least allows people with locally built tclkits or variants to try to use the starkit. Alas, there's no guarantee that your application is going to work if you don't distribute either tested starpacks or versions of tclkit known to work with the application. This is due to the evolving nature of Tcl and Tk, as well as the decisions made during the building of variants as to whether all the functionality of the original tclkit will be provided.


RS prefers to do the simplest thing possible, and that usually is a single file script (deployed via CVS to colleagues). One advantage of this is for instance that one can compare versions with e.g. cvs diff, while I wouldn't know how to compare two starkits without unwrapping them..

LES Simple is good, Richard. But my friends and colleagues know nothing about Tcl. I couldn't just send them bare Tcl scripts. Most people know nothing about Tcl. Developers and end users really need the packaging solutions.

RS: Well, that's my situation: my "customers" can be expected to have CVS, Tcl/Tk, and either Linux or Cygwin, so I can just instruct them to checkout and run my/path/myscript.tcl. I like CVS mostly for its built-in versioning.

LV Likewise, most of my friends and colleagues know nothing about cvs, and probably don't have a cvs command available to them. Like LES, for me, a starkit, or perhaps a starpack, is a better solution. I have recommended installation of ActiveTcl at times. In fact, just this week, I had a query as to what activetcl a site would have to install to be compatible. I discussed the politics of why the latest ActiveTcl wasn't currently available and what was going to be required to make that so, then provided the URL to the archives of activetcl so that the site could just get the same version as was being used to develop the script. While in all likelihood they would be better off with the latest version, having buracracy prevent someone from testing against the latest and greatest means that, in this case, the simplest would have been better, if I could have convinced the developers of this.


Kevin Walzer Since I develop commercially on the Mac, I tailor my deployment of applications to Mac conventions (see http://tk-components.sourceforge.net/tk-bundle-tutorial/index.html ). This means wrapping up my scripts and the Tcl/Tk frameworks in an "application bundle." One can either do this with a starkit/starpack properly arranged in the application bundle, or use a standalone build of Wish with the Tcl/Tk frameworks modified to run inside the bundle. I prefer the latter approach, simply because it's actually easier to deploy (I don't have to run "sdx"--I can just copy my scripts and extensions to the appropriate place in the bundle), and it's been around longer on the Mac than starkits--and, from a subjective standpoint, it's more "Mac-like" to me. Also, for whatever reason, I find building Tclkit a bit cumbersome on the Mac, but the standalone build of Wish goes very smoothly--this makes it possible for me to always use the latest version of Tcl/Tk. (It's a great excuse to push out an application update even if my own scripts don't have anything new--updates help generate sales!)


MG The main reason I'd not used tclkit/starkits in the past was that it was easier to install ActiveTcl than to try and get all the extensions/packages working inside a starkit. I try and avoid using lots of different extensions now, though (particularly if they aren't pure tcl), which makes using tclkit/starkits a lot easier - I develop the app in a directory structure suitable for immediate wrapping into a starpack (combined tclkit/starkit), and when I deploy, I know everyone using the code is running it against the same version of Tcl as I am.


Category Discussion Category tclkit