"Version 2021.09 is broken"

[JJ]

This happens in alpine:

Rakudo has been built and installed.
Version moar-2021.09 is broken. Refusing to switch to it.

This when issuing rakubrew global moar-2021.09. It had not happened before. It's using the latest Alpine, together with fresh versions of everything in this Dockerfile: https://github.com/JJ/alpine-raku

[JJ]

I think this is related to this commit fdb768a9335771869f8b823da63fe72774bd1531 . It seems to fail when you try registering it into a new location.

[lizmat]

FWIW, I've had some really strange issues with 2021.09 as well, but that may have been a result of switching between master and new-disp branches as well.

[JJ]

I think it happens when you configure the build so that the prefix is something else, as we do in the Dockerfile. I'm going to check it locally; it's probably unrelated to Alpine at all.

[JJ]

Building with this command line:

rakubrew build moar master --configure-opts='--prefix=/tmp/raku'

Yields yet another error:

Invalid version found: moar-master at /home/jmerelo/.rakubrew/bin/rakubrew line 2773.

While Raku has been built correctly without an error:

➜  ~ /tmp/raku/bin/raku --version
Welcome to 𝐑𝐚𝐤𝐮𝐝𝐨™ v2021.09-3-gb2bfa4dec5.
Implementing the 𝐑𝐚𝐤𝐮™ programming language v6.d.
Built on MoarVM version 2021.09.

[JJ]

(that was version 16, BTW)

[JJ]

OK, this works in the last version, no error. So it's likely that's not the issue here.

[JJ]

OK, last version, Alpine, this:

rakubrew build moar 2021.09 --configure-opts='--prefix=/root/.raku'

Yields the same error as above. So it's build, not register or global, and it happens when you use a different prefix.

[raydiak]

On Arch, I'm also having problems with the latest version. I don't recall doing anything special with different branches or extra command line parameters, just basic usage the same as every month's release. I did rakubrew self-upgrade, and then rakubrew build moar-2021.09. It appeared to build, but I can't switch to it. rakubrew switch moar-2021.09 silently fails. I get the Switching to moar-2021.09 message, but both raku -v and which raku indicate that it's still on 2021.08. To the best of my recollection, I haven't changed anything relevant about my system and have successfully used this same OS and rakubrew installation for several releases until now.

[patrickbkr]

Hi. Thanks for the report and tests! The detection of broken installations entered rakubrew only in the latest version. So there is obviously something broken there. I'll have a look.

[patrickbkr]

@raydiak Thanks for the report. I actually did manage to break version switching in env mode. I have fixed that now and released version 21 with the fix. Can you verify it is fixed for you?

[patrickbkr]

@JJ Hm. I had a look at that Dockerfile. There rakubrew is used to build a rakudo in a custom location. That results in a version that is broken from rakubrews perspective (This has been true in previous versions as well). Subsequently that (broken) version is deleted and the installation in a separate dir is then registered. The thing that has now changed, is that rakubrew (rightfully so) complains about the broken build. I think the Dockerfile would start to work again when changing line 24 from

&& rakubrew build moar $VER --configure-opts='--prefix=/home/raku/.raku' \

to

&& rakubrew build moar $VER --configure-opts='--prefix=/home/raku/.raku' || true \

In general I consider using rakubrew in such a way as relying on implementation details. Nevertheless this change in behaviour broke your Dockerfile. As I don't see a way to have both backwards compatibility and a sane error reporting, the question is which of the two we value more. I lean towards having sane error reporting and changing the Dockerfile.

Would you agree?

[patrickbkr]

@lizmat I think you probably also observed the "switch silently doesn't work in env mode" bug which is fixed in version 21. So I hope updating should fix the misbehaviour you observed.

[lizmat]

I'm not a rakubrew user. The breakage I saw was maybe caused by the same underlying change in Rakudo?

[patrickbkr]

@lizmat OK. Understood.

[raydiak]

@patrickbkr++ v21 works correctly for me, it switched to 2021.09 with no problems. Thanks for the speedy fix!

[JJ]

@JJ Hm. I had a look at that Dockerfile. There rakubrew is used to build a rakudo in a custom location. That results in a version that is broken from rakubrews perspective (This has been true in previous versions as well). Subsequently that (broken) version is deleted and the installation in a separate dir is then registered. The thing that has now changed, is that rakubrew (rightfully so) complains about the broken build. I think the Dockerfile would start to work again when changing line 24 from

&& rakubrew build moar $VER --configure-opts='--prefix=/home/raku/.raku' \

to

&& rakubrew build moar $VER --configure-opts='--prefix=/home/raku/.raku' || true \

In general I consider using rakubrew in such a way as relying on implementation details. Nevertheless this change in behaviour broke your Dockerfile. As I don't see a way to have both backwards compatibility and a sane error reporting, the question is which of the two we value more. I lean towards having sane error reporting and changing the Dockerfile.

Well, it would really have preferred that backward compatibility was not broken; that is why I've created the issue #42. A lot of infraestructure is going to rely on rakubrew, and breaking them does not contribute to customer experience.

The workaround you mention simply will not do. There might be other things broken, and passing through is going to only hide those problems. If you are no longer going to offer the option of building in an alternative place, I would have really appreciated if you had designed some deprecation cycle so that people get used to it and adapt their tools, and eventually error when that option is invoked.

[patrickbkr]

@JJ Do you have an idea how we could do both, not break backward compatibility and at the same time also not hide the fact that the build went wrong?

A bit unrelated to this ticket, is there any reason you are relying on rakubrew to do the build instead of doing the build directly? It would make the script more reliable by having one dependency less. I didn't test the following, but that's how it should work in principle. (The LOC actually stayed the same.)

curl -o rakudo.tgz https://rakudo.org/dl/rakudo/rakudo-$VER.tar.gz \
&& tar -xzf rakudo.tgz \
&& pushd rakudo-$VER \
&& perl Configure.pl --backends=moar --gen-moar --make-install --prefix=/home/raku/.raku \
&& git clone https://github.com/ugexe/zef.git \
&& cd zef \
&& raku -I. bin/zef install . \
&& zef install Linenoise App::Prove6 \
&& popd \
&& rm -rf .profile rakudo.tgz rakudo-$VER

[patrickbkr]

I think it makes sense to focus Rakubrew as it is now to be a tool for direct use by humans and not to be used when automating workflows. I have now added a respective section to the rakubrew.org website. Given this more explicit focus it seems sensible to close this issue.