zef start or zef run?

[JJ]

Provide a default command and JSON path that allows to start automatically perl6 apps, à la npm start

Context

META6.json is increasingly becoming the package.JSON or cpanfile of perl6. It's useful now to insert dependencies of a particular app of module and install them using zef install --deps-only. zef test is also pretty much standard, as well as zef build. Wouldn't be a big step to add some command to start applications or sun them.

Expected Behavior

zef run|start or zef run|start . would look into the script key of the META6.json file and run it.

Actual Behavior

This is a RFC. Nothing happens now.

Steps to Reproduce

N/A

Your Environment

N/A

[ugexe]

Firsts lets examine how a bin script from a perl6 distribution (such as zef) is installed and invoked

$ git clone https://github.com/ugexe/zef.git
$ cd zef

---

How bin/ scripts are usually determined for a local path

zef$ perl6 -e 'say Distribution::Path.new($*CWD).meta<files>.hash'

{bin/zef => /path/to/zef/bin/zef, resources/config.json => /path/to/zef/resources/config.json, resources/scripts/perl5tar.pl => /path/to/zef/resources/scripts/perl5tar.pl, resources/scripts/win32http.ps1 => /path/to/zef/resources/scripts/win32http.ps1, resources/scripts/win32unzip.ps1 => /path/to/zef/resources/scripts/win32unzip.ps1}

Note above that the files key is shown - this is not a META6.json spec key, and instead of as a CompUnit::Repository::Installable (a role; -not- ::Installation the class). Also note that there is stuff from resources/ mixed in files. In other words: files is a mapping of all non-perl-module files to some name-path. A name-path list in resources as libraries/p5helper might map like resources/libraries/p5helper => /path/to/Inline-Perl5/libp5helper.so, i.e. $value is not always $key.absolute since $key may not even be representable on a given file system.

---

bin/ scripts being installed

# Show where it will be installed to
zef$ perl6 -e 'say $*REPO.repo-chain.first(* ~~ CompUnit::Repository::Installable).perl'

CompUnit::Repository::Installation.new(prefix => "/home/ugexe/.perl6")

# Install
zef$ perl6 -e 'say $*REPO.repo-chain.first(* ~~ CompUnit::Repository::Installable).install(Distribution::Path.new($*CWD)) ?? "ok" !! "not ok"'

ok

---

wrappers installed for each bin/ script
how $ zef actually loads bin/zef

PATH="/home/ugexe/.perl6/bin:$PATH" zef

Zef - Perl6 Module Management

USAGE
...

PATH="/home/ugexe/.perl6/bin:$PATH" zef-m

Zef - Perl6 Module Management

USAGE
...

---

This is one of the parts s22 did not go into a great deal about. Currently an author does not declare bin/ scripts anywhere in META6.json. But as we can see such an implementation would be trivial; create a Distribution that, when its .meta is called, checks some to-be-decided meta field and sets the proper mappings in <files> of its return value. In CompUnit::Repository itself it can be thought of as the API for method files { }, which is intended to be the CompUnit::Repository API looks up a name-path (lib/Foo.pm6, resources/libraries/foo, etc).

A CompUnit::Repository has an API for looking up some relative path (name-path) from a specific distribution. This is notable for something like CompUnit::Repository::Installation because this type of CompUnit::Repository contains muliple distributions, e.g. use Dist1; use Dist2; may be loaded by the same CompUnit::Repository::Installation. However, a CompUnit::Repository::FileSystem (what is used for -I $some-path) instance only ever represents a single distribution. I mention this because sometimes it may seem like there is an unneeded layer of abstraction, but its usually intended to bring consistency to the overall CompUnit::Repository/Distribution interfaces. This is further improved in rakudo/rakudo#1132

# Currently this only works for an installed distribution
zef$ perl6 -e 'CompUnit::RepositoryRegistry.run-script("zef")'

Zef - Perl6 Module Management

USAGE
...

# With PR#1125 and PR#1132 .run-script could work with
# e.g. CompUnit::Repository::FileSystem

# Note: these should read 'bin/zef' insetad of 'zef' after PRs
zef$ perl6 -I. -e 'CompUnit::RepositoryRegistry.run-script("zef")'

Zef - Perl6 Module Management

USAGE
...

Zef could include different logic on a per-repo/dist basis itself (bypassing the PRs), but consider things like 3rd party distribution handling or 3rd party comp unit repos and it starts to make more sense. Whats important to take from this is that you should be able to do this without zef before it is possibility added to zef.

---

For the sake of this issue lets assume the PRs mentioned as merged such that:

• perl6 -e 'CompUnit::RepositoryRegistry.run-script("bin/zef")' - launches a copy of zef from a CompUnit::Repository::Installation
• perl6 -I. -e 'CompUnit::RepositoryRegistry.run-script("bin/zef")' - launches a copy of zef from a CompUnit::Repository::FileSystem

I agree most people do not want to remember that invocation. It is easy to imagine a zef script foo that is just a wrapper around CompUnit::RepositoryRegistry.run-script("bin/zef"), but that example is naive in that it doesn't address the -I. (would have to PERL6LIB=. or add flags to zef). Maybe zef script foo implies cwd, but that seems like it could lead to other problems. Maybe zef start tag-name starts any and all scripts matching some tag that is mapped in the META6.json. I'm sure there are some good use cases this could eventually solve.

I'm unsure of what to think of the script key itself. As shown early Distribution.meta<files> is similar, but is a collection of files. This raises the question of if a script field which can only contain a single file makes sense. I would then propose figuring out a META6 spec way of declaring bin/ scripts (i.e. more than one), but this requires careful consideration of things beyond the scope of this issue (which attributes if any to include, conditional installation [ignoring .bat files], theoretical build time generated bin scripts, etc).

So considering everything so far it is certainly possible. Much of the groundwork has indeed already been done with these types of things in mind. The questions then become based on what this theoretical command should do in various situations: version selection (bin/zef run a Zef::CLI from a newer version of zef?), -Ilib, etc.

[JJ]

Thanks for considering it and for the amazing tutorial 💯