The last couple of days I’ve been taking another look at getting modules for the Raku programming language into Gentoo’s Portage tree. Making new packages available in Gentoo is incredibly easy with their overlay system.
The more complex part was Raku’s side of things. While most languages just have
a certain directory to drop files in, Raku should use a
CompUnit::Repository object, which exposes the
.install method. This is
obviously slower than just copying the files around, but there are merits to
this method. For one, it allows installation of the same module with different
versions, or from different authors. It also handles all the Unicode complexity
There is a
which would allow me to just copy over files to the right directory, however, I
quite like the ability to have multiple versions of the same module installed.
This is actually something Portage is designed with, too!
After an email to the Raku users mailing list, I got some pointers over IRC. I let these sink in for a couple days, considering how to approach the problem properly. Then, one night, a solution came to mind, and I set out to test it.
It actually worked. And a similar method should be usable for other distributions too, such as Debian, OpenSUSE or Archlinux, to create packages out of Raku modules. This should greatly improve the ability to ship Raku programs to end-users, without requiring them to learn how Raku’s ecosystem is modeled, or which module manager it uses.
The most important part of this approach is the
program, which is part of
dev-lang/raku::raku-overlay. It accepts a path to
the module to install. It does not depend on any one module manager, so it can
be used to bootstrap a user-friendly module manager (such as
zef) for the user.
It’s a fairly straightforward program. It checks for
$D to be set in the
environment, which is a variable Portage sets as the destination directory to
install new files in. This directory gets merged into the root filesystem to
finalize installation of any package.
$D is set, I append the path used by Raku in Gentoo to it, followed by a
repo name. Next I create a
CompUnit::Repository using this path. This is a
trick to get the files to appear in the right directory for Portage, to
eventually merge them in the system-wide
site module repo used by Raku.
Additionally, I can use the
install method to handle
all the Raku specific parts that I don’t want to handle myself.
This leaves one last issue. By creating this new repo, I also get a couple
files that already exist in the system wide
site repo. Portage will complain
about possible file collisions and refuse to install the package if these
remain. However, this can be solved rather easily by calling
rm to these
And with this, my test module,
IO::Path::XDG, installs cleanly through the
power of Portage, and is usable by all users using the system-wide Raku
To make this work for other distributions, the
should be modified slightly. Most notably, the
$prefix must be altered to
point towards the right directory, so the files will be installed into whatever
directory will end up being packaged. Other than that, the standard means of
packaging can be followed.
For the Gentoo users, this overlay is available at
SourceHut. It currently holds only
dev-raku/io-path-xdg), but you are invited to try it out and report any
issues you may encounter.