New release of Perl::Build

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

I attended Gotanda.pm

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?

App-RemoteCommand

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!

Make your CPAN module static installable

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