From Newsgroup: comp.lang.tcl

I'm posting this as a servoce to the community; if it's already
well-know, I apologise for disturbing you all.

I like to develop my packages with a pgkIndex.tcl and then point
TCLLIBPATH to them for testing. Once they are working, I install them as modules into lib/tcl9/site-tcl[1].

This technique runs into trouble, however, when I'm developing a new
version of a package that has an installed, module version. The problem
is that Tcl appears to find the module first so even if I have

package prefer latest

the installed version always seems to end up being loaded.

In the past, when I got myself into this position I would need to stop
running the script by

$ TCl_PKG_PREFER_LATEST=1 tclsh myScript.tcl

and do something like

$ (echo source myPackage.tcl; echo source myScript.tcl) \
| TCL_PKG_PREFER_LATEST=1 tclsh

which is a bit of a pain, but manageable thanks to command-line recall

I am indebeted to Schelte Bron who suggested to me on the Tclers chat
last night that if I attempt to require a non-existent package, then Tcl
will check everywhere before giving up and throwing an error. When it
then comes across my [package require] it will know that v1.0 is
available (as an "installed" module) but that v1.1a1 is also available
(as a package in my source tree) so it will do what I want (use v1.1a1
in this case because I defined TCL_PKG_PREFER_LATEST).

This strikes me as both very clever (and therefore admirable) but also
as a hack (and therefore nasty). Is there a better alternative - perhaps another environment variable (say TCL_PKG_TRAVERSE_FIRST) or a specific
value (say TRAVERSE_FIRST) for TCL_PKG_PREFER_LATEST?

If there's any support, I'd be happy to try to write a TIP.


Alan

[1] I find the above workflow convenient as I can simply edit and save
the package source and (provided I don't change the version number) it's immediately available for testing using the same command as the last
time around (that I can simply up-arrow to). Further, the source file is called myPackage.tcl as (I think) it should be.

The alternative appears to be that I call the source file
myPackage-0.1a1.tm and point (is it) TCL9_0_TM_PATH at it, but then the
new version would need to be called myPackage-0.1a2.tm - which is a fine
way to preserve multiple versions of a file but hasn't been *required*
since the advent of configuration management systems way back.

Sure, you can argue that I need to change pkgIndex.tcl when I move to
the next version and that's true, but I always have a makeIndex.tcl
script (that inspects the package source to determine the version
number) which makes the rebuild trivial.

I'm sure all of you who develop your packages differently think that
your way is better, and you may well be right - if I ever make it to a conference let's sit down over a drink and argue the night away... :-)

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 8/5/2026 11:59 AM, Alan Grunwald wrote:

I'm posting this as a servoce to the community; if it's already well-know, I apologise for disturbing you all.

I like to develop my packages with a pgkIndex.tcl and then point TCLLIBPATH to them for testing. Once they are working, I install them as modules into lib/tcl9/site-tcl[1].

Since by definition, and listed as a requirement, a module, with a .tm extension has to be source-able. So, during development, where presumably you have a test file, or even if you use a console, why not simply [source mymodule-x.y.tm] and don't bother with package require at all. No pkgIndex.tcl to create or worry about. You'll always get the file you want loaded.

-e

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Alan Grunwald <nospam.nurdglaw@gmail.com> wrote:

I'm posting this as a servoce to the community; if it's already
well-know, I apologise for disturbing you all.

I like to develop my packages with a pgkIndex.tcl and then point
TCLLIBPATH to them for testing. Once they are working, I install them as modules into lib/tcl9/site-tcl[1].

This technique runs into trouble, however, when I'm developing a new
version of a package that has an installed, module version. The problem
is that Tcl appears to find the module first so even if I have

When developing said new version, do you increment the version number
so that the new alpha package is a "newer" version number?

If so, it would seem easier to just tweak your package require line to
require a version above the current system version, which means the
package loader will pass over the system version as "not new enough"
and then find your "alpha" in your local location.

From the 'package' manpage:

package require package ?requirement...?

Note ?requirement...?.

That lets you specifiy a specific version, or a version below some
value, or a version above some value.

I.e. if your installed package is 2.1.3, and your new package is 3.0.0
(both made up) then

package require 3.0.0

or

package require 2.1.4-

should net you your 3.0.0 "alpha" package being loaded.

--- Synchronet 3.22a-Linux NewsLink 1.2