[ruby-talk:6491] comp.lang.tcl -- The "Batteries Included" Distribution [LONG]

Hi,

FYI, the post that follows makes several interesting and important points 
concerning distribution/packaging issues that have been discussed here in 
the past. 

First, a little introductory background 
(http://www.cs.man.ac.uk/fellowsd-bin/TIP/):

# What is a TIP?
# 
# TIP stands for Tcl Improvement Proposal. A TIP is a design document
# providing information to the Tcl community, or describing a new
# feature for Tcl. The TIP should provide a concise technical
# specification of the feature and a rationale for the feature.
# 
# We intend TIPs to be the primary mechanisms for proposing new
# features, for collecting community input on an issue, and for
# documenting the design decisions that have gone into Tcl. The TIP
# author is responsible for building consensus within the community and
# documenting dissenting opinions.
# 
# Because the TIPs are maintained as text files under revision control,
# their history is the historical record of the feature proposal.  This
# historical record is available by the normal (CVS?) commands for
# retrieving older revisions. For those without direct access to the CVS
# tree, you can browse the current and past TIP revisions via
# http://tip.web.site/

And now on to the main post from comp.lang.tcl:

>  TIP #12: THE "BATTERIES INCLUDED" DISTRIBUTION
> ------------------------------------------------
>  Version:        $Revision$
>  Author:         George A. Howlett <[e-mail]>
>  State:          Draft
>  Type:           Informative
>  Vote:           Pending
>  Created:        Friday, 15 September 2000
>  URL:            http://www.cs.man.ac.uk/fellowsd-bin/TIP/12.html
>  Post-History:
>  Discussions-To: news:comp.lang.tcl
> 
> 
-------------------------------------------------------------------------
> 
>  ABSTRACT
> ----------
> 
>  This document describes a comprehensive Tcl/Tk distribution. Its
>  primary purpose is to create a standard source tree that includes Tcl,
>  Tk, and extensions so that they can be built and installed in an simple
>  and easy manner.
> 
>  INTRODUCTION
> --------------
> 
>  One of the most enduring complaints about Tcl/Tk is that it lacks
>  features, especially when compared to Perl, Python, or Java. We
>  patiently explain that some particular feature is available in
>  extension "XYZ" only to hear how hard it is to build and install
>  extensions.
> 
>  Frank Stajano ("The SMS server, or why I switched from Tcl to Python")
>  describes the problem succinctly.
> 
>        "But if I had to put the finger on the single most important
>        reason that has me now working in Python rather than in Tcl/[incr
>        Tcl] it would not be a language issue but a library issue. I
>        prefer Python because its standard library is a gold mine. Sure,
>        for anything I want to do there's bound to be an extension
>        available in the Tcl code repository on the FTP site. Now I just
>        have to find it, fetch it, recompile the interpreter with it (Oh
>        wait - this may mean getting and installing a C compiler for this
>        system. Will the GNU one compile the windowing stuff properly or
>        do I need to get VC++, or Borland? Who wants to have some fun
>        discovering where another IDE has hidden the useful compiler
>        flags this week?), hope that it won't clash with other extensions
>        I've had to install, hope that it will not require a different
>        version of the interpreter from the one I am running, and so on.
>        Python supports the same C extension mechanism as Tcl - but the
>        practical difference is that the stuff I want is, most of the
>        time, already included and shipped in the standard distribution
>        of the language!
> 
>        "But, as a general-purpose tool, Python's single most important
>        selling point is the richness of its standard library - an idea
>        that Tcl is only now starting to internalise. It's all in the
>        distribution. You can attack your practical problem using the
>        stuff that's already installed on your system, and documented in
>        the library manual you already printed. Python is great because
>        it comes with batteries included."
> 
>  It's true. There are too many things to know to maintain even a
>  moderate set of extensions. There are too many different places to
>  download extensions, too many extension-specific configuration options,
>  etc.
> 
>  My hope is that this proposal will mark the beginning of the end of the
>  "Batteries Included" problem. One evidence of success will be that
>  words "core" and "extension" disappear from our Tcl vocabularies. We've
>  lived their artifical distinctions that are useful only to core
>  developers and extension writers. It's skewed our thinking about
>  relationship between Tcl and its parts. After all, application writers
>  first care about whether a feature or capability is available, not how
>  it's structured under the hood.
> 
>  THE "BATTERIES INCLUDED" DISTRIBUTION.
> ----------------------------------------
> 
>  Let's start with a very modest example. Let's imagine that the
>  "Batteries Included" distribution is nothing more than a tar file of
>  Tcl/Tk and several extensions.
> 
>                Unix    Windows  Mac
>                 ----    -------  ---
>      Tcl 8.3       x       x      x
>      Tk 8.3        x       x      x
>      [incr Tcl]    x       x      x
>      expect        x       ?
>      TclX          x
>      BLT           x       x
>      Trf
>      Html widget
>      XML
>      ...lots more...
> 
>  Tcl, Tk, and the packages are configured such that they can be built
>  and installed just from a top level directory (not individually).
>  Someone can download and try out all sorts of new features without
>  repeating the same "configure", "make", "make install" sequences.
> 
>  With this simple tar file, the following benefits are automatically
>  generated:
> 
>      * It provides a simple way for users to try out extensions. Users
>        only have to run download, configure, compile and install, at
>        most, once.
> 
>      * It describes a clear framework for extensions. We will have
>        established a directory structure for both source code and
>        installed binaries. It will be much more clear how to
>        inter-operate. This is TEA in action.
> 
>      * It's better for Tcl/Tk application writers. You can count on
>        features being universally available. Your program can again be
>        just a Tcl script, not an array of packages that everyone needs
>        to download and install.
> 
>      * It's better for extension writers. Configuration is simpler,
>        since you know where all the sources and the compiler-specific
>        information will reside. You don't need to search for
>        _tclConfig.sh_ or _tkConfig.sh_ files.
> 
>      * It's better for Tcl/Tk distribution builders. This includes both
>        the Linux distributors and company sysadmins that build Tcl/Tk.
>        They don't have to fear installing extensions because of version
>        dependencies.
> 
>        Let's give Redhat and SuSE a good reason to move off of version
>        8.0. One the big advantages of Linux over (let's say) Solaris is
>        that each new Redhat or SuSE distribution comes with updated
>        versions of utilities already built.
> 
>      * It's better for the core developers. Extension writers will
>        willing the adopt changes in exchange for the wider distribution.
>        The core team will in turn gain better understanding of the
>        burdens of extension writers.
> 
>      * It's better for Tcl library writers. With [incr Tcl], we now have
>        a basis for a real, extensible Tcl-code library. Library code
>        rely on a full set of extensions being available.
> 
>  RATIONALE
> -----------
> 
>  We want to create an open door procedure that makes it easy for
>  contributors to add new features and commands to Tcl and Tk. By
>  creating a framework for extensions to be built and distributed, the
>  "Batteries Included" distribution will provide a path for great new
>  features to quickly become available to the Tcl community.
> 
>  The "Batteries Included" distributed is not designed to be one size
>  that fits all. I assume there will be many distributions to suit many
>  needs. There may be one for Tcl web servers and another for embedded
>  systems. The goal is that the "Batteries Included" distribution will
>  become a prototype for other distributions. Distribution creators will
>  be able to pull code from the same CVS source tree.
> 
>  What will distinguish the "Batteries Included" distribution is that it
>  will be the most comprehensive and most up-to-date distribution. We
>  will explicitly not choose one package or extension over another. That
>  decision should remain with the Tcl user community. The only
>  requirement is that the extensions are robust and/or actively
>  maintained.
> 
>  If the "Batteries Included" distribution is to become successful, it
>  must be a cooperative effort between Tcl core developers, extension
>  writers, and the Tcl user community. For example, we need the help of
>  extension writers to adopt the new configuration scheme and directory
>  structure.
> 
>  PARTICULARS
> -------------
> 
>  We can stage the project with small milestones while still focusing on
>  longer range goals. For example, the first phase can be as simple as
>  creating a tar file. It will start to address questions that were
>  raised by TEA. For example, how do we manage documentation?
> 
>  The biggest reason why this proposal will succeed is the incredible
>  talent in the Tcl community. We can leverage the skills and experiences
>  of the foremost experts on the core, extensions, and applications.
> 
>  TCL/TK VERSION.
> -----------------
> 
>  The distribution will be based on 8.3.2 (or 8.3.3 when it is released).
>  While there's no assurance when 8.4 will be released and in what state,
>  we also want to place a premium on stable, robust extensions, that have
>  been thoroughly tested. Most extensions will be unlikely to have been
>  tested against the 8.4 alphas.
> 
>  PHASE 1.
> ----------
> 
>      * Identify extensions.
> 
>        What extensions should be included in the near term? We need
>        extension authors that are willing to work with us to build a
>        directory framework, change configuration files, etc. Extensions
>        do not need to work on all platforms. For example, there is a
>        wealth of Windows-based extensions that should be included.
> 
>        What are the minimum requirements for extensions in the short
>        term? Manual pages, html, tests, demos all would be nice. We need
>        to temper this with what's practical. This is a learning process.
>        We can adjust requirements in future phases.
> 
>      * Determine build and install directory structures.
> 
>        We need to make this work with more that one release installed.
>        Don't suppose that there only one version will ever be used.
> 
>      * Setup CVS archives.
> 
>      * Create configuration files.
> 
>        This will require negotiation with extension writers. We want
>        their buy-in so they will maintain the changes.
> 
>        There may be more than one form of configuration required. One
>        subtle but important issue is that extensions must be able to be
>        configured without Tcl or Tk libraries already existing. This is
>        a "trusted" configure. The extension must trust that the library
>        will exist. Right now, most extensions work from "untrusted"
>        configurations.
> 
>      * Test builds on multiple platforms.
> 
>        For now, the Windows and Mac build files can be hand-generated.
>        It may be too hard to create a seamless build environment. We're
>        not trying to satisfy every Windows/Mac developer here. We can
>        focus on creating pre-built binary distributions for these
>        platforms.
> 
>      * Create self-installing executables for Windows and the Mac.
> 
>        If we want, we can provide Linux, Solaris, etc. binaries by
>        reviving Michael McLennan's Tclish installer.
> 
>  PHASE 2.
> ----------
> 
>      * Handle documentation issues.
> 
>        Generate platform specific doc with Richard Hipp's XML code.
> 
>      * Establish Tcl code library.
> 
>      * Identify more extensions.
> 
>      * Determine the release schedule for "batteries included"
>        distribution.
> 
>        How often do you release a new version? It must be more frequent
>        than Tcl/Tk. We can start by planning for quarterly releases and
>        then adding more frequent releases if necessary.
> 
>      * Determine what core changes (if any) are needed for the
>        distribution.
> 
>      * Start looking at network-based updates.
> 
>      * Start looking at selective builds. Allow builders to
>        compile/install subsets of the distribution.
> 
>      * Push on Redhat, SuSE, etc. to pick up distribution.
> 
>  PHASE 3.
> ----------
> 
>      * Network-based installs.
> 
>      * Selective installations/builds.
> 
>      * Include applications tree.
> 
>      * Identify more extensions.
> 
>  The last phases are sketchy. Feel free to add to this list, further
>  breaking down goals into subtasks.
> 
>  OPEN ISSUES
> -------------
> 
>      * Windows and MacIntosh sources.
> 
>        Given the dearth of configuration tools for these platforms, it's
>        likely that only binary installations will be available for the
>        near term.
> 
>      * Documentation
> 
>        Overlap in command and widget names can be neatly handled by
>        namespaces. Need to consider how to handle manual pages.
> 
>  MORE INFORMATION
> ------------------
> 
>  If anyone has interest to participate or would like to add comments to
>  the "Batteries Included" proposal, please send mail to George Howlett
>  <[e-mail]>.
> 
>  COPYRIGHT
> -----------
> 
>  This document has been placed in the public domain.

<Remainder of document snipped.>

Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)