finding path of currently used extensions

[welle...@googlemail.com]

Is there a way to find the path of a currently used extension? Reason: I have installed some new extensions but I want to make sure Tcl is not using the standard Tcl extensions shipped with the macOS (Tktable is shipped for example).

I am able to read the version:

package require tkdnd
package require Tktable

puts -nonewline "Tktable: "
puts [package require Tktable]
puts -nonewline "tkdnd: "
puts [package require tkdnd]

but I'd also like to get the path.
Thank you.
Welle

[heinrichmartin]

https://www.tcl.tk/man/tcl8.6/TclCmd/package.htm#M6

You can get [package versions]. (I often wished <version> was optional in [package ifneeded].)

HTH
Martin

[gregor...@googlemail.com]

https://wiki.tcl-lang.org/page/The+RC+File

the proc
lspackages

[gregor...@googlemail.com]

package ifneeded Tktable [package provide Tktable]

[heinrichmartin]

On Wednesday, March 27, 2019 at 10:03:11 PM UTC+1, gregor...@googlemail.com wrote:
> Am Dienstag, 26. März 2019 11:03:39 UTC+1 schrieb heinrichmartin:
> > You can get [package versions]. (I often wished <version> was optional in [package ifneeded].)
>

> package ifneeded Tktable [package provide Tktable]

I kept this seemingly valuable input for later. Now is later, and it does not work.

My use case is to know "which package would be loaded if I package require without exact version or other requirements"?

package provide only returns the version if a package is already loaded. Is there a way to merely poll the version number?

[gregor...@googlemail.com]

a example with Tktable


lindex [lsort [package versions Tktable ]] end

or

package ifneeded Tktable [lindex [lsort [package versions Tktable ]] end]

[gregor...@googlemail.com]

Am Mittwoch, 24. April 2019 13:21:26 UTC+2 schrieb heinrichmartin:

package ifneeded Tktable [lindex [lsort -dictionary [package versions Tktable ]] end]

[heinrichmartin]

On Wednesday, April 24, 2019 at 10:35:43 PM UTC+2, gregor...@googlemail.com wrote:
> > My use case is to know "which package would be loaded if I package require without exact version or other requirements"?
> >
> > package provide only returns the version if a package is already loaded. Is there a way to merely poll the version number?
>
>
> package ifneeded Tktable [lindex [lsort -dictionary [package versions Tktable ]] end]

This cannot be it. Why would package vcompare and package prefer exist then? I understand that this code will fit in 80% of all cases, but it's not generic if I assume correctly.

[gregor...@googlemail.com]

example with Tktable


package versions Tktable
#Returns a list of all the version numbers of package
#https://www.tcl.tk/man/tcl8.6/TclCmd/package.htm#M14

lsort -dictionary [package versions Tktable ]

# sort the versions number
#https://www.tcl.tk/man/tcl8.6/TclCmd/lsort.htm#M6

lindex [lsort -dictionary [package versions Tktable ]] end

#find out the highest number

[heinrichmartin]

Thank you for your continued effort. Still, it looks like my point did not make it through.

What I implicitly noted is that:
* version sorting is more complex - even than dictionary sorting[1]
* package require has two possible preferences, namely latest and stable

It is not feasible to re-implement this decision making algorithm ... this could better be another subcommand (like package version) or a switch (like package require -dryrun).

[1]
set versions {1.0 2.2 2.11 2.12a2 2.12b1 2.12.0 2.13a1 3.42}
lsort $versions
lsort -dictionary $versions
lsort -command {package vcompare} $versions

# other than the code above, the following lines won't actually work
package require foo ;# loads and returns 3.42
package require foo 2 ;# loads and returns 2.12.0, but if
package prefer latest
package require foo 2 ;# then loads and returns 2.13a1

[stefan]

> It is not feasible to re-implement this decision making algorithm ...

Why not use a throw-away interp to do your dry run?

set sandbox [interp create]

set what [$sandbox eval {
package prefer latest
package require critcl 3
}]

interp delete $sandbox

puts $what

# decide sth. on value of "what" ...

this way you can also introspect on changes to auto_path, sources and loads, etc. w/o affecting your main interp.

HTH, Stefan

[heinrichmartin]

On Monday, April 29, 2019 at 12:21:32 PM UTC+2, stefan wrote:
> > It is not feasible to re-implement this decision making algorithm ...
>
> Why not use a throw-away interp to do your dry run?
>
> set sandbox [interp create]
>
> set what [$sandbox eval {
> package prefer latest
> package require critcl 3
> }]
>
> interp delete $sandbox

This is it. Thank you!
Actually, I thought about spawning another process, but which is quite expensive. I am not used to working with multiple interpreters ... one never stops discovering.