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:
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. Given that the Activetcl license prevents me from making our version of the package available to non-company individuals, I get to point people to appropriate archives for older versions.
Kevin Walzer Since I develop commercially on the Mac, I tailor my deployment of applications to Mac conventions (see http://www.codebykevin.com/opensource/tutorial.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.
EKB For distribution, I've got a nice system set up using Freewrap. Since it does what I want, I haven't seen the need to switch. Also, FreeWrap comes bundled with BLT, which is a must for me. (Starkits may offer this now, too -- I haven't checked lately.) For my day to day work and my own set of tools, I like using ActiveTcl.
slebetman Same here. Freewrap does what I want in a way I'm more comfortable with and, unlike starpacks, it does source code obfuscation which makes my boss happy.
JH IIUC Freewrap's "obfuscation" is not really obfuscated at runtime (it is introspectable).
slebetman Removing instrospection is quite easy. Just rename info at the end of your code. Though I've rarely seen any need for this. As long as you Brace your expr-essions and avoid eval it's quite easy to protect your app from code injections.
CMcC I have a general reticence to rely on 3rd party binaries ... don't know why, it's a quirk of mine. So, tclkits are hard to actually make, for some reason ... perhaps it's just because a tclkit is harder than a debian package (albeit less limiting.) Secondly: I like to develop using the packages I compile myself (I'm a beta-whore, perhaps that has some bearing on why I'd like to make my own tclkits) and I always end up scratching my head when I try to move from the tclkit packaged runtime - where do the libs go again? Perhaps I just don't use 'em enough to gain familiarity. Thirdly: the directory layout of a tclkit isn't consonant with the layout I'd prefer for development *or* with the layout imposed by say cvs or svn. So there's a disjunction between the development and packaging requirements. Perhaps that's inevitable. MSH I use a small TK script to build my applications (as kits or packs), which are managed under SVN in their own sub tree and I can execute them directly using wish.exe under windows or wish under linux or wrap them up (on either platform) as an executable (on either platform). My tool (WrapExe) prewraps all my extensions (bwidget, tablelist et al) and mounts them if they are needed when generating the executable/kit. As for the libs tclkit loads automatically any binary extensions and pure TCL extensions are executed directly from the VFS.