Purpose: Discuss the purpose, and implementation, of [TIP]#189
[http://tip.tcl.tk/189], TIP#190 [http://tip.tcl.tk/190], and 
TIP#191 [http://tip.tcl.tk/191] .
Note this is something totally different from the Tcl [Modules] package.
----
See also [Tcl Module creation script]
----
See [tarpack] for an experiment in tar archives that are also sourceable Tcl Modules.
----
Could [Tcl Software Libraries] be relevant in discussing this topic?

----
[LV] I've seen people ask whether [zip] files will be supported as tcl modules; I myself am hoping to see [starkit]s as tcl modules.
----
[jmn] 2005-09-13 
::tcl::tm::add can have unintuitive (IMO) results. 
tip189 clearly states that paths added last are 'looked at' first - but it doesn't make it clear that a package of the same version in a later path will 'override' the earlier entry in the 'package ifneeded' database.

This may be of concern if you are trying to create a local cache of packages with a fallback to your main repository on a (slower) network share - or if you are trying to force use of a particular module file during testing (without hacking at versions).

'package forget' won't help here - in contrast to the standard auto_path system where a path inserted into the head of $auto_path WILL allow loading of this package in preference to the one found later in the list (assuming either auto_path wasn't scanned prior to the addition, or you've called 'package forget' after the addition) .

Is this behaviour intended?

I think it'd be really nice to have some way (that works consistently for both module & auto_path systems) to override existing entries in the 'package ifneeded' database - for just those packages in a particular folder.

e.g a 'package scan <dir>' command might add just the packages found in <dir> - replacing any previous entries in the database.

Otherwise - some better introspection of the 'package ifneeded' database would be nice.. It's currently quite confusing to debug package loading issues so if you could do something like a 'package ifneeded *' and see what it holds - that might help.

[Lars H]: Do you mean something like this?
 proc package_ifneeded_* {} {
    set res {}
    foreach pkg [package names] {
       set L {}
       foreach ver [package versions $pkg] {
          lappend L $ver [package ifneeded $pkg $ver]
       }
       lappend res $pkg $L
    }
    set res
 }
Example:
 % join [lrange [package_ifneeded_*] 0 5] \n
 rcs
 0.1 {source /Library/Tcl/tcllib1.8/rcs/rcs.tcl}
 logger
 0.6.1 {source /Library/Tcl/tcllib1.8/log/logger.tcl}
 SOAP::Utils
 1.0 {source /Library/Tcl/tclsoap1.6.7/utils.tcl}

[jmn] Thanks yes - of course you're right.. the package command does provide enough basics to build your own view of the database as you require - I just think something similar to your snippet would be a nice inclusion to the standard distribution. While I should have known better and just built such a thing - I think for new users (or even just anyone a little unsure of how it all works) the package mechanisms have enough tricky subtleties that any extra introspection help that can be provided would be good.

Anyway.. this is an aside to the main issue I'm having: that I can't get the 'package require' system to use a package earlier in the module path if the package versions are the same. The theory may go that if the package versions are the same it shouldn't matter - but there may be administrative reasons to need this to behave properly - such as repository access speed.. or maybe a c-coded version to take higher precedence than a tcl-only version.

[MG] Perhaps an addition to the way [[package require]] works would help. For instance, if you could do

  package require -path [list "/path/to/thisfile" "/path/to/thatfile"] myPackage 2.0

to either have only those paths checked, or to have those checked first, followed by all the usual places, it might solve your problem. That would also allow you to [[package require]] a package which you know resides in a certain place, on it's own, without having to add that path into your $auto_path (which is checked for ''all'' packages, slowing things down a little, as I understand it).

Another simpler solution to the C vs. Tcl versions is to just add another level to the version number. For instance, call a C version of a package version 2.0.2 and the pure-Tcl (slower) version 2.0.1, so that a [[package require myPackage 2.0]] would give priority to the C one.

----
[Category Deployment]