The Federalisation of Package Repos

Under various names (sometimes referred to as ‘plugins’, sometimes as ‘packages’), the (official) package repository was part of a sub-project within the NumeRe project and was hosted on SourceForge. General availability was acceptable, meaning that packages could almost always be downloaded and installed. There was also version control, although SVN is comparatively slow.

What, on the other hand, didn’t work very well – or not at all – was collaboration. There were two possible approaches:

• Send the package to be uploaded by email and hope that we would upload it

• Set up a SourceForge account, get access granted to our repository, and then have to struggle with SVN

As was to be expected, nobody made any significant contributions. And that’s a real shame, because we firmly believe that there is code out there that would actually be ideal for sharing via a proper repository.

Even though there is some controversy surrounding GitHub, this platform is still excellent for collaboration. In particular, because GitHub still provides a very ‘generous’ REST API, which allows us to interact with the package manager without having to rely on Git straight away. In any case, we have decided to host the ‘official’ package repository on GitHub from now on, thereby creating a significantly better opportunity for collaboration.

We have also made some changes to the structure of the repository, drawing inspiration from the WinGet repository. Consequently, the packages are sorted into their respective folders, which in turn contain folders for the version numbers. These in turn contain the actual package file as well as a meta.json manifest. The manifest summarises all the meta-information about the packages and is a much smaller file than the actual package. This allows us to save on bandwidth and keep access times to the repository to a minimum.

Of course, one might think it makes no sense to create version number folders when using Git. In fact, however, Git isn’t actually required anywhere, and there’s a good reason for that. And that lies in the fact that there can be more than one package repository. We are aiming for the democratisation or federalisation of various package repositories. Some will be private or in-house (which is perfectly legitimate), others will have a thematic focus, and then there will be repositories containing alternative or better implementations of the ‘official’ repository. Each user will be able to decide for themselves which repositories they wish to use. To do this, they simply need to copy the relevant repository configuration (which the respective repositories should provide) into the ‘/remotes’ folder.

Although we do not require Git for a package repository, we do require that it provides a REST API such as GitHub or GitLab. At the time of writing, Codeberg unfortunately does not yet do this. Bitbucket might work, but issues could arise.