Last year, I created yet another Perl6 environment manager, p6env. Speaking of Perl6 environment managers, I think everyone imagine rakudobrew. Yes, it is awesome.

Here are pros and cons of p6env:

• Pros
  • p6env is one of the env family (rbenv, plenv, pyenv, etc.). So if you’re already familiar with them, you can use p6env even without any explanation.
  • You can easily write plugins for p6env. See, for example, https://github.com/skaji/p6env-update.
  • It can install rakudo-star distributions by default.
• Cons
  • It does not support Windows.

Since I created p6env, I have been using it and like it. I hope you try it.

How to install p6env

Here, we assume you use bash as your default shell. If you use different shells, please read README at github instead.

# 1. install p6env
❯ git clone https://github.com/skaji/p6env ~/.p6env

# 2. add two lines to ~/.bash_profile
❯ echo 'export PATH="$HOME/.p6env/bin:$PATH"' >> ~/.bash_profile
❯ echo 'eval "$(p6env init -)"' >> ~/.bash_profile

# 3. install perl6-build, which is the actual implementation of "install" command
❯ git clone https://github.com/skaji/perl6-build ~/.p6env/plugins/perl6-build

# 4. restart your shell
😆

How to use p6env

Here is typical usage of p6env.

List available Perl6

❯ p6env install -l
Available versions (latest 20 versions):
 rakudo-star-2018.10
 rakudo-star-2018.06
 rakudo-star-2018.04
 rakudo-star-2018.01
 rakudo-star-2017.10
 rakudo-star-2017.07
 rakudo-star-2017.04
 rakudo-star-2017.01
 rakudo-star-2016.11
 rakudo-star-2016.10
 2018.12
 2018.11
 2018.10
 2018.09
 2018.08
 2018.06
 2018.05
 2018.04.1
 2018.04
 2018.03

Install rakudo-star or perl6 from rakudo git repository

# install rakudo-star 2018.10
❯ p6env install rakudo-star-2018.10

# install perl6 from rakudo git repository with HEAD
❯ p6env install HEAD

# Install perl6 from rakudo git repository with jvm backend
❯ p6env install --jvm HEAD

Use your Perl6

❯ p6env versions
  2018.12-125-g4a152da50
  2018.12-125-g4a152da50-jvm
  rakudo-star-2018.10

❯ p6env global rakudo-star-2018.10

❯ perl6 -v
This is Rakudo Star version 2018.10 built on MoarVM version 2018.10
implementing Perl 6.c.

Install zef into current Perl6

❯ p6env install-zef
❯ zef --help
Zef - Perl6 Module Management

That’s all. Happy hacking with p6env!

Perl::Build is a Perl Builder created by tokuhirom. You can build and install Perl by:

$ curl -L https://raw.githubusercontent.com/tokuhirom/Perl-Build/master/perl-build | perl - 5.26.2 /opt/perl-5.26/

Also, it is the backend of plenv-install:

$ git clone https://github.com/tokuhirom/Perl-Build.git $(plenv root)/plugins/perl-build
$ plenv install 5.26.2

Recently I became its maintainer, and have released a new version to CPAN. The new version contains the following changes:

Use MetaCPAN API

#66, #67, #73, #74, #75, thanks Grinnz, anttilinno, djzort, sjn.

Now Perl::Build uses fastapi.metacpan.org to find available Perl versions and Perl tarball URLs. MetaCPAN indexer is quite fast. So, as soon as a new Perl is released, you should be able to install it by Perl::Build.

Use HTTP::Tinyish for https support

#72, thanks AnaTofuZ.

MetaCPAN API serves in https, so we need HTTP clients that have https capabilities. Perl::Build uses HTTP::Tiny, which supports https only if IO::Socket::SSL (and hence XS module Net::SSLeay) is available. On the other hand, because Perl::Build will be fatpacked, we cannot expect the XS module Net::SSLeay is available. So what can we do?

Tatsuhiko Miyagawa created HTTP::Tinyish, which can automatically select HTTP clients (between LWP, HTTP::Tiny, curl, wget) that supports https. Thus Perl::Build uses HTTP::Tinyish now.

Improve fatpacking process

#65.

Perl::Build is distributed as a fatpacked script. Fatpacking is awesome, but it is hard to maintain.

I develop a CPAN client cpm, where I also fatpack it in this way. It works well so far, so I adopted it to Perl::Build. I hope this makes Perl::Build more maintainable.

Try new Perl::Build!

If you use Perl::Build as a plenv plugin, then you can update it by:

$ cd $(plenv root)/plugins/perl-build
$ git pull origin master

(There is also plenv-update plugin; you may update Perl::Build through it)

I guess Perl 5.28.0 will be released in a few days. Let's install Perl 5.28.0 with new Perl::Build!

$ plenv install 5.28.0

Yesterday, I attended Gotanda.pm, which is a Japanese local pm group organized by karupanerura.

A lot of interesting talks were presented there. I especially enjoyed codehex's talk, where he introduced how to write closures in XS. You can read his blog post for the more detailed explanation.

And I gave my talk about writing perl with w0rp/ale, which is an Asynchronous Lint Engine for vim8. There is already a blog post about it by oalders, so you may notice it.

If you write Perl with vim, why don't you try ale together with my simple syntax checker skaji/syntax-check-perl?

Last Friday, kichijojipm was held at Shinjuku, Tokyo, Japan. It is a japanese local Perl Monger group organized by magnoliak. The talks were about not only Perl but also a wide variety of subjects.

I talked about App::RemoteCommand there, which is a simple remote command launcher via SSH, built on top of an excellent module Net::OpenSSH.

Here is the slide. I hope you try it!

CPAN modules are normally distributed with Makefile.PL or Build.PL, so that people can install them by

> perl Makefile.PL
> make
> make test
> make install

This makes CPAN modules installable without any CPAN clients help unlike other programing language ecosystem (such as ruby(gem), node(npm)).

On the other hand, today, people mostly use CPAN clients (such as CPAN.pm, cpanm) to install CPAN modules. And it seems that when CPAN modules are not "complicated", CPAN clients easily expect how to build/test/install them even without executing Makefile.PL or Build.PL.

Now we have the concept Static Install. That is, if CPAN modules are not "complicated" and set x_static_install 1 in their META.json, then we may install them statically.

cpanm-menlo (cpanm 2.0) and cpm support the static install. So if a CPAN module set x_static_install 1 in its META.json, then cpanm-menlo and cpm use their bundled builder to build/test/install the CPAN module. There is no execution of perl Makefile.PL or make.

Why do you make your CPAN module static installable?

Fast

Because CPAN clients do not need to execute external programs during installation, people can install your module fast.

Example: Win32::ShellQuote (which set x_static_install 1 in META.json)

> wget http://www.cpan.org/authors/id/H/HA/HAARG/Win32-ShellQuote-0.003001.tar.gz
> tar xzf Win32-ShellQuote-0.003001

# with x_static_install 1
> cpm install -v .
29899 DONE fetch     (0.054sec) file:///Win32-ShellQuote-0.003001
29899 DONE configure (0.012sec) file:///Win32-ShellQuote-0.003001
29899 DONE install   (0.020sec) file:///Win32-ShellQuote-0.003001
1 distribution installed.

# without x_static_install 1
> vim META.json # remove x_static_install 1
> cpm install -v .
29937 DONE fetch     (0.047sec) file:///Win32-ShellQuote-0.003001
29937 DONE configure (0.200sec) file:///Win32-ShellQuote-0.003001
29937 DONE install   (0.433sec) file:///Win32-ShellQuote-0.003001
1 distribution installed.

This shows:

• With x_static_install: configure 0.012sec, install 0.020sec
• Without x_static_install: configure 0.200sec, install 0.433sec

Simple

People can easily expect the result (eg: which files will be installed, and where).

Safe

There is no place to execute arbitrary code during installation.

The spec of static install

The official spec is here (cpan-static).

Especially at the time of writing, you should note that to make your CPAN module static installable, not only set x_static_install 1 in META.json, but also:

• Module files must be in lib/ directory
• Script files must be in script/ directory if any (NOT bin/)
• No xs file, no PL file (code generation file)
• Prerequisites must be declared in META.json statically

How to set x_static_install in META.json

If you CPAN author use ExtUtils::MakeMaker or Module::Build manually, then set x_static_install 1 using META_MERGE or meta_merge attributes respectively, so that META.json with x_static_install 1 will be generated.

If you use Dist::Zilla as an authoring tool, then it seems that the easiest way to set x_static_install 1 is to use Dist::Zilla::Plugin::ModuleBuildTiny:

; dist.ini
[ModuleBuildTiny]
static = yes

Especially, if you use Dist::Milla (a Dist::Zilla profile, which defaults to use ModuleBuildTiny as an installer), then:

; dist.ini
[@Milla]
ModuleBuildTiny.static = yes

If you use Minilla v3.0.8+, then:

# minil.toml
[Metadata]
x_static_install = 1

Conclusion

If you set x_static_install 1 in META.json, then some cpan clients (such as cpanm-menlo, cpm) will install your module statically, which is faster and simpler than traditional ways.

Although this static install feature is highly experimental, I must say it is very interesting, and I've already set x_static_install 1 to almost all my modules.

If you are interested too, set x_static_install 1 to your modules, and let's see what happens!

See also

• The spec of static install: Leont/cpan-static
• Menlo pull request: miyagawa/cpanminus/pull/467
• cpm pull request: skaji/cpm/pull/68
• x_static_install at grep.cpan.me