raku at the Monterey Docks

Title: Building on fabled Cannery Row, Monterey, California – Wikimedia Commons

The Problem…

There I was just being tidy and getting the latest macOS release (Monterey) for my pricey new M1 laptop – expecting the usual seamless upgrade. Then bang! <<Homebrew is not supported on ARM processors>>. This is NOT (just) a raku thing. In my case, the proximate cause seems to be lack of support for M1 for ruby <<No Homebrew ruby 2.6.8 available for arm64 processors!>>. My swag is that Monterey is stepping down rosetta mollycoddling vs BigSur and wo-betide anyone who wants to run non native via a terminal. Well what did you expect with an architecture change.


This may well be the way I have set up my setup on my machine – you made never experience any of this. I would also mention that I am not a core dev and I am a bit out on a limb building from source – I can do it fine if it works… and all of what follows has a good measure of uninstall/reinstall which can leave a bit of a mess.

… gets Worse

This made me mad. So I factory reset my machine, installed Xcode (this is safer than xcode-select --install), rosetta2 (leaving the Terminal.app “open with rosetta 2” option unchecked, since I want to go faster) and Docker Desktop and tried several things on a clean macOS machine. My failings included:

  • brew install rakudo (and rakudo-star)
  • rakubrew download from available 2021.04 (and 2021.09)
  • install prebuilt macOS arm64 image
  • rakubrew build from source 2021.04 (locale error) & 2021.07 (make test error)

I would love it if any of these methods would work for me … and encourage you to comment if you have fared better / know the incantation that I missed!

And this is not to cast aspersions on the excellent raku toolchain – I am sure if I wait a couple of months and get off the bleeding edge, then all will be fixed. In the meantime, I realised that macOS is a bit of a sideshow for raku which is developed on ubuntu.

Back to the Drawing Board (aka Docker Desktop)

Since I have been wondering about the best way to test against multiple raku versions and to maintain a tight system configuration around raku to support Python::Inline and Perl5::Inline, I choose to see the silver lining in my cloud and go for Docker. So I installed the newly GA Docker Desktop for Apple Silicon.

This method is very forgiving – Docker Desktop will warn, then run AMD64 (on rosetta) using platform detection if need be, regardless of the Terminal.app settings.

Now to work out the workload … well I have been working on the various Physics::Measure modules using jnthn’s excellent CommaCP for a while, so I was very keen to get testing working for these.

I also have been using JJ’s excellent alpine-raku and raku-alpine-test on the voracious TravisCI service so it seemed natural to go with that. Here are the steps that worked for me:

Path 1: Basic Module Test

Starting by running a module test from the Docker command line (raku-test is a specialised derivative, with a Dockerfile that starts FROM alpine-raku:latest):

docker run -t -v /path/to/module-dir:/test jjmerelo/raku-test

This will pull the image from the Docker repo and run it… you just specify the local path to your module.

Nice! I am alive once more with local test harness and the ability to apply multiple raku versions – BUT this is on AMD64 (aka Intel) … so all that money spent on M1 is wasted!

Path 2: Run any raku script

Stepping this up, I can use alpine-raku to run scripts directly (following the documentation):

docker run –rm -t jjmerelo/alpine-raku -e “mkdir ‘raku-app’; say ‘raku-app’.IO.absolute;”
docker run -t -v pwd:/home/raku/raku-app jjmerelo/alpine-raku /home/raku/raku-app/pell.p 6

Path 3: Run Math::Polygons via the existing Dockerfile

Since I already had made a Dockerfile to run this module in interactive mode in a Jupiter notebook, I gave it a try …

git clone https://github.com/p6steve/raku-Math-Polygons
cd raku-Math-Polygons
docker build -t rmp .

This takes a while (20mins+) as it does on Jupyter binder since it is building a full raku ubuntu image from scratch – when running you can access via the browser button on Docker Desktop.

Putting Docker and Comma together

To wrap this story up, how nice it would be to get Docker and Comma working together … lo and behold, CommaIDE has a plugin just for this…

And Finally!

So, now all is well – Docker Desktop is up and running and I can ring all the changes from the command line:

docker run -it jjmerelo/alpine-raku
docker run -it jjmerelo/alpine-raku:2021.04
docker run -t jjmerelo/alpine-raku -e “say ‘hello þor'”
docker run -it –entrypoint sh -l -c jjmerelo/alpine-raku [container persists eg. zef modules]
docker run -v pwd:/app -it jjmerelo/alpine-raku /app/Tree.p6

BUT – this way I have to install all my module dependencies on every test run … surely there must be a better, faster way… (just wait for the next gripping instalment)

Please do leave any feedback and comments …




  1. ManiacsThriftJewes says:

    I would probably opt for using a Dockerfile that starts with docker.io/jjmerelo/alpine-raku:2021.04, then has commands to RUN mkdir /app, COPY your meta file, RUN zef install for your dependencies, and then COPY the rest of your files. Maybe also set the CMD and/or ENTRYPOINT
    Rebuild the app for each new test run, and it should only reinstall dependencies if you change your meta file (or force a rebuild).
    Also avoids using the notoriously slow bind mount translator for the VM on MacOS.

    Or alternatively mount a volume for /home/raku

    Liked by 1 person

    1. p6steve says:

      great point – I’m planning a part 2 that will detail this!! 🙂

      Liked by 1 person

Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s