rakurakudo-star

What is the proper way to load Raku modules using rakudo-star?

I have the following project

$ tree
.
├── lib
│   └── MyModule.raku
└── main.raku

$ cat lib/MyModule.raku
use v6;
unit module MyModule;
sub hello { say 'hello' }

$ cat lib/main.raku
use v6;
use MyModule;
MyModule.hello();

I would like to run main.raku using the latest rakudo-star image. However the following occurs

$ docker run -i --rm -u $(id -u) \
--workdir /work \
--volume  $PWD:/work \
--entrypoint bash \
rakudo-star perl6 -I ./lib main.raku
===SORRY!===
Could not find MyModule at line 3 in:
    file#/work/lib
    inst#/.perl6
    inst#/usr/share/perl6/site
    inst#/usr/share/perl6/vendor
    inst#/usr/share/perl6
    ap#
    nqp#
    perl5#

I have also tried inserting use lib '/work/lib' before use MyModule in main.raku with the same result.

Solution

  • There are several problems.

    1. Modules don't end with .raku. They end with .rakumod or .pm6 (for now).
      (Technically after you install, it doesn't actually matter what the extension is as long as you have it properly declared in META6.json.)

    2. Subroutines are lexically scoped by default (my), and are also not exported by default.
      So there is no way to access hello() outside of the module it is defined in.

    3. Modules don't have methods, so you can't call hello as a method.
      Even if they did have methods they wouldn't start with the sub keyword.

    You can globally scope the subroutine with our:

    lib/MyModule.rakumod

    use v6.d;
unit module MyModule;

our sub hello () { say 'hello' }
#^
# \
#  globally scoped

    main.raku

    use v6.d;
# use lib './lib';
use module MyModule;

MyModule::hello();
#       ^^
#        \
#         namespace delimiter

    You could export it instead:

    lib/MyModule.rakumod

    use v6.d;
unit MyModule;

#             mark for export
#            v-------v
sub hello () is export {
    say 'hello'
}

    main.raku

    use v6.d;
# use lib './lib';
use MyModule;

hello();

    In addition to is export, there are other more fine grained ways to export.

    I would recommend that if you are going to export, that you also make it global with our. That way if someone uses your module, but doesn't want to import your subs; they still have access to them.