2026/01/06

Extension package registry

We just renewed the Gauche homepage. It's mostly cosmetics, but one notable change is the Extension Packages page

It's been in our todo list for very long time to create some system to track Gauche extension packages. It is trivial to create a site where users can put the info. What's not trivial is how to keep the info updated.

It's a burden to the user if we ask them to keep updating such info whenever they update their extension package.

If a user puts their website/email for the package, but then moves away from Gauche development, and eventually the site/email become inactive and go away, we don't know what to do with the entry; it'd be also difficult if somebody wants to take over the project.

Should anybody be able to update the package's info? Limiting it to the original authors becomes an issue if they go inactive and out of touch. Allowing it may cause a security issue if someone replaces the distribution URL to malicious one.

To vet the users entering info, we need some mechanism of user registration and authentication, which adds another database to maintain.

These implications kept us from implementing the official mechanism to provide the extension package registry.

Things has changed in the last decate or so.

First, distributed VCS and their hosting services have become a norm. Instead of having personal websites to serve extension package tarballs and documents, developers can put their repository on one of those services and make it public.

Recent Gauche provides a standard framework of building extensions. One important aspect of it is package.scm in the source tree to keep meta information about the package, including version number, authors, "official" repository url, dependencies, etc.

So, once we know the package's repository URL, we can get its meta information!

The author updates package.scm as the development proceeds, because it is a part of the source. No need to update information on the registry separately.

Anybody can create account on those services, but the service gives certain identity to each one and the place to interact with each other. Sure, people move away eventually, but it's rarely that they bother to remove the repositories; and it's easy to inherit the abandoned project.

We already have a official way to state such transfer of control in package.scm (superseded-by slot). If the successor can contact the original author/maitainer/committer, the package.scm in the original repository can have superseded-by field pointing to the new repository. It is not mandatory, but it can make it clear where is the "official" successor.

In other words, we can use the existing public repositories as the metadata database, and merely maintain pointers to them by ourselves.

So, how to manage those pointers? We don't have thousands of extension packages updated daily, so we don't need a sophisticated database server for it.

We decided to piggyback on the public DVCS service again. Gauche package repository index github repo maintains the list of package urls under its packages directory. If you want your packages to be listed, just fork it, add your package, and send a pull request. (If you don't want to use GitHub, just send a patch via email.)

Which repository is added when, by whose request, is recorded in the commits of that repo.

Currenly, pulling metadata and reflecting it on the webpage is done in occasional batch process. We'll adjust the frequency as it goes. If we ever get very popular and receiving tons of new package registration requests, we might need to upgrade the system, but until then, this will be the least-maintenance-cost solution.

To be in the registry, your extension package needs package.scm. I scanned through the existing list on wiki (WiLiKi:Gauche:Packages) and added packages that I could find the public repository with package.scm.

If your extension is old enough not to have package.scm, a convenient way is to run gauche-package populate in the top directory of the source tree. It gives you a template package.scm with some fields filled by whatever information it can find.

Tag: Extensions