It's been over a month since I first came across -- finally -- a clean way to present anyone who runs Linux with a simple, clean, non-"virtualenv" installation of raku: rakudo-pkg to the rescue!

rakudo-pkg vs a virtual environment like rakubrew

There was always a bit of an icky feeling related to relying on rakubrew(and rakudobrew before it) for requiring inquiring minds to first ignore what their system offered them through official channels and instead install some in order to have access to anything remotely resembling an up-to-date version of the raku runtime (or perl6 before it).

Unfortunately, in the case of most official package repositories, the latest officially available versions were often ancient¹. It's heartening to note, however, that this situation has improved significantly since the official debut of the "finished" language as 6.c half a decade ago. Still the official repositories lag far behind the improvements that are made, even today.

In my opinion, it is one thing to encounter a virtualenv-style tool after you have hit some limitation with running the system installation of a language. But being exposed to adding a whole new mothball to your home directory and login shell configuration as a requirement to just trying out a language is not the strongest look in terms of an advocacy perspective.

Having a dedicated system path for the tools also fixes issues related to tools that do not inherit environment variables created by executing all of those tweaks stashed in .bash_profile or (in my case) .config/fish/config.fish.

A virtualenv approach is also particularly un-desirable as it is potentially resolvable through guarantees made at the language design layer around Raku's approach to module and language versioning.

Important details about Raku versioning

Raku naturally shows it's previous life as that caterpillar formerly-known-as-Perl-6 most strongly when you encounter its own versioning.

use v6.c is guaranteed to access a historical standard of Raku behavior. use v6.* optimistically says "use *Whatever* version you consider the newest". use v6.d gives you guarantees that the language won't start spitting deprecation warnings pertaining to later versions, starting with v6.e, while also doing everything exactly as v6.d intended even on a newer release.

Free project ideas below

It would be interesting to stress test the implicit and explicit language level guarantees of Raku by dog-fooding an old fashioned "smoke test" on our own with regard to the claims made in the designs of the language versioning and the module repositories and authorities concepts. A sort of "distributed DarkPAN simulator" for Raku in the 2020s.

The CompUnit repositories and module authorities are ideas that intend to make backward compatibility easier in a world where sometimes you want to run a locally patched variant of a public module that is otherwise identical (or even wildly incompatible) and other times you want to be able to run two different versions of a library side-by-side -- at the same time.

A/A testing of library upgrades at vanguard for a bit before rolling out to the fleet, anyone? (That's a different, likely far more profitable, library idea for you, my intrepid reader).

Ok, but where???

Check out the blog post announcement of the new GitHub Task based release flow and the latest iteration of the rakudo-pkg project.

1. It was a long road to the first official release, so it is not at all fair to blame distribution maintenance teams to not bother with ensuring that the bleeding edge version of a still-baking language was--or is--easily accessible. Things have gotten better since the release of 6.c.↩