rakudobrew | Perl 6 installation manager

moar is a backend. To get a specific Rakduo version, you have to specify it as well:

• To change Perl 6 SDK for the project you go to File -> Project Settings and select project's SDK. Usually it suggests you to choose from not SDKs available from rakudobrew, but one available in your PATH(global, possibly not configured by rakudobrew for this particular shell). So it looks like Perl 6 you have in PATH is not the one that you use from the command line, so the modules are not available.

• Clicking on New -> Perl 6 SDK in Project Settings you can manually specify a path to a Perl 6 bin directory you want to have as an SDK, so for rakudobrew you should specify e.g. /home/$user/.rakudobrew/versions/moar-2019.07/install/bin directory. If it will be the same location you have in which perl6 in your command line where you install modules, it should work.

• Right now Comma does not do things related to package management, though this feature is planned.

Your connection problem is not really anything to do with any P6 related software, or in fact any software you're using. It is, as you say, "just a simple connection failure". And most such failures are transient and "fix themselves". As JJ notes, in such scenarios you just wait and then things start working again.

So by the time you read this it'll probably be working for you again without you having fixed anything. But I'm writing an answer anyway with these sections:

• Consider not using rakudobrew

• Connection problems that "fix themselves"

• Connection problems you investigate or fix yourself

• Getting around single points of failure

The main purpose of rakudobrew is to support installation of many versions of Rakudo simultaneously and the main audience for the tool is folk hacking on the Rakudo compiler, not those merely using it.

If you're just a regular user, not someone developing the Rakudo compiler and/or don't need to have multiple versions of Rakudo, with complete source code, installed simultaneously, then consider just downloading and installing Rakudo files directly, eg. via rakudo.org/files, rather than via rakudobrew.

rakudobrew failed because a git clone ... command failed because the connection with the github.com server timed out.

A server timing out when doing something that usually works using a connection that usually works is likely a transient problem, aka a "please try later" problem.

Transient problems typically "fix themselves" a few seconds, minutes or hours later.

If there's still a problem when you try again, and you want to spend time trying to find out what's going on officially, then look for a status page for that server.

Here are two status pages I know of for github.com:

• https://www.githubstatus.com/

• https://twitter.com/githubstatus?lang=en-gb.

And for unofficial scuttlebutt I suggest reading the twitter feed.

For me, right now, github.com is working fine and the status page says all systems are go.

So it should now be working for you too.

If it's not, then you can wait longer, or investigate. It you want to investigate, start by looking at the status pages above.

If github claims it's working fine then there's presumably a problem with your local internet "on-ramp" (your system or your internet service provider's) or somewhere further afield between your on-ramp and the server you're failing to connect to. (You can only know approximately where the server is based on which region of the world administers the IP address the server is associated with at any given moment.)

The next place to look will be places like the internet traffic report; this indicates traffic jams and the like across the planet. (Ignore the visual display, which is broken on some browsers, and click on the links in the table to drill down.)

If it's all green between you and the region that administers the IP address of the server you're failing to connect to, then the next place to turn would be your system's administrator and/or ISP.

Failing that, then perhaps you can ask a question at a sister stackexchange site like serverfault.com or superuser.com.

Perhaps you were thinking there might be some system redundancy and/or you're interested in that aspect.

P5's ecosystem and its tools are generally mature and limit spofs. This is unlike the ecosystems and tools of most of the other languages out there; so if you've gotten used to the remarkable reliability/availability of CPAN due to its avoidance of spofs, and by extension perlbrew, well, you've been spoiled by P5.

The P6 ecosystem/tool combinations are evolving in the P5 tradition.

For example, the zef package manager automatically connects to CPAN alongside github, and is built to be able to connect to other repos. The ecosystem is partway there to take advantage of this zef capability in that many modules are redundantly hosted on both CPAN and github.

rakudobrew ignores CPAN and assumes use of git repos. It is impressively configurable via its Variables.pm file which includes a %git_repos variable, which could be re-targeted to an alternative git repo site like gitlab. But no one has, to my knowledge, arranged to redundantly copy and update the relevant rakudo files to another git repo site, so this spof-avoidance ability apparently inherent in rakudobrew's code is, afaik, moot for now.

You are missing the $ on the host parameter to connect.

The key observation is that sort doesn't actually return a list:

I just tried to replicate this slightly differently on my REPL, I get no error...

As ikegami says in a comment to your question, you really should use a Buf, which is basically a “string” of bytes.

In Perl 6, the mechanism for loading modules and caching their compilations is pluggable. Rakudo Perl 6 comes with two main mechanisms for this.

One is a file-system based repository, and it's used with things like -Ilib. This resolves modules simply using paths on disk. Whenever a module loaded, it first has to check that the modules sources have not changed in order to re-compile them if so. This is ideal for development, however such checks take time. Furthermore, this doesn't allow for having multiple versions of the same module available and picking the one matching the specification in the use statement. Again, ideal for development, when you just want it to use your latest changes, but less so for installation of modules from the ecosystem.

The other is an installation repository. Here, specific versions of modules are installed and precompiled. It is expected that all interactions with such a repository will be done through the API or tools using the API (for example, zef locate Some::Module). It's assumed that once a specific version of a module has been installed, then it is immutable. Thus, no checks need to be done against source, and it can go straight to loaded the compiled version of the module.

Thus, the installation repository is not intended for direct human consumption. The SHA-1s are primarily an implementation convenience; an alternative scheme could have been used in return for a bit more effort (and may well be used in the future). However, the SHA-1s do also create the appearance of something that wasn't intended for direct manipulation - which is indeed the case: editing a source file in there will have no effect in the immediate, and probably confusing effects next time the compiler is upgraded to a new version.