Rakudist.raku.org Beta Testing Starts

Thanks to Raku community’s members @AlexDaniel and @rba who supported the idea of bringing RakuDist to community infrastructure, so long story short:

https://rakudist.raku.org is available!

Check the service out to test your Raku distribution against various versions of Rakudo. Ubuntu and Debian OS are available.

The service is in beta stage, feel free to post bugs or suggestions to RakuDist GitHub project.

Here is also API docs if you prefer programmatic interface instead of launching tests through a web form.

Thanks for reading.


RakuDist Update. Long Queue Short.


RakuDist is a service that enables Raku module authors to test theirs distribution across different Rakudo and OS versions.

A lot of things have happened to the project recently.

I am to busy to write all the details, but to make a long story short, there are two important facts.

RakuDist has got a nice web UI, so people could launch builds by using convenient html form, try it now!


In the future I’ll probably find a proper domain name for the service, but so far it’s the link just mentioned.

And secondly, RakuDist is now powered by Sparky backend, which means all the builds are 100% asynchronous queues and hopefully my VM will cope with a load if people start using the service proactively.

That is it. Thank you for reading. I’d appreciate comments as usual from Raku community.





2020.15 An eASTer Surprise

Rakudo Weekly News

Jonathan Worthingtontweeted that they finally found the time and the voice to record the presentation they had planned for the German Perl and Raku Workshop. You can either watch the video and/or look through the slides. It basically touches on these four subjects:

  • Where is Rakudo now with regards to macros
  • Why it’s time to overhaul the Rakudo compiler frontend
  • The design of RakuAST, an AST for mere mortals
  • A tentative time-path with milestones

Yours truly is particularly excited about the concept of RakuAST, which should allow building executable code without having to resort to using EVAL, with all of its security and performance implications. Exciting times!

Reintroducing ArrayHash

Sterling Hanenkamp redesigned / refactored their ArrayHash module, which originally predated the Great List Refactor, and wrote a very interesting blog post about it.

So you have an idea for a project…

Then this round of Perl Foundation…

View original post 942 more words

RakuDist Update. Web UI

Hi this is a small update of RakuDist – an API to test Raku modules.
Nothing major has happened since my last update. However I am exited to announce a web UI to browse recent tests:


To run tests one need to use an HTTP API.

For example to run test against Kind module and ​​​Rakudo commit version 1a10b63a :

curl -d os=alpine \
-d rakudo_version=1a10b63a28e2de5d826a2336875fcda04e4f6c0b \

One can also test against GitHub/GitLab projects, the same test for a GitHub source code would be:

curl -d os=alpine \
-d project Kaiepi/p6-Kind \
-d rakudo_version=1a10b63a28e2de5d826a2336875fcda04e4f6c0b \

All the tests get browsed through a web UI http://repo.westus.cloudapp.azure.com/rakudist

Current OS supported:

* CentOS
* Debian
* Alpine

Rakudo version could be set:

* as a full commit SHA
* or a default version  2020.02.1  could be chosen

Thank you for reading. As always your comments and feedback are welcome.


Testing Command Line Applications using Tomty and RakuDist

So you have a command line application written on Raku and shipped as a Raku module to an end user. You’re quite happy with unit tests get run as a part of  zef install process.

But say, you need something  extra. For example, some post deployment tests that check your tool runs properly on a small set of scenarios. Here we enter  Tomty – Raku testing framework.

With a very simple code it’s possuble to add extra tests and run those tests under RakuDist – API to test Raku modules.

Zero Install

As tests are going to  be  run by RakuDist API, no dependencies to install is required, RakuDist will take care about execution environment, you just need to create tests and push them to Git as a part of .rakudist folder,  as this:

mkdir .rakudist/.tomty && git add .rakudist && git commit -a -m "my tests"

You still may want to install Tomty to debug/run tests locally :

zef install Tomty

Hello world example

Every test consists of two parts – high level wrapper written on Raku and underlying script written on a language of your choice (any Sparrow compatible language*)

* Perl,Bash,Ruby,Powershell,Python,Raku for the moment

Raku wrapper:

​nano .rakudist/.tomty/test-01.pl6

task-run "tasks/some-task";

Test script:

nano .rakudist/tasks/some-task/task.bash

echo "Hello World"

In this example it’s just a simple echo command, of course for real modules you would have a command line of  an application.

Let’s give it a run:

cd .rakudist/ && tomty --all --verbose

[test-01] ....... 
23:12:04 02/21/2020 [repository] index updated from file:///home/melezhik/repo/api/v1/index
23:12:04 02/21/2020 [tasks/some-task] Hello World
(=: / [1] tests in 1 sec / (1) tests passed

At the very basic level Tomty just runs an external script and checks it exit code.

Task checks

Tomty allows to create so called task checks – Raku regexp based DSL to check a script output, in simplest form it could be just a plain string check:

nano .rakudist/some-task/task.check

Hello World

Now, Tomty not only checks if a script exits with zero exit code but also verifies it’s output:

tomty --all --verbose

[test-01] ....... 
23:16:16 02/21/2020 [repository] index updated from file:///home/melezhik/repo/api/v1/index
23:16:16 02/21/2020 [tasks/some-task] Hello World
[task check] stdout match <Hello World> True
(=: / [1] tests in 1 sec / (1) tests passed

Script parameters

Raku wrappers not just call scripts,  they might pass some parameters:

task-run "tasks/some-task", %(  
  name => Raku 

With a simple modification a script could handle passed parameters:


name=$(config name)
echo "Hello {$name}"

You can even handle parameters within task checks:


generator: <<CODE
  name=$(config name)
  echo "hello ${name}"

To know more about how to write Sparrow scenarios follow documentation.

More tests

Eventually more tests are added by creating new Raku wrappers inside .rakudist/.tomty directory and respected scripts inside .rakudist/tasks folder:


The whole test suite as usually is executed by tomty --all command


We’ve ended up with a simple file structure to test command line application distributed as a Raku module:

├── tasks
│   └── some-task
│       ├── task.bash
│       └── task.check
└── .tomty
    └── test-01.pl6
3 directories, 3 files

If you want to see more examples, take a look at my pull request for App::Mi6 application.

I would love to hear a feedback and ideas on possible usage of the toolset.

Thank you for reading

RakuDist Update – Travis Integration and Post Deployment Tests

Hi! I continue to make updates on RakuDist project aimed to automate a process of testing Raku modules.

Here is a couple of interesting features I have added recently.

Enter Travis CI integration and post deployemt checks.

Travis CI

If one need to run RakuDist through Travis CI it’s as simple as that:

language: minimal

 - curl http://repo.westus.cloudapp.azure.com/rakudist/api/run/$os/$author/$module -s | bash


$os – tested OS name, for example `debian`
$author – github(*) login
$module – module name

(*) – RakuDist supports GitLab projects as well I just need to write a proper helper for that.

Post deployment scenarios

Quite often Raku modules distributions include scripts that are part of an installation process.

RakuDist allows to test such a scripts at post deployment phase:

nano smokefile:

bash 'your-script', %(
  user => config()<user>,
  expect_stdout => 'this string should be in a script output'


You could see more sophisticated and interesting examples here.

I would like to hear from Raku modules authors if this feature is useful.

That’s all for @today, stay tuned!

RakuDist Update – Raku Modules Custom Installation.

Custom installation

I continue to play with RakuDist API searching for useful cases for Raku modules authors.

With RakuDist/Sparrow6 one can easily customize an installation and testing process.

Why would people need it? For various reasons:

  • A module requires external libraries not satisfied by zef install
  • A module requires external services – e.g. databases servers running and so on
  • A module requires extra configuration files which are hard to deliver by standard distribution means

To address all the needs RakuDist provides a handy functionality called custom scenarios.

Custom scenarios

Just drop a .rakudist folder into your Raku module source code, with some custom scenario inside:


Say, you need an installation of an sqlite library as your module relies on it:

cat .rakudist/sparrowfile

package-install "sqlite-dev";

That is it. Now commit and push changes to git:

git add .rakudist && git commit -m "my custom scenario" && git push

Now you may test your distribution hosted on GitHub through API:

POST os=$os project=$author/$project /rakudist/api/run/:github

For example to test Teddy::Bear module:

curl \
-d os=alpine \
-d project=melezhik/rakudist-teddy-bear \

Once you’ve packed .rakudist/ folder in a CPAN distribution, you can test it as well:

POST os=$os  /rakudist/api/run/$module

For example:

curl \
-d os=alpine \


More examples

1. Custom tasks/scripts

Sparrow6 DSL allows to write scenarios of any complexity and if it still is not enough one could add custom tasks written on many languages to extend the functionality:

cat .rakudist/tasks/hello-world/task.bash

# your Bash code here

And then inside Sparrow scenario just:

cat .rakudist/sparrowfile

task-run "tasks/hello-world";

2. Raku dependencies not declared in META6.json file

Sometimes developers might be not ready to include dependencies in meta6 file for various reasons. For example, when a dependent module itself is not released yet, or if the dependency fails and needs to be installed as --/test exclusively, here is depends.raku for the rescue:

Just create .rakudist/depends.raku file declaring Raku dependencies in simple format:

OpenSSL notest

Here we want to install OpenSSLwithout unit tests and Math::Libgsl::Constants from GitHub sources.

3. Existing modules examples

I’ve recently made a PR to Math::Libgsl::Permutation and to PR to Archive::Libarchive::Raw to support RakuDist test against various OS systems. These modules rely on external libraries gsl and libarchive and so need to be tested against platforms. RakuDist comes very handy in such case.


RakuDist keeps growing, but is still in quite experimental phase, to see the project potential, I would like to have a feedback from Raku modules authors. Thanks.

RakuDist Update. Rakudo Versions Support.

I continue to post updates on RakuDist project aiming to help Raku modules authors to test their distributions on different environments.

Here is very quick ( I lack of time due to my main $work ) but exciting update. Now RakuDist supports  various Rakudo versions.

Long story short

Yes, you can now test your shiny Raku  module install against arbitrary Rakudo version. Now RakuDist expose simple ( don’t blame me if the server will blow under a load 😉 ) yet handy API to test distribution online:

curl -d os=debian -d rakudo_version=SHA $api_url/rakudist/api/run/$module

For example to test Tomty module against rakudo version 40b13322c503808235d9fec782d3767eb8edb899 on Debian say this:

curl -d os=debian \
-d rakudo_version=40b13322c503808235d9fec782d3767eb8edb899 \


Low level API

If for some reasons you don’t want to use public API, you can run RakuDist test scenarios on on-premise infrastructure. All you need is a docker container!

Following a simple workflow:

Install Sparrowdo

zef install --/test Sparrowdo

Pull docker images

docker pull debian

Run container

docker run -d -t --rm --name debian-rakudist debian

Write test

Test scenarios are written on Sparrow6 DSL

cat sparrowfile
zef "https://github.com/melezhik/sparrow6-rakudo-install.git", %( 
  force => True 

user "test123";

my $path = module-run 'Rakudo::Install', %(
  user => 'test123',
  rakudo-version => '40b13322c503808235d9fec782d3767eb8edb899'

# Now you can use installed Rakudo

bash "perl6 --version", %(
  envvars => %( PATH => "{%*ENV<PATH>}:{$path}" ),
  user => "test123",
  debug => True

bash "zef install --/test Kind --verbose", %(
  description => "install Kind",
  user => "test123",
  envvars => %( PATH => "{%*ENV<PATH>}:{$path}" ),


Run test

sparrowdo --bootstrap \
--no_sudo --docker=debian-rakudist \


Read more on https://github.com/melezhik/RakuDist


RakuDist update

One week ago I started a discussion in Raku community on testing Raku modules suggesting Sparrow as a solution. While the discussion has been being held and various opinions have been being given, I’d like to share my experience and indeed some good results I’ve had with applying Sparrow tool to the task of testing Raku modules.

First results

* It reveals bugs – drforr/raku-OLE-Storage_Lite/issues/1 , FCO/Red/issues/421 , titsuki/raku-Chart-Gnuplot/issues/40 , HomoGlypher/issues/2

* It’s flexible enough to create even complicated tests involving databases and services, see FCO/Red/issues/421

* It’s dead simple.  Taking me around 1-2 minutes to write a test for an average module. See the list of examples

* It’s light. With Alpine OS image weighted 5MB and very small Sparrow6 dependency tree, the overall test of average module would take no more 2-3 minutes. If we run on already bootstrapped instance – it’s even a seconds!

* It’s has clear and understandable syntax. Sparrow6 DSL is dead simple and easy to read and write, just see a following example

Let’s get started

The main workflow is dead easy. Spin up a docker instance, install Sparrowdo, drop a simple scenario and give it a run! Boom, within a couple of minutes you’ll get your report nice and readable. No need to wait in queue in Travis, it’s cheap, it’s easy and it’s yours!

Spin a docker instance.

Choose an alpine OS image, 5 MB. You pull it and run it with literally seconds!

docker pull alpine
docker run -d -t --rm --name alpine-rakudist alpine


Bootstrap docker instance

Install Sparrowdo – a thin client to run Sparrow6 tasks on docker instance. It’s really light, just a few Raku modules as dependencies. Then bootstrap your docker instance with Rakudo and Sparrow6 environment, the last one is also extremely light and it won’t take more then a couple of minutes for the whole process and should be done only once.

zef install --/test Sparrowdo
sparrowdo --bootstrap --no_sudo --docker=alpine-rakudist


Create your test

Sparrow6 DSL has all you need. Nice wrappers around zef installer, user management to create users if you need to test users installations and git-scm wrapper to fetch a module source code from Git repositories.

The simplest scenario would be something like that:

$ cat sparrowfile:

my $user = config()<user>;

my $directory = "/data/test/{$user}";

my $scm = config()<scm>;

user $user;

directory $directory, %( 
  owner => $user,
  group => $user


git-scm $scm, %( 
  to => $directory, 
  user => $user,

if os() eq 'alpine' {

  # this is needed for alpine rakudo installation
  unless "/bin/zef".IO ~~ :e {
    copy "/opt/rakudo-pkg/share/perl6/core/bin/zef", "/bin/zef"

  # this is needed for alpine rakudo installation
  unless "/bin/perl6".IO ~~ :e {
    copy "/opt/rakudo-pkg/bin/perl6", "/bin/perl6"


zef $directory, %( 
  force => False,
  depsonly => True, 
  user => $user,
  description => "Install module dependencies"

bash "cd {$directory} && zef test .", %(
  description => "zef test",
  user => $user


The scenario takes some parameters from config.pl6 , e.g. source code repository url and user name to run tests under:

  user => "kind",
  scm =>  "https://github.com/Kaiepi/p6-Kind.git"


Users installations allows to reuse the same docker instance to test various modules. Because dependencies get installed under user’s account and never clash with other modules. Another option would be – relaunch a new docker instance for every test and start from the scratch but this will add time for initialization phase.

Run scenario

I promised it’d be easy, so just launch our  new shiny test on docker alpine instance:

sparrowdo --no_sudo --docker=alpine-rakudist --repo=http://repo.westus.cloudapp.azure.com

And here the report:

16:50:02 01/09/2020 [repository] index updated from http://repo.westus.cloudapp.azure.com/api/v1/index
16:50:07 01/09/2020 [create user kind] uid=1006(kind) gid=1006(kind) groups=1006(kind)
16:50:07 01/09/2020 [create user kind] user kind created
[task check] stdout match <created> True
16:50:11 01/09/2020 [create directory /data/test/kind] directory path: /data/test/kind
16:50:11 01/09/2020 [create directory /data/test/kind] directory owner: <kind>
16:50:11 01/09/2020 [create directory /data/test/kind] directory group: <kind>
16:50:11 01/09/2020 [create directory /data/test/kind] directory access rights: drwxr-xr-x
[task check] stdout match <owner: <kind>> True
[task check] stdout match <group: <kind>> True
16:50:15 01/09/2020 [bash: git checkout https://github.com/Kaiepi/p6-Kind.git] /data/test/kind
16:50:15 01/09/2020 [bash: git checkout https://github.com/Kaiepi/p6-Kind.git] stderr: Cloning into '.'...
16:50:17 01/09/2020 [bash: last commit] commit c08acf1e4a52491a3b09e19e129efc3092cef745
16:50:17 01/09/2020 [bash: last commit] Author: Ben Davies <kaiepi@outlook.com>
16:50:17 01/09/2020 [bash: last commit] Date:   Tue Dec 24 16:28:29 2019 -0400
16:50:17 01/09/2020 [bash: last commit]
16:50:17 01/09/2020 [bash: last commit]     Release v0.1.0
16:50:17 01/09/2020 [bash: last commit]
16:50:17 01/09/2020 [bash: last commit] M       CHANGELOG
16:50:17 01/09/2020 [bash: last commit] M       META6.json
16:50:17 01/09/2020 [bash: last commit] M       lib/Kind.pm6
16:50:19 01/09/2020 [bash: cd /data/test/kind && ls -l] total 32
16:50:19 01/09/2020 [bash: cd /data/test/kind && ls -l] -rw-r--r--. 1 kind kind  191 Jan  9 16:50 CHANGELOG
16:50:19 01/09/2020 [bash: cd /data/test/kind && ls -l] -rw-r--r--. 1 kind kind 8902 Jan  9 16:50 LICENSE
16:50:19 01/09/2020 [bash: cd /data/test/kind && ls -l] -rw-r--r--. 1 kind kind  408 Jan  9 16:50 META6.json
16:50:19 01/09/2020 [bash: cd /data/test/kind && ls -l] -rw-r--r--. 1 kind kind 3230 Jan  9 16:50 README.md
16:50:19 01/09/2020 [bash: cd /data/test/kind && ls -l] -rw-r--r--. 1 kind kind 3337 Jan  9 16:50 README.pod6
16:50:19 01/09/2020 [bash: cd /data/test/kind && ls -l] -rw-r--r--. 1 kind kind  114 Jan  9 16:50 dist.ini
16:50:20 01/09/2020 [bash: cd /data/test/kind && ls -l] drwxr-xr-x. 2 kind kind   22 Jan  9 16:50 lib
16:50:20 01/09/2020 [bash: cd /data/test/kind && ls -l] drwxr-xr-x. 2 kind kind   23 Jan  9 16:50 t
16:50:24 01/09/2020 [bash: Install module dependencies] stderr: All candidates are currently installed
16:50:24 01/09/2020 [bash: Install module dependencies] <empty stdout>
16:50:27 01/09/2020 [bash: zef test] ===> Testing: Kind:ver<0.1.0>
16:50:29 01/09/2020 [bash: zef test] [Kind] t/01-kind.t .. ok
16:50:29 01/09/2020 [bash: zef test] [Kind] All tests successful.
16:50:29 01/09/2020 [bash: zef test] [Kind] Files=1, Tests=3,  2 wallclock secs ( 0.02 usr  0.00 sys +  2.68 cusr  0.21 csys =  2.91 CPU)
16:50:29 01/09/2020 [bash: zef test] [Kind] Result: PASS
16:50:29 01/09/2020 [bash: zef test] ===> Testing [OK] for Kind:ver<0.1.0>



Sparrow could be a reasonable alternative to existing CI tools allowing test Raku distributions easy and fast.  Give it a try and say you comments! Follow the RakuDist project for examples of test scenarios and further updates.