How to use a wrapper script for a Raku CLI

So I'm guessing Zef adds it?

CompUnit::Repository::Installation adds it

Why is it there? One reason is because some wrapper needs to manage bin scripts the same name that would otherwise clash if they were in the same directory.

Is there some way to use the run-script method shown above without Zef?

run-script is for CompUnit::Repository::Installation only -- if you aren't installing a module then run-script won't be of interest

Assuming I do need to have my users download two files, where should I have them install the files?

Well the recommended/idiomatic way would be to use the core raku functionality to install things (i.e. use zef). Otherwise where you should put some code is either a) not going to matter or b) going to be mostly dependendant on your environment, what is idiomatic for your os, etc.

Does it need to be copied into their Raku module search path (and, if so, what command would show them what that path is)

echo $RAKULIB should suffice for showing the module search path in most cases, especially if they aren't interested in where the installation paths are. And as such you can instruct users to set e.g. RAKULIB=$FROB_LIB_DIR to point wherever your library is if you want them to be able to run your script without manually specifying it via raku -I../ frobnicate (so they don't copy the code anywhere special, they just point to wherever they e.g. clone your repo). Ditto for working with $PATH.

Or can I modify the frobnicate wrapper in some way (maybe by changing raku to raku -Ilib or something like that?) in a way that would let them install both to directory on their PATH?

I would advise against installing things based on some value in $PATH. Instruct users to set $PATH, don't install things to $PATH.

Technically you could add use lib '../' to your script, but using use lib in a script that you also want users to install normally is less than ideal since its adding an unused, potentially hijackable module search path when being run from such an install.

If you want your code to precompile then I suggest putting it in a module, and instructing your users that, if they don't intent to install it, to invoke it via raku -I../ ./frobnicate on a per-use basis or something like export RAKULIB="$FROB_LIB_DIR,$RAKULIB" followed by ./frobnicate for something more permanent. Alternatively if someone evenetually implements precompilation of scripts then you could just use the single file approach.

Some comments on this topic.

1. It is optimal, I think, to use zef because zef will also load dependencies. It is already unusual to be able to write a Raku program without using other modules and I would expect this to become even more unusual as more Raku modules get developed.

2. I forget which modules I have installed on my system, and included in a program. By specifying everything in META6.json, then running zef test ., the chance of ensuring someone else can download the module is improved. Actually, I have found the best way to ensure this is to create a docker file and try to install a new module in a docker image/container - but that's another topic.

3. I have found (for Linux, and I cannot comment about Windows) that if I:

   • write an executable in Raku (see below), lets call it MyWonder,
   • place it in the <distribution>/bin folder,
   • give it +x permission(s), and
   • specify it in the distribution's root META6.json file
   • (publish the distribution)

   then when zef installs the distribution, MyWonder will work on the command line (assuming that zef itself works on the command line, implying that PATH contains the directory to zef).

4. The optimal (for me) way of invoking a program that is meant to be used on command line, or invoked by a desktop, is:

   • put the following into the MyWonder file (no need for extension)

   use v6.d;
   use MyWonderLife;
   

   • put all of the functionality into MyWonderLife.rakumod
   • make sure there is at least one sub MAIN in MyWonderLife.rakumod
   • specify MyWonderLife in the META6.json file (which allows a lot of flexibility about which directory you can put the actual MyWonderLife.rakummod file under; it doesn't have to be lib/)
   • create a simple test t/basic.rakutest for the distribution, with just the test use-ok 'MyWonderLife;

   This recipe means that all the functionality is precompiled by zef, so that when the executable is called by the user, there is a much quicker response. The slowest part when using Raku is compiling a program. By installing with zef, this is done once during installation. Programs in all languages are slow to install, so a Raku program does not cause a user to wonder what is happening at the moment it is being used.

   Secondly, it is possible to use several multi sub MAIN to handle a variety of calling situations, and to use the range of command line options that can now be handled. Whilst this is obviously possible in any script, putting them all in a .rakumod file seems (to me) to be more natural.

   I've found that extensive tests are a pain to watch when modules are being installed, so I have begun to move most of the development and maintenance testing to xt/ and only have simple installation tests in t/.

   Finally, with this recipe (and assuming you have given the distribution the name MyWonderLife in the META6.json file, the installation instructions for MyWonder, assuming it is possible to call the program with no arguments are simply:

   Use zef to install MyWonderLife, eg.,

   zef install MyWonderLife
   

   and use it on a Command Line as follows:

   MyWonder