WHAT?
Dist-Zilla-Plugin-Hook (or just Hook) is a set of Dist-Zilla plugins. Every
plugin executes Perl code inlined into dist.ini at particular stage of build
process.
WHY?
There is Dist::Zilla::Plugin::Run on CPAN which allows to run Perl code from
within dist.ini, why I wrote one more? Let us consider two examples.
The first one executes external commands:
$cat dist.ini
name = RunShell
abstract = RunShell demo
version = 0.001_001
[Run::BeforeBuild]
run = echo "1. begin"
run_if_release = echo "2. release"
run_no_release = echo "3. not release"
run_if_trial = echo "4. trial"
run_no_trial = echo "5. not trial"
run = echo "6. end"
[GenerateFile/Assa.pm]
filename = lib/Assa.pm
content = package Assa; 1;
[FakeRelease]
$ dzil build
[Run::BeforeBuild] executing: echo "1. begin"
[Run::BeforeBuild] 1. begin
[Run::BeforeBuild] executing: echo "6. end"
[Run::BeforeBuild] 6. end
[Run::BeforeBuild] executing: echo "5. not trial"
[Run::BeforeBuild] 5. not trial
[Run::BeforeBuild] executing: echo "3. not release"
[Run::BeforeBuild] 3. not release
[DZ] beginning to build RunShell
[DZ] writing RunShell in RunShell-0.001_001
[DZ] building archive with Archive::Tar::Wrapper
[DZ] writing archive to RunShell-0.001_001-TRIAL.tar.gz
[DZ] built in RunShell-0.001_001
Execution order is err… non-linear. Of course there is an explanation why
command were executed in this particular order, but when you are looking at
dist.ini it is not obvious. (It is also unclear why Run consider the build is
*not* trial, but it may be just a bug.)
Another example executes Perl code:
$cat dist.ini
name = RunPerl
abstract = RunPerl demo
version = 0.001_001
[Run::BeforeBuild]
eval = my $self = shift( @_ );
eval = my $dist = $self->zilla;
eval = $self->log( [ '%s v%s', $dist->name, $dist->version ] );
[GenerateFile/Assa.pm]
filename = lib/Assa.pm
content = package Assa; 1;
[FakeRelease]
$ dzil build
[Run::BeforeBuild] evaluating: my $self = shift( @_ );
[Run::BeforeBuild] my $dist = $self->zilla;
[Run::BeforeBuild] $self->log( [ '0.001_001 v', $dist->name, $dist->version ] );
[Run::BeforeBuild] 0.001_001 v
[DZ] beginning to build RunPerl
[DZ] writing RunPerl in RunPerl-0.001_001
[DZ] building archive with Archive::Tar::Wrapper
[DZ] writing archive to RunPerl-0.001_001-TRIAL.tar.gz
[DZ] built in RunPerl-0.001_001
Look at the last message from Run::BeforeBuild plugin. Surprising? Where is the
distribution name? Why is the character "v" printed after version number? Ah! %s
is a special conversion specifier which was replaced with "something retained
for backward compatibility". There is a bunch of other conversion specifiers:
%a, %d, %n,%p, %t, %v, %x,… That effectively means I cannot use printf-like
functions and hashes, because every percent will be replaced with something or
cause error "unknown conversion".
Ok, I can. There is (undocumented!) method to avoid it — every percent sign
should be doubled:
eval = $self->log( [ '%%s v%%s', $dist->name, $dist->version ] );
or
eval = my %%meta = %%{ $dist->distmeta };
It is simple, but… this is err… not quite Perl. I cannot just cut-n-paste code
from a plugin to dist.ini and back.
Let me cite a part of "Philosophy" section of the great Text::Template module:
When people make a template module like this one, they almost always start
by inventing a special syntax for substitutions. For example, they build it
so that a string like %%VAR%% is replaced with the value of $VAR. Then they
realize the need extra formatting, so they put in some special syntax for
formatting. Then they need a loop, so they invent a loop syntax. Pretty soon
they have a new little template language.
This approach has two problems: First, their little language is crippled. If
you need to do something the author hasn't thought of, you lose. Second: Who
wants to learn another language? You already know Perl, so why not use it?
Look: Run plugin introduced a bunch of dist.ini options: run_if_trial,
run_no_trial (BTW, why not run_if_not_trial?), run_if_release, run_no_release,
eval, censor_commands, fatal_errors, quiet; a bunch of "conversion specifiers":
%a, %d, %n, %p, %v, %t, %x, %s; and bunch of poorly documented rules. It's "a
little crippled language", isn't it?
Compared to Run, Hook is designed to be minimalistic: It provides only one
option, and it executes only Perl. Of course, when writing a hook you have to
keep in mind many rules, but these are well documented Perl rules and (not so
well) Dist::Zilla rules, not rules introduced by Hook.
All Run features can be easily implemented with hooks in Perl, for example:
Running external commands:
. = system( … );
Making errors in external commands fatal:
. = use autodie ':all';
. = system( … );
Making errors in Perl code non-fatal:
. = use Try::Tiny;
. = try { … };
Checking trial status:
. = if ( $dist->is_trial ) { … };
Checking release build:
. = if ( $ENV{ DZIL_RELEASING } ) { … };
The code is a little bit longer than Run counterparts, but it is well-known
full-featured Perl.
What if you need to pass to an external command something the Run authors have
not thought of? For example, abstract or licence name. There are no conversion
specifiers for it, so you lose. But with Hook it is trivial:
. = system( …, $dist->abstract, …, $dist->license->name, … );
BTW, there are two minor (at the first look) Hook features:
These bring a new quality: with Hook you can write inline plugins. For example,
a plugin which reads distribution version from an external file:
[Hook::VersionProvider]
. = use Path::Tiny; path( 'VERSION' )->slurp;
(Actually, every hook is an inline plugin.) See more in "EXAMPLES" in
Dist::Zilla::Plugin::Hook::Manual.
NAMING
perl-Dist-Zilla-Plugin-Hook is official software name.
However, in Perl world prefix "perl-" is redundant and not used. For example, on
meta::cpan this software is named as
Dist-Zilla-Plugin-Hook. In the rest of the documentation shortened name
Dist-Zilla-Plugin-Hook is used as synonym for full name
perl-Dist-Zilla-Plugin-Hook. We are in the Perl world, aren't we?
You may notice that name may be spelled with dashes (Dist-Zilla-Plugin-Hook) or
with double colons (Dist::Zilla::Plugin::Hook). Strictly speaking, there is
difference: the first one is software name, while the second is name of Perl
package, but often these names are interchangeable especially if software
consists of single package.
FORMS
You may face Dist-Zilla-Plugin-Hook in *source* or *distribution* forms.
If you are going to write Dist::Zilla plugin directly in dist.ini, you will
likely be interested in *using* Dist-Zilla-Plugin-Hook *distribution*. If you
are going to *develop* (or *hack*) the Dist-Zilla-Plugin-Hook itself, you will
likely need the *source*, not distribution.
Since Perl is an interpreting language, modules in the distribution *look* like
sources. Actually, they are Perl source files. But they are not *actual*
sources, because they are *built* (preprocessed or generated) by Dist-Zilla.
How to distinguish source and distribution:
* Source may contain Mercurial files and directories .hgignore, .hgtags, .hg/,
while distribution should not.
* Source should contain dist.ini file, while distribution may not.
* Source should *not* contain xt/ directory, while distribution should.
* Name of source directory does *not* include version (e. g.
Dist-Zilla-Plugin-Hook), while name of distribution does (e. g.
Dist-Zilla-Plugin-Hook-v0.7.1).
SOURCE
Dist-Zilla-Plugin-Hook source is in Mercurial repository hosted on
fedorapeople.org. To clone the entire repository:
$ hg clone https://vandebugger.fedorapeople.org/hg/perl-Dist-Zilla-Plugin-Hook
Source Files
Dist-Zilla-Plugin-Hook source files usually include a comment near the top of
the file:
This file is part of perl-Dist-Zilla-Plugin-Hook.
Not all source files are included into distribution. Some source files are used
at distribution build time only, and not required for installation.
DISTRIBUTION
Dist-Zilla-Plugin-Hook distributions are published on CPAN
.
Generated Files
Distribution may contain files preprocessed or generated by Dist-Zilla and its
plugins. Some generated files are made from Dist-Zilla-Plugin-Hook source, but
some are generated from third-party templates. Files generated from third-party
templates usually include a comment near the top of the file:
This file was generated with NAME
(where *NAME* is a name of the plugin generated the file). Such files are *not*
part of Dist-Zilla-Plugin-Hook source, and Dist-Zilla-Plugin-Hook copyright and
license are not applicable to such files.
INSTALLING
With cpanm
cpanm tool is (probably) the easiest way to install distribution. It automates
downloading, building, testing, installing, and uninstalling.
To install the latest version from CPAN:
$ cpanm Dist::Zilla::Plugin::Hook
To install a specific version (e. g. *v0.7.1*) from CPAN:
$ cpanm Dist::Zilla::Plugin::Hook@v0.7.1
To install locally available distribution (e. g. previously downloaded from CPAN
or built from sources):
$ cpanm ./Dist-Zilla-Plugin-Hook-v0.7.1.tar.gz
To uninstall the distribution:
$ cpanm -U Dist::Zilla::Plugin::Hook
Manually
To install distribution tarball manually (let us assume you have version
*v0.7.1* of the distribution):
$ tar xaf Dist-Zilla-Plugin-Hook-v0.7.1.tar.gz
$ cd Dist-Zilla-Plugin-Hook-v0.7.1
$ perl Build.PL
$ ./Build build
$ ./Build test
$ ./Build install
See Also
How to install CPAN modules
HACKING
For hacking, you will need Mercurial, Perl interpreter and Dist-Zilla (with some
plugins), and likely cpanm to install missed parts.
Clone the repository first:
$ hg clone https://vandebugger.fedorapeople.org/hg/perl-Dist-Zilla-Plugin-Hook
$ cd perl-Dist-Zilla-Plugin-Hook
To build a distribution from the source, run:
$ dzil build
If required Dist-Zilla plugins are missed, the dzil tool will warn you and show
the command to install all the required plugins, e. g.:
Required plugin Dist::Zilla::Plugin::Test::EOL isn't installed.
Run 'dzil authordeps' to see a list of all required plugins.
You can pipe the list to your CPAN client to install or update them:
dzil authordeps --missing | cpanm
To run the tests (to check primary software functionality):
$ dzil test
To run extended tests (to check source code style, documentation and other
things which are not too important for software end users):
$ dzil xtest
To install the distribution:
$ dzil install
or
$ cpanm ./Dist-Zilla-Plugin-Hook-VERSION.tar.gz
where *VERSION* is a version of built distribution.
To clean the directory:
$ dzil clean
DOCUMENTATION
Online
The easiest way is browsing the documentation online at meta::cpan
.
Locally Installed
If you have the distribution installed, use perldoc tool to browse locally
installed documentation:
$ perldoc Dist::Zilla::Plugin::Hook::Manual
$ perldoc Dist::Zilla::Plugin::Hook
Built from Source
Build Dist-Zilla-Plugin-Hook first (see "HACKING"), then:
$ cd Dist-Zilla-Plugin-Hook-VERSION
$ perldoc Dist::Zilla::Plugin::Hook::Manual
$ perldoc Dist::Zilla::Plugin::Hook
where *VERSION* is a version of built distribution.
FEEDBACK
CPAN Request Tracker
The quickest way to report a bug in Dist-Zilla-Plugin-Hook is by sending email
to bug-Dist-Zilla-Plugin-Hook [at] rt.cpan.org.
CPAN request tracker can be used via web interface also:
Browse bugs
Browsing bugs does not require authentication.
Report bugs
You need to be a CPAN author, have a BitCard
account, or OpenID in order to report bugs via the web interface.
(On 2015-04-27 I have logged in successfully with my LiveJournal OpenID, but
my Google OpenID did not work for CPAN. I did not check other OpenID
providers.)
Send Email to Author
As a last resort, send email to author: Van de Bugger .
Please start message subject with "perl-Dist-Zilla-Plugin-Hook:".
GLOSSARY
CPAN
Comprehensive Perl Archive Network, a large collection of Perl software and
documentation. See cpan.org , What is CPAN?
.
Distribution
Tarball, containing Perl modules and accompanying files (documentation,
metainfo, tests). Usually distributions are uploaded to CPAN, and can be
installed with dedicated tools (cpan, cpanm, and others).
Module
Perl library file, usually with .pm suffix. Usually contains one package.
See perlmod .
Package
Perl language construct. See package
and perlmod
.