tcltk-registry

Why:

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.

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.

Adding a package:

Submit a PR adding your package to packages.json. The registry is automatically rebuilt daily.

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!

Please:

Spread the word: Share it with anyone learning Tcl/Tk.

Six-month check-in :

We're now halfway through the one-year adventure I signed up for, and I'm happy to say the registry is still here.

I won't pretend I expected a stampede. I know everyone is busy and Tclers are a pleasantly low-key bunch.

But I did hope this might become a little communal nook where people occasionally drop a package link to something they found useful.

So far, it's mostly been me talking to myself and a few people (2) thanks to them.

So here's a gentle nudge: if you know a package worth sharing yours or someone else's, I'd love to hear about it.

And if GitHub pull requests feel like a hassle, just open an issue with the name, link, and a sentence about what it does. I'll add it with pleasure and zero judgment.

Thanks to all

APN 2026-02-19 I hope this succeeds too! One suggestion I have is to differentiate between the source repository and the download link. For Tcl for example, the source repository may point to core.tcl-lang.org but the (optional) download link would point to the SourceForge download area. There does not seem to be a field to specify the latter.

NR 2026-02-20 I will implement this distinction by adding an optional artifacts field to the source objects. This allows specifying where the built releases, tarballs, or binaries are hosted when it's different from the source repository. To enforce this policy strictly, the GitHub Actions validation workflow will be updated to actively check that URLs do not point to direct file downloads. Pull requests containing direct download links will be rejected automatically

{
  "name": "tcl",
  "sources": [
    {
      "url": "https://core.tcl-lang.org/tcl",
      "method": "fossil",
      "web": "https://www.tcl-lang.org/",
      "artifacts": "https://sourceforge.net/projects/tcl/files/",
      "author": "Tcl Core Team",
      "license": "Tcl/Tk"
    }
  ]
}

What do you think about that?

APN Makes sense. I will start adding my packages this weekend.

Jeff Smith 2026-02-20 : I hope this succeeds also! I can see myself as being one of the people this would be a benefit a great deal.

NR 2026-02-20 "I hope this succeeds also!". I hope so! thanks.

JMN 2026-09-09. I find this useful, nice work! - but to be relied on as a community asset, I think it should at least have a 'designated trusted successor' being another member of the community - preferably someone on Tcl Core. This is a private setting that isn't publicly visible (unfortunately) - but I think finding someone who would accept the role and adding and a note in the readme would be a good idea. It's not nice to think about 'bus factor' - but I've been around long enough to see maintainers disappear for one reason or another.

NR 2026-09-10. That was actually already in my mind, but I didn’t want to impose the idea. I wanted to wait a little, see whether the registry generated real community interest through pull requests and issues, and then submit the idea for discussion.

Thanks for the advice — I think it is a very good point.