tcl-core

[TCLCORE] New tip #722

[Christian W. <Chr...@t-...>]

Hello all,

(posted again in case I've sent it with the wrong account)

please could some tip fossil maintainer add the following tip.

---8><---8><---

# TIP 722 Improve **package present** subcommand
         Author:         Christian Werner <und...@gm...>
         State:          Draft
         Type:           Project
         Created:        19-May-2025
         Keywords:       Tcl,package
-----

# Abstract

This TIP proposes to improve the **package present** subcommand such
that it can be used to return a list of all currently loaded packages.

# Rationale

Although there is a **package names** subcommand which returns a list of
all currently available packages there's no equivalent to retrieve the
list of currently loaded packages. However, the latter can be of use
e.g. to build a software bill of materials of an application or to help
in generating a package dependency graph.

# Specification

For **package present** without any further arguments (which currently
generates an error message) the implementation of **package names** is
borrowed but its selection clause while iterating over the package hash
table is changed to add package names to the result list for which a
version is known (which means that the package has been loaded).

** Implementation

The code block to add to the current **package present** implementation is:

'''
if (objc < 3) {
     Tcl_Obj *resultObj;

     TclNewObj(resultObj);
     tablePtr = &iPtr->packageTable;
     for (hPtr = Tcl_FirstHashEntry(tablePtr, &search); hPtr != NULL;
              hPtr = Tcl_NextHashEntry(&search)) {
         pkgPtr = Tcl_GetHashValue(hPtr);
         if (pkgPtr->version != NULL) {
             Tcl_ListObjAppendElement(NULL, resultObj, Tcl_NewStringObj(
                     Tcl_GetHashKey(tablePtr, hPtr), -1));
         }
     }
     Tcl_SetObjResult(interp, resultObj);
     break;
}
'''

The test code in ```package.test``` must be changed for test case 8.11 to:

```
test package-8.11 {Tcl_PackageCmd procedure, "present" option} -body {
     package present
} -match glob -result *
```

# Copyright

This document has been placed in the public domain.

---8><---8><---

Thank you,
Christian

[TCLCORE] New tip #722

[Christian W. <und...@gm...>]

Hello all,

please could some tip fossil maintainer add the following tip.

---8><---8><---

# TIP 722 Improve **package present** subcommand
         Author:         Christian Werner <und...@gm...>
         State:          Draft
         Type:           Project
         Created:        19-May-2025
         Keywords:       Tcl,package
-----

# Abstract

This TIP proposes to improve the **package present** subcommand such 
that it can be used to return a list of all currently loaded packages.

# Rationale

Although there is a **package names** subcommand which returns a list of 
all currently available packages there's no equivalent to retrieve the 
list of currently loaded packages. However, the latter can be of use 
e.g. to build a software bill of materials of an application or to help 
in generating a package dependency graph.

# Specification

For **package present** without any further arguments (which currently 
generates an error message) the implementation of **package names** is 
borrowed but its selection clause while iterating over the package hash 
table is changed to add package names to the result list for which a 
version is known (which means that the package has been loaded).

** Implementation

The code block to add to the current **package present** implementation is:

'''
if (objc < 3) {
     Tcl_Obj *resultObj;

     TclNewObj(resultObj);
     tablePtr = &iPtr->packageTable;
     for (hPtr = Tcl_FirstHashEntry(tablePtr, &search); hPtr != NULL;
              hPtr = Tcl_NextHashEntry(&search)) {
         pkgPtr = Tcl_GetHashValue(hPtr);
         if (pkgPtr->version != NULL) {
             Tcl_ListObjAppendElement(NULL, resultObj, Tcl_NewStringObj(
                     Tcl_GetHashKey(tablePtr, hPtr), -1));
         }
     }
     Tcl_SetObjResult(interp, resultObj);
     break;
}
'''

The test code in ```package.test``` must be changed for test case 8.11 to:

```
test package-8.11 {Tcl_PackageCmd procedure, "present" option} -body {
     package present
} -match glob -result *
```

# Copyright

This document has been placed in the public domain.

---8><---8><---

Thank you,

Christian

[TCLCORE] TIP 722: return loaded packages by ”package present”

[Harald O. <har...@el...>]

Dear TCL team,

Christian is currently highly active, thanks for all!

TIP 722 proposes to return the list of currently loaded packages.

Here is a usage example of a freshly installed tclsh:

% package present
tcl::zlib tcl::oo TclOO tcl::tommath tcl Tcl

This looks usable and neat.

Only the documentation is missing. There is currently one test.

I saw a code path "NREPackageObj". Must this also be changed?

Any comments on this one?

---
This Tk tickets looks good to me:
https://core.tcl-lang.org/tk/info/c81e0ccee2b971b0

---
Monotonic clock:
IMHO, the only clean solution is:
timer on <TimeDelta>
timer at <TimePoint>
as the current "after" has two use-cases.
This is the long way solution.
I will at least update the TIP...
No time at the moment, sorry...

Thanks for all,
Harald

Re: [TCLCORE] TIP 722: return loaded packages by ”package present”

[Christian W. <Chr...@t-...>]

On 06/06/2025 02:03 PM, Harald Oehlmann wrote:

Harald, all,

> …
> TIP 722 proposes to return the list of currently loaded packages.
>
> Here is a usage example of a freshly installed tclsh:
>
> % package present
> tcl::zlib tcl::oo TclOO tcl::tommath tcl Tcl
>
> This looks usable and neat.
> …

while at this "package" point I'm asking myself if it wouldn't as
well interesting to borrow and augment another already present idea:
There's a "package files …" which collects all the sourced files
during "package require …". A very similar mechanism could be
established which gathers the first level "package require …"
invocations in order to get an idea of the first level dependencies
of the newly required package. So storage would be similar to
"package files …" i.e. per package. By combining the overall
information of all packages a dependency tree emerges which again
could be quite useful to make a software bill of materials or to
help in building single file applications using e.g. the zipfs.

What are your thoughts? Is this a useful addition?

BR,
Christian

[TCLCORE] Follow-up: TIP 722: return loaded packages by ”package present”

[Christian W. <Chr...@t-...>]

On 06/06/2025 06:53 PM, Christian Werner wrote:

> …  while at this "package" point I'm asking myself if it wouldn't as
> well interesting to borrow and augment another already present idea:
> There's a "package files …" which collects all the sourced files
> during "package require …". A very similar mechanism could be
> established which gathers the first level "package require …"
> invocations in order to get an idea of the first level dependencies
> of the newly required package. So storage would be similar to
> "package files …" i.e. per package. By combining the overall
> information of all packages a dependency tree emerges which again
> could be quite useful to make a software bill of materials or to
> help in building single file applications using e.g. the zipfs.

A POC implementation based on the 8.6 derivative used in AndroWish
and friends can be found in

   https://androwish.org/home/info/15dbeb55bc676755

It adds (pasted from the manpage)

.TP
\fBpackage depends \fIpackage\fR ?\fIpackage\fR?
.
With a single \fIpackage\fR argument a list of all direct dependent package names
is returned. This list is automatically obtained when loading \fIpackage\fR.
The list can be manually extended with the second and following \fIpackage\fR
arguments to this command. The order of the returned list is arbitrary.
.TP
\fBpackage files \fIpackage\fR
.
Lists all files forming part of \fIpackage\fR. Auto-loaded files are not
included in this list, only files which were directly sourced during package
initialization. The list order corresponds with the order in which the
files were sourced.

Together with the flesh of TIP#422 it is possible to construct a full package
dependency tree at arbitraty points of runtime by by applying "package depends"
on all provided packages.

Once again, what are your thoughts? Is this a useful addition?

BR,
Christian

Re: [TCLCORE] Follow-up: TIP 722: return loaded packages by ”package present”

[Christian W. <Chr...@t-...>]

On 06/24/2025 09:36 PM, Christian Werner wrote:

> blablabla
> Together with the flesh of TIP#422 …
> blablabla

Correction: TIP#722

Sorry,
C.

Re: [TCLCORE] [EXTERNAL] Follow-up: TIP 722: return loaded packages by ”package present”

[Donald G P. <don...@ni...>]

On 6/24/25 15:36, Christian Werner wrote:
> Once again, what are your thoughts? Is this a useful addition?

Some thoughts...

 From the description in the message, it looks like the dependency information that
is reported by the proposed mechanism is...

... empirical; and

... consists of package names alone.

So we learn that in the current program run requiring package foo caused the requiring
of package bar which in turn caused the requiring of packages baz and grok.

Contrast this with the conception of the [package require] command itself.

   package require $pkgName ?$requirement ... $requirement?

which can take the form of

   package require foo 3.1-3.7 4.3

The important point is that a program does not depend on just a package name, but
on a collection of releases of a package that truly meet the needs of the program.
If you do not capture the version information as well, you aren't capturing all the
dependency information on which [package] operates.

This also illustrates that the conceptual dependency understood by the programmer
writing the [package require] commands cannot be captured empirically.  The
program knows that "foo 3.1" or "foo 3.2" or "foo 3.2.4.6" or "foo 3.6.1" or "foo 4.3"
are all acceptable, but each run of the program can only empirically capture that
this time "foo 3.4.7" and "foo 3.5.0" were available, and "foo 3.5.0" was provided.

Depending on which version of foo was actually provided, the dependencies that
get dragged in could well be different.  foo 3.4.7 had a dependency on bar 2. but
foo 3.5.0 decided to make use of bingo 7 to solve the same problem.

I can see some value in recording a history of how packages came into the interp, but
the empircal approach does not capture the full dependency tree, realized and
unrealized, and doesn't result in the sort of data on which you could do a toplogical sort.
Good for some purposes, but not for the full functionality I would expect to find in
a [package depends] command.

Here is some old work I once did on the topic.  It includes construction of dependency
tree data structures that programs can operate on to discover and activate mutually
consistent package releases to achieve a working program, even when the greedy
default algorithm built in to [package require] would fail to find the available working
combination.

https://math.nist.gov/~DPorter/tcltk/package/

Note that this work was done for pre-8.5 releases of Tcl.  Tcl 8.5 added some of its
functions to [package] (TIP 268), but not all.  The code is also awkward in all the
ways code had to be before the arrival of {*} syntax.

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] [EXTERNAL] Re: [EXTERNAL] Follow-up: TIP 722: return loaded packages by ”package present”

[Donald G P. <don...@ni...>]

On 6/24/25 16:57, Donald G Porter via Tcl-Core wrote:
> I can see some value in recording a history of how packages came into the interp, but
> the empircal approach does not capture the full dependency tree, realized and
> unrealized, and doesn't result in the sort of data on which you could do a toplogical sort.

Another illustration of this idea.  A program makes use of packages foo and bar,
and both of them are nicely internationalized, so each one makes use of package msgcat.

An empirical [package depends] will record that msgcat is present because foo
dragged it in, or because bar dragged it in, depending on the empircial sequence
that happened to occur, but it won't capture that both foo and bar are equally dependent
on it.

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] [EXTERNAL] Follow-up: TIP 722: return loaded packages by ”package present”

[Christian W. <Chr...@t-...>]

On 06/24/2025 10:57 PM, Donald G Porter via Tcl-Core wrote:

Thanks for your comments, Don,

> …
> From the description in the message, it looks like the dependency information that
> is reported by the proposed mechanism is...
>
> ... empirical; and
>
> ... consists of package names alone.
>
> So we learn that in the current program run requiring package foo caused the requiring
> of package bar which in turn caused the requiring of packages baz and grok.
>
> Contrast this with the conception of the [package require] command itself.
>
>   package require $pkgName ?$requirement ... $requirement?
>
> which can take the form of
>
>   package require foo 3.1-3.7 4.3
>
> The important point is that a program does not depend on just a package name, but
> on a collection of releases of a package that truly meet the needs of the program.
> If you do not capture the version information as well, you aren't capturing all the
> dependency information on which [package] operates.

Now already here I am at the point where I have to politely doubt the sense of
"package files …". Why did it then make into the "package" command at all, since the
version/minor/micro could be indeed decide on the set of files which make up the
package. And what deeper value is then in this information when the next version's
set is slightly different?
  
> This also illustrates that the conceptual dependency understood by the programmer
> writing the [package require] commands cannot be captured empirically.  The
> program knows that "foo 3.1" or "foo 3.2" or "foo 3.2.4.6" or "foo 3.6.1" or "foo 4.3"
> are all acceptable, but each run of the program can only empirically capture that
> this time "foo 3.4.7" and "foo 3.5.0" were available, and "foo 3.5.0" was provided.

The idea was mainly driven to get a snapshot for the dependencies to make that
snapshot somehow permanent given the means we got by e.g. "zipfs mkimage". Therefore
the tracking of version information of a package is deliberately left out (similar
to "package files …" is version unaware.

> Depending on which version of foo was actually provided, the dependencies that
> get dragged in could well be different.  foo 3.4.7 had a dependency on bar 2. but
> foo 3.5.0 decided to make use of bingo 7 to solve the same problem.
>
> I can see some value in recording a history of how packages came into the interp, but
> the empircal approach does not capture the full dependency tree, realized and
> unrealized, and doesn't result in the sort of data on which you could do a toplogical sort.
> Good for some purposes, but not for the full functionality I would expect to find in
> a [package depends] command.
> …

I see your points and will step back to further bring this idea forward.

All the best,
Christian

Re: [TCLCORE] New tip #722

[<apn...@ya...>]

Done. Note tip does not mention target version. 

Yahoo Mail: Search, organise, conquer 
 
  On Mon, 19 May 2025 at 11:11 am, Christian Werner<Chr...@t-...> wrote:   Hello all,

(posted again in case I've sent it with the wrong account)

please could some tip fossil maintainer add the following tip.

---8><---8><---

# TIP 722 Improve **package present** subcommand
        Author:        Christian Werner <und...@gm...>
        State:          Draft
        Type:          Project
        Created:        19-May-2025
        Keywords:      Tcl,package
-----

# Abstract

This TIP proposes to improve the **package present** subcommand such
that it can be used to return a list of all currently loaded packages.

# Rationale

Although there is a **package names** subcommand which returns a list of
all currently available packages there's no equivalent to retrieve the
list of currently loaded packages. However, the latter can be of use
e.g. to build a software bill of materials of an application or to help
in generating a package dependency graph.

# Specification

For **package present** without any further arguments (which currently
generates an error message) the implementation of **package names** is
borrowed but its selection clause while iterating over the package hash
table is changed to add package names to the result list for which a
version is known (which means that the package has been loaded).

** Implementation

The code block to add to the current **package present** implementation is:

'''
if (objc < 3) {
    Tcl_Obj *resultObj;

    TclNewObj(resultObj);
    tablePtr = &iPtr->packageTable;
    for (hPtr = Tcl_FirstHashEntry(tablePtr, &search); hPtr != NULL;
              hPtr = Tcl_NextHashEntry(&search)) {
        pkgPtr = Tcl_GetHashValue(hPtr);
        if (pkgPtr->version != NULL) {
            Tcl_ListObjAppendElement(NULL, resultObj, Tcl_NewStringObj(
                    Tcl_GetHashKey(tablePtr, hPtr), -1));
        }
    }
    Tcl_SetObjResult(interp, resultObj);
    break;
}
'''

The test code in ```package.test``` must be changed for test case 8.11 to:

```
test package-8.11 {Tcl_PackageCmd procedure, "present" option} -body {
    package present
} -match glob -result *
```

# Copyright

This document has been placed in the public domain.

---8><---8><---

Thank you,
Christian



_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core
  

Re: [TCLCORE] New tip #722

[Christian W. <Chr...@t-...>]

On 05/19/2025 08:31 AM, apnmbx-public--- via Tcl-Core wrote:
> Done. Note tip does not mention target version.

Thank you, Ashok.

Target version is 8.6 and above since the proposal should work for all.

Thanks again,
Christian

Re: [TCLCORE] New tip #722

[Donald G P. <don...@ni...>]

Tcl 8.6 is not open for new (sub)commands or features.

On 5/19/25 02:57, Christian Werner wrote:
> On 05/19/2025 08:31 AM, apnmbx-public--- via Tcl-Core wrote:
>> Done. Note tip does not mention target version.
>
> Thank you, Ashok.
>
> Target version is 8.6 and above since the proposal should work for all.
>
> Thanks again,
> Christian
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core


-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] New tip #722

[Christian W. <Chr...@t-...>]

On 05/19/2025 01:56 PM, Donald G Porter via Tcl-Core wrote:

> Tcl 8.6 is not open for new (sub)commands or features.

Then 9.1, as Ashok wisely put in the TIP index page.

BR,
Christian

Re: [TCLCORE] New tip #722

[Donald G P. <don...@ni...>]

Revising the behavior of an existing subcommand raises worries ( at least )
about compatibility.

Consider proposing a new subcommand instead.

On 5/19/25 01:40, Christian Werner wrote:
> Hello all,
>
> (posted again in case I've sent it with the wrong account)
>
> please could some tip fossil maintainer add the following tip.
>
> ---8><---8><---
>
> # TIP 722 Improve **package present** subcommand
>         Author:         Christian Werner <und...@gm...>
>         State:          Draft
>         Type:           Project
>         Created:        19-May-2025
>         Keywords:       Tcl,package
> -----
>
> # Abstract
>
> This TIP proposes to improve the **package present** subcommand such
> that it can be used to return a list of all currently loaded packages.
>
> # Rationale
>
> Although there is a **package names** subcommand which returns a list of
> all currently available packages there's no equivalent to retrieve the
> list of currently loaded packages. However, the latter can be of use
> e.g. to build a software bill of materials of an application or to help
> in generating a package dependency graph.
>
> # Specification
>
> For **package present** without any further arguments (which currently
> generates an error message) the implementation of **package names** is
> borrowed but its selection clause while iterating over the package hash
> table is changed to add package names to the result list for which a
> version is known (which means that the package has been loaded).
>
> ** Implementation
>
> The code block to add to the current **package present** implementation is:
>
> '''
> if (objc < 3) {
>     Tcl_Obj *resultObj;
>
>     TclNewObj(resultObj);
>     tablePtr = &iPtr->packageTable;
>     for (hPtr = Tcl_FirstHashEntry(tablePtr, &search); hPtr != NULL;
>              hPtr = Tcl_NextHashEntry(&search)) {
>         pkgPtr = Tcl_GetHashValue(hPtr);
>         if (pkgPtr->version != NULL) {
>             Tcl_ListObjAppendElement(NULL, resultObj, Tcl_NewStringObj(
>                     Tcl_GetHashKey(tablePtr, hPtr), -1));
>         }
>     }
>     Tcl_SetObjResult(interp, resultObj);
>     break;
> }
> '''
>
> The test code in ```package.test``` must be changed for test case 8.11 to:
>
> ```
> test package-8.11 {Tcl_PackageCmd procedure, "present" option} -body {
>     package present
> } -match glob -result *
> ```
>
> # Copyright
>
> This document has been placed in the public domain.
>
> ---8><---8><---
>
> Thank you,
> Christian
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core


-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] New tip #722

[Christian W. <Chr...@t-...>]

On 05/19/2025 01:58 PM, Donald G Porter via Tcl-Core wrote:

> Revising the behavior of an existing subcommand raises worries ( at least )
> about compatibility.
>
> Consider proposing a new subcommand instead.

So "package names -present", i.e. a switch to an existing subcommand isn't a nogo, too?
But from the natural language standpoint "package present" seemed the most logical to me.
Then dear native speakers please find a good alternative for me.

Thank you,
Christian

Re: [TCLCORE] New tip #722

[Christian W. <Chr...@t-...>]

On 5/19/25 14:31, Christian Werner wrote:
> On 05/19/2025 01:58 PM, Donald G Porter via Tcl-Core wrote:
>
>> Revising the behavior of an existing subcommand raises worries ( at
>> least )
>> about compatibility.
>>
>> Consider proposing a new subcommand instead.
>
> So "package names -present", i.e. a switch to an existing subcommand
> isn't a nogo, too?
> But from the natural language standpoint "package present" seemed the
> most logical to me.
> Then dear native speakers please find a good alternative for me.

Massimo Manghi gave me his proposal "package names -loaded" which IMO is
a very good choice as it smoothly fits into the current implementation of
"package names". So the "-loaded" option simply modifies the if-condition
whose block appends to the result list. Streamlined.

BR,
Christian

Re: [TCLCORE] New tip #722

[Donald G P. <don...@ni...>]

On 5/19/25 11:10, Christian Werner wrote:
> On 5/19/25 14:31, Christian Werner wrote:
>> On 05/19/2025 01:58 PM, Donald G Porter via Tcl-Core wrote:
>>
>>> Revising the behavior of an existing subcommand raises worries ( at
>>> least )
>>> about compatibility.
>>>
>>> Consider proposing a new subcommand instead.
>>
>> So "package names -present", i.e. a switch to an existing subcommand
>> isn't a nogo, too?
>> But from the natural language standpoint "package present" seemed the
>> most logical to me.
>> Then dear native speakers please find a good alternative for me.
>
> Massimo Manghi gave me his proposal "package names -loaded" which IMO is
> a very good choice as it smoothly fits into the current implementation of
> "package names". So the "-loaded" option simply modifies the if-condition
> whose block appends to the result list. Streamlined.

The existing command is [package names] with no arguments accepted.

What do you think of adding two optional argument values:

[package names provided] -- return names of packages provided in the current interp.

[package names available] -- return names of packages where some "ifneeded" script has been found.

and

[package names] -- continue to return the union of the lists described above.

This reuses the "provide" verbiage already part of [package], and avoids confusion
with the "-loaded" term that better belongs with [load], etc.

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] New tip #722

[Christian W. <Chr...@t-...>]

On 05/19/2025 05:24 PM, Donald G Porter via Tcl-Core wrote:
> On 5/19/25 11:10, Christian Werner wrote:
>> On 5/19/25 14:31, Christian Werner wrote:

>>  …
>> Massimo Manghi gave me his proposal "package names -loaded" which IMO is
>> a very good choice as it smoothly fits into the current implementation of
>> "package names". So the "-loaded" option simply modifies the if-condition
>> whose block appends to the result list. Streamlined.
>
> The existing command is [package names] with no arguments accepted.
>
> What do you think of adding two optional argument values:
>
> [package names provided] -- return names of packages provided in the current interp.
>
> [package names available] -- return names of packages where some "ifneeded" script has been found.
>
> and
>
> [package names] -- continue to return the union of the lists described above.
>
> This reuses the "provide" verbiage already part of [package], and avoids confusion
> with the "-loaded" term that better belongs with [load], etc.

Good point, Don. So may I ask Ashok again to update the TIP entry to

---8><---8><---

# TIP 722: Improve **package names** subcommand
     Author:         Christian Werner <und...@gm...>
     Tcl-Version:    9.1
     State:          Draft
     Type:           Project
     Created:        19-May-2025
     Keywords:       Tcl,package
-----

# Abstract

This TIP proposes to improve the **package names** subcommand such
that its result list can be filtered with respect to packages which are
provided (i.e. present) and packages which are not provided,
but for which a **package ifneeded** script is available.

# Rationale

Although the **package names** subcommand returns a list of all currently
provided and available packages there's no equivalent to retrieve only the
list of currently provided (i.e. present) packages. However, the latter can
be of use e.g. to build a software bill of materials of an application or
to help in generating a package dependency graph.

# Specification

For **package names** without any further arguments (current default
mode of operation) the result list is made up of package names which are
provided or for which a **package ifneeded** script is available.

For **package names available** the list contains only the packages
which are not provided (i.e. not present) but for which a **package ifneeded**
script is available.

For **package names provided** the list contains only the currently provided
(i.e. present) packages.

# Implementation

TBD.

# Copyright

This document has been placed in the public domain.

---8><---8><---

Thank you,
Christian

Re: [TCLCORE] New tip #722

[<apn...@ya...>]

Update done. (Could someone with the right privileges please give TIP
repository write access to Christian?)

Since we are tinkering with [package names], I'd like to point out that the
term "available" is a little misleading, even in the current manpage.
Currently, [package names] only returns names *currently* known to Tcl, not
those available on disk. One has to do the completely non-intuitive

catch {package require nosuchpackage}; # Force a full search along path
package names

to retrieve the packages available to be loaded.

So the question is,

- will [package names available] continue the same behavior of not actually
searching the package paths ?
- if it does not do a full search, can we add a [package names refresh] that
will replace the (ugly imo) catch {} ?
- if it does do a full search, [package names] as currently implemented is
no longer the union of [package names loaded] and [package names available]

I would actually prefer [package names] to do a full search though that
would be differ from current behavior. I'm not sure why it did not do that
in the first place, presumably performance, though I wonder if performance
is really an issue in situations where [package names] is used.

/Ashok

-----Original Message-----
From: Christian Werner <Chr...@t-...> 
Good point, Don. So may I ask Ashok again to update the TIP entry to

Re: [TCLCORE] New tip #722

[Schelte B. <tc...@tc...>]

On 20/05/2025 04:34, apnmbx-public--- via Tcl-Core wrote:
> Could someone with the right privileges please give TIP
> repository write access to Christian?

Done.


Schelte.

Re: [TCLCORE] New tip #722

[da S. P. J <pet...@fl...>]

It sounds like “package names” is misleading, but transitioning to a better name is problematic.

I am not sure it should automatically walk the file system implicitly, will that include vfs mounts? If it does, a way to refresh the list still needs to be available so that newly loaded vfs mounts, dynamically created packages (eg Speedtables), and packages installed after startup can be enumerated.

From: apnmbx-public--- via Tcl-Core <tcl...@li...>
Date: Monday, May 19, 2025 at 21:37
To: ch...@ch... <ch...@ch...>
Cc: 'Tcl Core' <tcl...@li...>
Subject: Re: [TCLCORE] New tip #722
Update done. (Could someone with the right privileges please give TIP repository write access to Christian?) Since we are tinkering with [package names], I'd like to point out that the term "available" is a little misleading, even in the current


Update done. (Could someone with the right privileges please give TIP

repository write access to Christian?)



Since we are tinkering with [package names], I'd like to point out that the

term "available" is a little misleading, even in the current manpage.

Currently, [package names] only returns names *currently* known to Tcl, not

those available on disk. One has to do the completely non-intuitive



catch {package require nosuchpackage}; # Force a full search along path

package names



to retrieve the packages available to be loaded.



So the question is,



- will [package names available] continue the same behavior of not actually

searching the package paths ?

- if it does not do a full search, can we add a [package names refresh] that

will replace the (ugly imo) catch {} ?

- if it does do a full search, [package names] as currently implemented is

no longer the union of [package names loaded] and [package names available]



I would actually prefer [package names] to do a full search though that

would be differ from current behavior. I'm not sure why it did not do that

in the first place, presumably performance, though I wonder if performance

is really an issue in situations where [package names] is used.



/Ashok



-----Original Message-----

From: Christian Werner <Chr...@t-...>

Good point, Don. So may I ask Ashok again to update the TIP entry to











_______________________________________________

Tcl-Core mailing list

Tcl...@li...

https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!MvWE!HhoyC6t3Z3QsMpJKI6zRG93Z-SlDggeyL8FzYh9mbmI_bY__OdNgKVlzyqV85ShKRFbc9ia1Q_otKhptMeOMyzoYZ2mxovQI6g$<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/tcl-core__;!!MvWE!HhoyC6t3Z3QsMpJKI6zRG93Z-SlDggeyL8FzYh9mbmI_bY__OdNgKVlzyqV85ShKRFbc9ia1Q_otKhptMeOMyzoYZ2mxovQI6g$>

Re: [TCLCORE] New tip #722

[Donald G P. <don...@ni...>]

On 5/19/25 22:34, apnmbx-public--- via Tcl-Core wrote:
> Since we are tinkering with [package names], I'd like to point out that the
> term "available" is a little misleading, even in the current manpage.
> Currently, [package names] only returns names *currently* known to Tcl, not
> those available on disk. One has to do the completely non-intuitive
>
> catch {package require nosuchpackage}; # Force a full search along path
> package names
>
> to retrieve the packages available to be loaded.
>
> So the question is,
>
> - will [package names available] continue the same behavior of not actually
> searching the package paths ?

Short answer:
[package names available] should only report names of packages with ifneeded scripts
already recorded in Tcl's memory.  This command should not prompt a search.

If that makes "available" a misleading name, then it should change to something more accurate.
> - if it does not do a full search, can we add a [package names refresh] that
> will replace the (ugly imo) catch {} ?
> - if it does do a full search, [package names] as currently implemented is
> no longer the union of [package names loaded] and [package names available]

These ideas are digging deeper into the [package unknown] problems, and that is a much
deeper rabbit hole than we want to explore in this TIP I think.

For those who have forgotten, or never learned, the [package] command is customizable.

The [package unknown] command permits an app or an installation to replace Tcl's
default package finder with another one better suited to any local method of package
storage.

The default package finder is [tclPkgUnkown].  It is implemented in a way that if
you ask it to go find package "foo", along the way it may discover and record the
ifneeded scripts of packages "bar" and "baz" as well.  ***This behavior is not in the
[package unknown] contract***  Custom [package unknown] replacements need not
and probably will not have that "discover all the packages" functionality.

When you invoke the incantation [package require nosuch], you are not using any
[package] command feature.  You are using a side effect of [tclPkgUnknown].

If we need a "report all the findable packages" functionality to exploit, step one will
have to be to extend or replace the [package unknown] mechanism. That's a bigger
project that will have slower progress and better not joined to this fairly simple proposal.

If your curiosity is sparked by any of this, you might enjoy an ancient presentation
on the subject.

https://math.nist.gov/~DPorter/tcltk/oscon/

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] New tip #722

[<apn...@ya...>]

Don,

Thanks for the exposition. You are right my suggestion would lead to a deep rabbit hole and should not be considered.

/Ashok

-----Original Message-----
From: Donald G Porter via Tcl-Core <tcl...@li...> 
Sent: Tuesday, May 20, 2025 5:39 PM
To: tcl...@li...
Subject: Re: [TCLCORE] New tip #722

On 5/19/25 22:34, apnmbx-public--- via Tcl-Core wrote:
> Since we are tinkering with [package names], I'd like to point out that the
> term "available" is a little misleading, even in the current manpage.
> Currently, [package names] only returns names *currently* known to Tcl, not
> those available on disk. One has to do the completely non-intuitive
>
> catch {package require nosuchpackage}; # Force a full search along path
> package names
>
> to retrieve the packages available to be loaded.
>
> So the question is,
>
> - will [package names available] continue the same behavior of not actually
> searching the package paths ?

Short answer:
[package names available] should only report names of packages with ifneeded scripts
already recorded in Tcl's memory.  This command should not prompt a search.

If that makes "available" a misleading name, then it should change to something more accurate.
> - if it does not do a full search, can we add a [package names refresh] that
> will replace the (ugly imo) catch {} ?
> - if it does do a full search, [package names] as currently implemented is
> no longer the union of [package names loaded] and [package names available]

These ideas are digging deeper into the [package unknown] problems, and that is a much
deeper rabbit hole than we want to explore in this TIP I think.

For those who have forgotten, or never learned, the [package] command is customizable.

The [package unknown] command permits an app or an installation to replace Tcl's
default package finder with another one better suited to any local method of package
storage.

The default package finder is [tclPkgUnkown].  It is implemented in a way that if
you ask it to go find package "foo", along the way it may discover and record the
ifneeded scripts of packages "bar" and "baz" as well.  ***This behavior is not in the
[package unknown] contract***  Custom [package unknown] replacements need not
and probably will not have that "discover all the packages" functionality.

When you invoke the incantation [package require nosuch], you are not using any
[package] command feature.  You are using a side effect of [tclPkgUnknown].

If we need a "report all the findable packages" functionality to exploit, step one will
have to be to extend or replace the [package unknown] mechanism. That's a bigger
project that will have slower progress and better not joined to this fairly simple proposal.

If your curiosity is sparked by any of this, you might enjoy an ancient presentation
on the subject.

https://math.nist.gov/~DPorter/tcltk/oscon/

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|



_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] New tip #722

[Donald P. <d.g...@co...>]

> If that makes "available" a misleading name, then it should change to something more accurate.

Perhaps [package names known] conveys better what the command does.

DGP