From Newsgroup: comp.lang.tcl


Hey everyone,

I've noticed that finding Tcl/Tk packages is still surprisingly hard for newcomers.
Between scattered wikis, old forum posts, and repos buried in various forges, it's not easy when you're just starting out.
So I built something to fix that: a centralized, searchable package registry specifically designed to help beginners (and veterans!).

Live site: https://tcltk-pkgs.pages.dev

Search by name, filter by tags (json, gui, database, etc.)
Clean interface with direct links to repos and docs

The deal:
I've set myself a 1-year mission for this project. Not because I want it to end,
but because I genuinely hope the community will adopt it and prove me wrong about having to shut it down.
I have high hopes - let's make this thing survive so I don't have to write a "farewell" post that makes us all sad!

A word on sustainability:
This is currently a demonstration/prototype running entirely on free tiers (Cloudflare Pages, GitHub Actions).
While these services are reliable for now, we all know that free hosting policies can change.
I can't guarantee this will be viable medium-to-long term if limits are imposed or policies change.
If the project gains traction, I'll look into more permanent hosting solutions, but for now, consider this a "best effort" community experiment.

How to help:
If you maintain a package:
Please add it! Just submit a PR to the GitHub repo with your package info (takes 2 minutes).

If you're a beginner: Try it out and tell me what's missing or confusing. Spread the word: Share it with anyone learning Tcl/Tk.
Repo: https://github.com/tcltk-pkgs/registry

Thanks!

Nicolas
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl


Note :
If you know a useful package (even if it's not yours): Don't hesitate to add it! This is a community registry, not just an author registry.
If you found a great tool that helped you, chances are it will help others too.

Thanks again!
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 18.02.2026 um 19:06 schrieb Nicolas ROBERT:

Note :
If you know a useful package (even if it's not yours): Don't hesitate to add it! This is a community registry, not just an author registry.
If you found a great tool that helped you, chances are it will help others too.

Thanks again!

Yes, Nicolas, great.
You may also cite your tak at the conference.

Thanks for all,
Harald
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Yes, Nicolas, great.
You may also cite your tak at the conference.

Thanks for all,
Harald

I think you might be confusing me with someone else!
This is a personal project I just launched, not something presented at a conference.

Thanks

Nicolas
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

I welcome the idea.

Note that efforts/products with a similar purpose already exist.
An example is here:

https://core.tcl-lang.org/jenglish/gutter/

I think it's wise to learn from those previous attempts/products, e.g.
- what is their current usage?
- if they are not used to the degree that you envisage for your package registry,
then why is that so?
- ...

Erik.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl


Erik Leunissen <elns@xs4all.nl> posted:

I welcome the idea.

Note that efforts/products with a similar purpose already exist.
An example is here:

https://core.tcl-lang.org/jenglish/gutter/

I think it's wise to learn from those previous attempts/products, e.g.
- what is their current usage?
- if they are not used to the degree that you envisage for your package registry,
then why is that so?
- ...

Erik.

Thank you for sharing this! Honestly, I wasn't aware of this project, and I don't yet know why it didn't gain more traction.
I'm just someone who had this idea and wanted to give it a try.
If you have any insight on what went wrong with previous attempts, I'd really appreciate hearing it rCo it would help me avoid making the same mistakes.

Thanks

Nicolas
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 2/18/26 21:58, Nicolas ROBERT wrote:

Thank you for sharing this! Honestly, I wasn't aware of this project, and I don't yet know why it didn't gain more traction.
I'm just someone who had this idea and wanted to give it a try.
If you have any insight on what went wrong with previous attempts, I'd really appreciate hearing it rCo it would help me avoid making the same mistakes.

I cannot say for sure. I remember having thought of setting up such an infrastructure myself, long
ago. Never did it, so I didn't work through all the issues.

But I remember one important design issue of a database of extensions is:

Who is responsible for keeping the info (version info) for a certain package
up to date, including the very first registration of a new package ?

Back then, I believed that it was important to leave that responsibility to the extension author,
and I still do think so. Of course, the flip-side is that the system needs to provide a
user-friendly method for package authors to provide updated information at each new release. (Maybe
this can be automated as an internet service?)

It's easy to imagine what goes wrong if that responsibility is assumed by the person
managing/administering the package database: at some point in time, lack of resources will make that
the information becomes outdated, less and less useful, less and less used.

So, my advice would be to design a system that offers a procedure/interface where package authors
can update package information themselves.

Erik Leunissen.
--

Thanks

Nicolas

--
elns@ nl | Merge the left part of these two lines into one,
xs4all. | respecting a character's position in a line.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 18.02.2026 um 19:40 schrieb Nicolas ROBERT:

Yes, Nicolas, great.
You may also cite your tak at the conference.

Thanks for all,
Harald

I think you might be confusing me with someone else!
This is a personal project I just launched, not something presented at a conference.

Thanks

Nicolas

I think, Harald remembered this talk, which had a similar topic: https://learn.wu.ac.at/eurotcl2025/lecturecasts/753988260?m=delivery

The repository mentioned in the talk can be found here: https://tclrepo.daidze.org/index.adp

Paul
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl


Erik Leunissen <elns@xs4all.nl> posted:

On 2/18/26 21:58, Nicolas ROBERT wrote:

Thank you for sharing this! Honestly, I wasn't aware of this project, and I don't yet know why it didn't gain more traction.
I'm just someone who had this idea and wanted to give it a try.
If you have any insight on what went wrong with previous attempts, I'd really appreciate hearing it rCo it would help me avoid making the same mistakes.

I cannot say for sure. I remember having thought of setting up such an infrastructure myself, long
ago. Never did it, so I didn't work through all the issues.

But I remember one important design issue of a database of extensions is:

Who is responsible for keeping the info (version info) for a certain package
up to date, including the very first registration of a new package ?

Back then, I believed that it was important to leave that responsibility to the extension author,
and I still do think so. Of course, the flip-side is that the system needs to provide a
user-friendly method for package authors to provide updated information at each new release. (Maybe
this can be automated as an internet service?)

It's easy to imagine what goes wrong if that responsibility is assumed by the person
managing/administering the package database: at some point in time, lack of resources will make that
the information becomes outdated, less and less useful, less and less used.

So, my advice would be to design a system that offers a procedure/interface where package authors
can update package information themselves.

Erik Leunissen.
--

Thanks

Nicolas

That's a very valid concern, Erik.
However, I think there might be a misunderstanding about my approach.

I don't manually maintain version numbers or metadata.
The registry uses automated Git scraping (via GitHub Actions) to discover package information directly from source repositories - git ls-remote picks up new tags automatically, and the metadata file is regenerated daily without human intervention.
When an author pushes a new tag to their repo, the registry picks it up within 24 hours automatically. Nobody needs to update the registry manually when they release.

Regarding Fossil: To be honest, I haven't fully tested Fossil support yet. The Fossil packages currently listed have GitHub mirrors, so the automated scraping works for them via Git.
True Fossil repository scraping would require different tooling that I haven't implemented yet.

Importantly, there is no "version number" written in the public JSON that needs updating.

The packages.json only contains repository URLs as "pointers" - regardless of whether it's GitHub, GitLab, or elsewhere.
The actual version metadata is fetched automatically at build time by querying the source repositories directly.

So if a package moves from GitHub to GitLab, or if it's hosted on a custom domain, it doesn't matter - as long as the Git URL is valid, the workflow extracts the current state dynamically.
Additionally, if a package no longer exists or the URL becomes invalid, the workflow detects this and marks the package status accordingly in the generated metadata (indicating the source is unavailable, rather than showing stale or fake data).
The entry remains in the registry for reference, but users are informed that the package is currently inaccessible.

Does this address your concern about the maintenance bottleneck ?

The registry doesn't store static version state that can become "outdated" - it regenerates fresh metadata daily from the sources themselves, reflecting both updates and availability issues automatically.

Thanks

Nicolas
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 2/18/26 23:59, Nicolas ROBERT wrote:

However, I think there might be a misunderstanding about my approach.

Oh that's very well possible. Sorry if my remarks are inapplicable.

I don't manually maintain version numbers or metadata.
The registry uses automated Git scraping (via GitHub Actions) to discover package information directly from source repositories - git ls-remote picks up new tags automatically, and the metadata file is regenerated daily without human intervention.
When an author pushes a new tag to their repo, the registry picks it up within 24 hours automatically. Nobody needs to update the registry manually when they release.

Regarding Fossil: To be honest, I haven't fully tested Fossil support yet. The Fossil packages currently listed have GitHub mirrors, so the automated scraping works for them via Git.
True Fossil repository scraping would require different tooling that I haven't implemented yet.

Importantly, there is no "version number" written in the public JSON that needs updating.

The packages.json only contains repository URLs as "pointers" - regardless of whether it's GitHub, GitLab, or elsewhere.
The actual version metadata is fetched automatically at build time by querying the source repositories directly.

So if a package moves from GitHub to GitLab, or if it's hosted on a custom domain, it doesn't matter - as long as the Git URL is valid, the workflow extracts the current state dynamically.
Additionally, if a package no longer exists or the URL becomes invalid, the workflow detects this and marks the package status accordingly in the generated metadata (indicating the source is unavailable, rather than showing stale or fake data).
The entry remains in the registry for reference, but users are informed that the package is currently inaccessible.

Does this address your concern about the maintenance bottleneck ?

The most important thing regarding the maintenance issue is that you're aware of it yourself. Alas,
in the short term I'm not in a position where I can evaluate the approach that you describe in the
detail that it deserves.

Good luck!

Erik.

The registry doesn't store static version state that can become "outdated" - it regenerates fresh metadata daily from the sources themselves, reflecting both updates and availability issues automatically.

Thanks

Nicolas

--
elns@ nl | Merge the left part of these two lines into one,
xs4all. | respecting a character's position in a line.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl


Erik Leunissen <elns@xs4all.nl> posted:

On 2/18/26 23:59, Nicolas ROBERT wrote:

However, I think there might be a misunderstanding about my approach.

Oh that's very well possible. Sorry if my remarks are inapplicable.

I don't manually maintain version numbers or metadata.
The registry uses automated Git scraping (via GitHub Actions) to discover package information directly from source repositories - git ls-remote picks up new tags automatically, and the metadata file is regenerated daily without human intervention.
When an author pushes a new tag to their repo, the registry picks it up within 24 hours automatically. Nobody needs to update the registry manually when they release.

Regarding Fossil: To be honest, I haven't fully tested Fossil support yet. The Fossil packages currently listed have GitHub mirrors, so the automated scraping works for them via Git.
True Fossil repository scraping would require different tooling that I haven't implemented yet.

Importantly, there is no "version number" written in the public JSON that needs updating.

The packages.json only contains repository URLs as "pointers" - regardless of whether it's GitHub, GitLab, or elsewhere.
The actual version metadata is fetched automatically at build time by querying the source repositories directly.

So if a package moves from GitHub to GitLab, or if it's hosted on a custom domain, it doesn't matter - as long as the Git URL is valid, the workflow extracts the current state dynamically.
Additionally, if a package no longer exists or the URL becomes invalid, the workflow detects this and marks the package status accordingly in the generated metadata (indicating the source is unavailable, rather than showing stale or fake data).
The entry remains in the registry for reference, but users are informed that the package is currently inaccessible.

Does this address your concern about the maintenance bottleneck ?

The most important thing regarding the maintenance issue is that you're aware of it yourself. Alas,
in the short term I'm not in a position where I can evaluate the approach that you describe in the
detail that it deserves.

Good luck!

Erik.

In any case, thank you for responding and giving me your advice.
If you think it's a good idea, try to share it if you can.

Thanks

Nicolas

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* Nicolas ROBERT <user10104@newsgrouper.org.invalid>
| I've noticed that finding Tcl/Tk packages is still surprisingly hard
| for newcomers. Between scattered wikis, old forum posts, and repos
| buried in various forges, it's not easy when you're just starting out.
| So I built something to fix that: a centralized, searchable package
| registry specifically designed to help beginners (and veterans!).

| Live site: https://tcltk-pkgs.pages.dev
--<snip-snip>--
| If you're a beginner: Try it out and tell me what's missing or confusing.

Cudos for the initiative!

Some thought on using the web interface:
- I'm missing an "all packages" button (though of course I can search
for the empty string, which obviously lists all packages, but I find
that 'urks')

- after I locate a package, how do I install it?
for example, if I sort "most recent first", the first entry currently
is 'textutil'. That page has two links, which lead me to the
tcllib-textutil submodule and its documentation.

But of course, if I wish to use that module, the canonical way would
be to install whole tcllib, not the individual module, no?

So for me there is missing the information that some package is part
of a larger library package, and probably cannot be used without other
modules of that library.

For all those subpackages of tcllib (or any other library-like
package), I would rather have some tree-like display than a flat list,
or something like https://core.tcl-lang.org/tcllib/doc/trunk/embedded/md/toc.md

On submission of new modules:
- is there any check on the validity of submitted entries?
I.e. if I were a malicious attacker, I'd submit some Github project with
a modified version of a well known package or something like that.
Yes, I can do that in the wiki, too. But if your page at one point
has earned some reputation of a valuable resource, this might be dangerous.

I don't know if and how other archives like python (pip) or
microcontrollers (arduino etc) handle that problem...

My re40.01
R'
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl


Ralf Fassel <ralfixx@gmx.de> posted:

Cudos for the initiative!

Some thought on using the web interface:
- I'm missing an "all packages" button (though of course I can search
for the empty string, which obviously lists all packages, but I find
that 'urks')

- after I locate a package, how do I install it?
for example, if I sort "most recent first", the first entry currently
is 'textutil'. That page has two links, which lead me to the
tcllib-textutil submodule and its documentation.

But of course, if I wish to use that module, the canonical way would
be to install whole tcllib, not the individual module, no?

So for me there is missing the information that some package is part
of a larger library package, and probably cannot be used without other
modules of that library.

For all those subpackages of tcllib (or any other library-like
package), I would rather have some tree-like display than a flat list,
or something like https://core.tcl-lang.org/tcllib/doc/trunk/embedded/md/toc.md

On submission of new modules:
- is there any check on the validity of submitted entries?
I.e. if I were a malicious attacker, I'd submit some Github project with
a modified version of a well known package or something like that.
Yes, I can do that in the wiki, too. But if your page at one point
has earned some reputation of a valuable resource, this might be dangerous.

I don't know if and how other archives like python (pip) or
microcontrollers (arduino etc) handle that problem...

My re40.01
R'

Thank you for the detailed feedback! These are exactly the kinds of real-world usage issues I need to hear about.

"All packages" button: You're absolutely right, that's a UX oversight.
I'll add a proper "Show all" button (probably an F5-style refresh/browse button) to avoid the empty search workaround.

Tcllib submodules/hierarchy: You've identified a tricky edge case.
Tcllib is special because it's a monorepo with many submodules (textutil, struct, etc.) that appear as separate packages but are actually part of the larger library.
Honestly, I don't have a clean solution for this yet - I could add a "parent_package" field, but I'm not sure I'll implement that complexity immediately.
I need to think about whether to show them as separate entries with "part of tcllib" badges, or group them differently.
For now, I should at least add a note on those pages explaining "This is part of tcllib - refer to tcllib's documentation."

Installation context: You're right that this clarity is missing. I believe detailed installation instructions should live in the package's own documentation (README, etc.), not necessarily generated by the registry.

Security/validation: This is a hard unsolved problem. Currently it's PR-based community review, but you're correct that without maintainer verification or reputation scoring, this could become a target for typosquatting if it gains traction.
I don't have a technical solution for this yet - it's "trust but verify" for now, which I acknowledge doesn't scale.

Thanks

Nicolas

PS: For the moment, the website is on a private repository. As soon as it becomes public, you will be able to open an issue and ask me for improvements or suggestions (if, of course, you agree to create a GitHub account !).


--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl


Nicolas ROBERT <user10104@newsgrouper.org.invalid> posted:

I've noticed that finding Tcl/Tk packages is still surprisingly hard for newcomers.
Between scattered wikis, old forum posts, and repos buried in various forges, it's not easy when you're just starting out.
So I built something to fix that: a centralized, searchable package registry specifically designed to help beginners (and veterans!).

Pourquoi faire simple quand on peut faire compliqu|- ... :-/

I certainly will be blamed and put into flames , but I want to give my opinion (after all Donal Tr. is not a member here !). I know you work hard for the benefit
of us, but why not to propose it BEFORE all this labour.

I've noticed that finding Tcl/Tk packages is still surprisingly hard for newcomers.

Yes and no, for instance your clever little package "tomato" is difficult to find unless,
its name is already known and is not on your proposed portal. Who then will maintain
this portal ? Wouldn't it better to concentrate on what is existing and works ?

I am far to be a true programmer, unable to compile (yet) Tcl by myself, unable to understand why
object programming is useful etc. I simply use the installation binaries of Ashok
or Paul (they have all inside) and if I need to see a detail I go to /core.tcl-lang.org .
If I need an idea or do this or that, I go to wiki.tcl-lang.org. It is not so hard.

Now after being reduced to ashes, I think I will be buried six feet underground to express a subject out of the topic, but similar :

Changing [ expr {...} ] into {=}{...} , is only a difference of 3 characters. There
was a discussion about it before a TIP was emitted, so if I would have disagreed
I should have said BEFORE, but I am afraid that Tcl will become more complicated
as both writing will coexist, and this arising complexity that frighten me.
I am dealing with Tcl/Tk since Tcl 7.3 and Tk 3.6 because Tcl stays, let's
say pure, and you can embrace tclib and tklib in one go (Thanks Arjen and all others).

That said, I respect your work because I am unable to make what you have made, and because some found it useful. It will be accepted by young programmers used to modern interface, but I prefer my notepad++ with its projects and workspaces of my browser
to manage tcllib, tklib, tcl and tk revisions.

It is done, I am volatilized, grumbling ...

Olivier.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl


Olivier <user1108@newsgrouper.org.invalid> posted:

Pourquoi faire simple quand on peut faire compliqu|- ... :-/

I certainly will be blamed and put into flames , but I want to give my opinion
(after all Donal Tr. is not a member here !). I know you work hard for the benefit
of us, but why not to propose it BEFORE all this labour.

I've noticed that finding Tcl/Tk packages is still surprisingly hard for newcomers.

Yes and no, for instance your clever little package "tomato" is difficult to find unless,
its name is already known and is not on your proposed portal. Who then will maintain
this portal ? Wouldn't it better to concentrate on what is existing and works ?

I am far to be a true programmer, unable to compile (yet) Tcl by myself, unable to understand why
object programming is useful etc. I simply use the installation binaries of Ashok
or Paul (they have all inside) and if I need to see a detail I go to /core.tcl-lang.org .
If I need an idea or do this or that, I go to wiki.tcl-lang.org. It is not so hard.

(...)

Olivier.

Thank you for your honest opinion - and no, you won't be put in flames! Different perspectives are valuable. You're absolutely right that wiki.tcl-lang.org exists.

About tomato not being there : you're correct, and that's partly my fault. When I started coding it, I was a beginner and found the wiki editing process intimidating - I was afraid of breaking something or not following the conventions.
So I didn't create a wiki page, which proves your point : the barrier to entry for contributing to the wiki can be high for newcomers.

Let me share why I built this registry from my own experience as a beginner : when I needed to work with XML, I searched the wiki for "XML", and honestly - did tdom come up first? No. I had to dig through pages.
The wiki has the information, but it's not always structured for easy discovery when you don't know exactly what you're looking for.

This registry aims to lower that barrier : adding a package is just a JSON entry via GitHub PR, no need to learn wiki markup or fear breaking existing pages.
If tomato had existed in this registry format, I would have added it immediately without worrying about "doing it wrong." (personal opinion)

When you already know what you need, the wiki is perfect. But for discovery and for shy beginners who hesitate to edit the wiki, this might be a gentler entry point.

Regarding maintenance : that's why I limited myself to 1 year. If it helps even a few people discover packages without the wiki anxiety I felt, it's worth the experiment.

I understand the "why complicate things" sentiment.
If you find the wiki sufficient, by all means continue using it - this is just an alternative for those who prefer searching over navigating wiki hierarchies or fear editing them.

That said, I might be waking up a bit late to the party. With AI assistants now ubiquitous, any beginner asking "how to parse XML in Tcl" will get tdom as the first answer instantly, no registry needed.
Still, structured open data in JSON format might remain valuable for AI training or for building other tools, so hopefully it's not entirely obsolete yet!

Thanks

Nicolas
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl


Nicolas ROBERT <user10104@newsgrouper.org.invalid> posted:

Olivier <user1108@newsgrouper.org.invalid> posted:

Pourquoi faire simple quand on peut faire compliqu|- ... :-/

I certainly will be blamed and put into flames , but I want to give my opinion
(after all Donal Tr. is not a member here !). I know you work hard for the benefit
of us, but why not to propose it BEFORE all this labour.

.....
.....

(...)

Olivier.

Thank you for your honest opinion - and no, you won't be put in flames! Different perspectives are valuable. You're absolutely right that wiki.tcl-lang.org exists.

About tomato not being there : you're correct, and that's partly my fault. When I started coding it, I was a beginner and found the wiki editing process intimidating - I was afraid of breaking something or not following the conventions.
So I didn't create a wiki page, which proves your point : the barrier to entry for contributing to the wiki can be high for newcomers.

Let me share why I built this registry from my own experience as a beginner :
when I needed to work with XML, I searched the wiki for "XML", and honestly - did tdom come up first? No. I had to dig through pages.
The wiki has the information, but it's not always structured for easy discovery when you don't know exactly what you're looking for.

This registry aims to lower that barrier : adding a package is just a JSON entry via GitHub PR, no need to learn wiki markup or fear breaking existing pages.
If tomato had existed in this registry format, I would have added it immediately without worrying about "doing it wrong." (personal opinion)

When you already know what you need, the wiki is perfect. But for discovery and for shy beginners who hesitate to edit the wiki, this might be a gentler entry point.

Regarding maintenance : that's why I limited myself to 1 year. If it helps even a few people discover packages without the wiki anxiety I felt, it's worth the experiment.

I understand the "why complicate things" sentiment.
If you find the wiki sufficient, by all means continue using it - this is just an alternative for those who prefer searching over navigating wiki hierarchies or fear editing them.

That said, I might be waking up a bit late to the party. With AI assistants now ubiquitous, any beginner asking "how to parse XML in Tcl" will get tdom as the first answer instantly, no registry needed.
Still, structured open data in JSON format might remain valuable for AI training or for building other tools, so hopefully it's not entirely obsolete yet!

Thanks

Nicolas

Thank you for your understanding. I must say that my opinion is a bit biased because
I "grew" up with wiki and saw its beginning. So I know its history and it is easier
to find something. There is also the fact that I am concerned in FEA software and EDA
where format and specifications are more stable (no XLM only CSV !) . Concerning AI, it is the contrary,
you are not late because references and safe sources will be needed so without doubt
your portal will help newcomers. Hopefully you will succeed. After all I already
grumbled when the wiki was created , thinking about a new gadget .. but I was wrong !

Olivier
--- Synchronet 3.21b-Linux NewsLink 1.2