This blog entry is a bit of a Lincoln/Douglas debate I'm having with a fellow Tcler
on the nature of
scripts and how pkgIndex.tcl files
come to be.
My debate assertions are as follows:
That Tcl Style Guide (Included in TIP 352) recommends
placing a package provide statement in the header of a source file.
That while a package ifneeded script can contain arbitrary code,
baking that behavior into a pkgIndex.tcl file is not a sustainable practice.
That it is proper and necessary for a package distributor to produce their own pkgIndex.tcl files.
That a proper technique is to scan source files in a vfspath
for the package provide (Recommended in the tip above)
and use a routine like the any of the following to produce a master manifest of packages:
There is no marker at all that this script file implements a package.
The only indication that the script implements a package at all is in the pkgIndex.tcl file.
And many packagers elect to build their own pkgIndex.tcl file with specialized instructions
for the local platform.
An interpreter that sources that file without the package ifneeded script
provided will run that script in an unknown namespace, most likely global. In other modules,
for instance chan,
his code defines procs named gets, puts and read which will cause no end of
confusion if they were to replace the global commands of those names.
There is no technical reason for this arrangement vs. the arrangment outlines in the
Tcl Style Guide.
This style causes problems with the Tcllib test suite as it is, because tests inside
of modules expect to be able to explicitly load other modules via source.
This style is utterly incompatible with being packaged as a tcl module file (.tm).
In particular I would like to add that none of the above reasons are:
Because it breaks my system for building self-contained executables
My kit builder breaks when it encounters this code because it is far outside the norm
of what a Tcl packager should expect to see.