Dist::Zilla: Eliminate Boilerplate for Easier CPAN Authoring

Dist::Zilla
raaaaaaaaar!

Tuesday, December 14, 2010

What is Dist::Zilla?

This talk is about your life as a CPAN author.

AWESOME


Any
Questions?

RJBS

ME!!!

also awesome!

I give away almost all my useful software on CPAN

RJBS
- cake and pie (and doughnuts)

ME!!!

also awesome!


RJBS
- cocktails and beer

ME!!!

also awesome!


RJBS
- shooting zombies

ME!!!

also awesome!


RJBS
- shooting zombies
- giving away useful software

ME!!!

also awesome!


CPAN!
CPAN is awesome, too. We all know that.

being a CPAN author is hard!
let’s go gemming!

who here is a CPAN author?

what makes it a pain? let’s talk about it

./Changes
./LICENSE
./MANIFEST.SKIP
./Makefile.PL
./README
./lib/YourApp.pm
./lib/YourApp/Reticulator.pm
./lib/YourApp/Util/mtfnpy.pm
./lib/YourApp/Xyzzy.pm
./t/unit-tests.t
./t/pod-coverage.t
./t/pod.t

this is all the crap in your working copy where you write this dist
making all these is a boring pain in the butt

./Changes
./LICENSE
./MANIFEST.SKIP
./Makefile.PL
./README
./lib/YourApp.pm
./t/unit-tests.t
./t/pod-coverage.t
./t/pod.t

and a bunch of semi-structured data is in Makeﬁle.PL

ExtUtils::MakeMaker


WriteMakefile(
NAME => ‘YourApp’,
AUTHOR => ‘You <rjbs@cpan.org>’,
VERSION_FROM => ‘lib/YourApp.pm’,
ABSTRACT_FROM => ‘lib/YourApp.pm’,
LICENSE => ‘perl’,
PREREQ_PM => {
‘Lingua::EN::Inflect’ => 1.86,
‘Sub::Override’ => 0.07,
‘Test::More’ => 0,
},
);

Then you have to put a bunch more information describing your distribution into Makeﬁle.PL, if you’re using
ExtUtils::MakeMaker.

WriteMakefile(
NAME => ‘YourApp’,
AUTHOR => ‘You <rjbs@cpan.org>’,
VERSION_FROM => ‘lib/YourApp.pm’,
ABSTRACT_FROM => ‘lib/YourApp.pm’,
LICENSE => ‘perl’,
PREREQ_PM => {
‘Lingua::EN::Inflect’ => 1.86,
‘Sub::Override’ => 0.07,
‘Test::More’ => 0,
},
(eval { ExtUtils::MakeMaker->VERSION(6.46) }
? (META_MERGE => {
resources => { Repository => ‘...’ }
})
: ()),
);

If you want to add more metadata, you start having to use really gross constructions, trying to avoid backcompat issues. In part,
this is because even the data only needed for installing the dist (like your respository) is present and executed on the installing
user’s computer.

Module::Install


use inc::Module::Install;
all_from(‘lib/YourApp.pm’);

requires(‘Lingua::EN::Inflect’ => 1.86);
requires(‘Sub::Override’ => 0.07);
requires(‘Test::More’ => 0);

repository(...);

WriteAll();

Module::Install lets you write this, instead. It does a lot more auto-detection by reading your Pod and trying to parse its
meaning. Then it runs on the installer’s machine and uses the machinery of ExtUtils::MakeMaker to build a plain old Makeﬁle for
installation. So, it bundles itself with each dist that uses it, and it’s still beholden to the version of EUMM installed on the user’s
machine. Still, it saves quite a lot of time in dealing with stupid crap in Makeﬁle.PL.

It just means you need to write a bunch of other stuff for it to scan, like:

./Changes
./LICENSE
./MANIFEST.SKIP
./Makefile.PL
./README
./lib/YourApp.pm
./t/unit-tests.t
./t/pod-coverage.t
./t/pod.t

You need to have your author in the main module to be detected, and the license. Then, because you want to keep the data in
each library, you have to keep that same data in each Perl module. Copy and paste!

Module::Starter


./Changes
./LICENSE
./MANIFEST.SKIP
./Makefile.PL
./README
./lib/YourApp.pm
./t/boilerplate.t
./t/pod-coverage.t
./t/pod.t

It can create all these ﬁles, Pod and all, *for* you so you don’t have to go through this drudgery. Unfortunately, some of these
ﬁles include stuff that you’re going to need to customize, replace, or delete immediately upon starting the dist. So many people
used Module::Starter and then left in garbage data that we added a test to help stop them from doing so...

./Changes
./LICENSE
./MANIFEST.SKIP
./Makefile.PL
./README
./lib/YourApp.pm
./t/boilerplate.t
./t/pod-coverage.t
./t/pod.t

It looks for the stock content you should get rid of. Once this test passes, you are expected to delete it. Why have that
boilerplate crap at all?

Worse, what if one of your boilerplate files has a typo? Or what if you want to change your default pod-coverage setup? You
need to go update every file in all of your distributions, because that file actually exists in your source repository.

./Changes
./LICENSE
./MANIFEST.SKIP
./Makefile.PL
./README
./lib/YourApp.pm
./t/unit-tests.t
./t/pod-coverage.t
./t/pod.t

Dist::Zilla tries to solve all these problems: don’t repeat yourself; don’t store what you can compute; rely on the installing user
having only the bare minimum of tools needed to install, and don’t bundle more if you can help it.

It also tries hard to be easy to test, so that when you write extensions to DZ, they’re easy to write and easy to test. EUMM, M:I,
and Starter are not.

I’m going to show you how to eliminate as much of this as you can so there’s less to write, less to update, less to diff, and less
to think about in general.

./Changes
./LICENSE
./MANIFEST.SKIP
./Makefile.PL
./README
./lib/YourApp.pm
./t/unit-tests.t
./t/pod-coverage.t
./t/pod.t

(ﬁles we can get rid of entirely)

./Changes
./LICENSE
./MANIFEST.SKIP
./Makefile.PL
./README
./lib/YourApp.pm
./t/unit-tests.t
./t/pod-coverage.t
./t/pod.t

(ﬁles from which we can prune lots of non-essential content)

...and it can do more than just reduce the on-disk content...


...and that’s why

- updating version numbers


...and that’s why

- uploading to CPAN


...and that’s why

- uploading to CPAN
- committing, tagging releases in Git (VCS)


...and that’s why

- uploading to CPAN
- determine prerequisites


...and that’s why

- uploading to CPAN
- determine prerequisites
- other stuff that is totally boring


...and that’s why

Dist::Zilla is
AWESOME

...because it frees you up to do things that are much more interesting than distribution building, like...

- eating cake and pie (and donuts)


- drinking cocktails and beer


- shooting zombies


- shooting zombies
- giving away useful software


Dist::Zilla is
HUGE


106 prereqs


106 prereqs
(and counting)


- Dist::Zilla only handles “make dist”


- it doesn’t handle “make install”


- only authors need to install the 106 prereqs


- your users don’t see Dist::Zilla


- your users don’t see Dist::Zilla
- they just see MakeMaker or Module::Build


Dist::Zilla is also Stupid

like me!

It keeps its brains in
plugins.

Almost all of the remainder of this talk is going to be about DZ plugins, because they do all the work. DZ itself just orchestrates
the interaction of plugins. When you use Dist::Zilla, you provide it with a conﬁguration ﬁle that sets up your plugins.

dist.ini

It’s almost always an INI ﬁle. INI is a nice simple format, and I’m going to just assume everybody understands it. Here’s a
sample dist.ini:

name = Your-Dist
license = Perl_5
copyright_holder = J.builds a dist:
# How Dist::Zilla Fred Bloggs
[GatherDir]
prepare;
include_dotfiles = 1
gather_files;
prune_files;
[PruneCruft]
munge_files;
[MetaYAML]
[MakeMaker]
register_prereqs;
[TestRelease]
setup_installer;
[ConfirmRelease]
write_files;
finish;
[UploadToCPAN]
user = JFB
password = QwardRules

You can do lots of different things in really varied ways, and there are people who use Dist::Zilla with very different workflows to
mine.

But I’m going to talk about how I use Dist::Zilla, which by grand coincidence is the one reflected in the tutorial and is probably
the most common workflow.

name = Your-Dist
license = Perl_5
[GatherDir]
prepare;
gather_files;
prune_files;
[PruneCruft]
munge_files;
[MetaYAML]
[MakeMaker]
register_prereqs;
[TestRelease]
setup_installer;
[ConfirmRelease]
write_files;
finish;
[UploadToCPAN]
user = JFB

the root section generally describes the dist itself, and is pretty short

name = Your-Dist
license = Perl_5
[GatherDir]
prepare;
gather_files;
prune_files;
[PruneCruft]
munge_files;
[MetaYAML]
[MakeMaker]
register_prereqs;
[TestRelease]
setup_installer;
[ConfirmRelease]
write_files;
finish;
[UploadToCPAN]
user = JFB

here’s a section that deﬁned a plugin, with one option set

name = Your-Dist
license = Perl_5
[GatherDir]
prepare;
gather_files;
prune_files;
[PruneCruft]
munge_files;
[MetaYAML]
[MakeMaker]
register_prereqs;
[TestRelease]
setup_installer;
[ConfirmRelease]
write_files;
finish;
[UploadToCPAN]
user = JFB

and this line sets up a plugin with no args -- the next line is just another plugin

name = Dist-Zilla
author = Ricardo SIGNES <rjbs@cpan.org>
license = Perl_5
copyright_holder = Ricardo SIGNES

[@Basic]
[AutoPrereq]
[AutoVersion]
[PkgVersion]
[MetaConfig]
[MetaJSON]
[NextRelease]
[PodSyntaxTests]
[Repository]
[PodWeaver]
[@Git]

RJBS: THESE THREE SLIDES ARE A SPEED RUN; detailed version to follow immediately

name = Dist-Zilla
license = Perl_5

[@Basic]
[AutoPrereq]
[AutoVersion]
[PkgVersion]
[MetaConfig]
[MetaJSON]
[NextRelease]
[PodSyntaxTests]
[Repository]
[PodWeaver]
[@Git]

@Basic means a bundle, and that bundle expands to this:

[GatherDir]
[PruneCruft]
[ManifestSkip]
[MetaYAML]
[License]
[Readme]
[ExtraTests]
[ExecDir]
[ShareDir]
[MakeMaker]
[Manifest]
[TestRelease]
[ConfirmRelease]
[UploadToCPAN]


name = Dist-Zilla
license = Perl_5

[@Basic]
[AutoPrereq]
[AutoVersion]
[PkgVersion]
[MetaConfig]
[MetaJSON]
[NextRelease]
[PodSyntaxTests]
[Repository]
[PodWeaver]
[@Git]


Too much!


test is just build then “make test”
install is just build then “cpan .”
release is just build, then cpan-upload (mostly)

dzil build


dzil build

dzil test


dzil build

dzil test

dzil install


dzil build

dzil test

dzil install

dzil release


How Dist::Zilla Builds

this is, obviously, a simpliﬁcation -- but not as great a simpliﬁcation as you might think

to make any of these lines do anything useful, you need plugins; plugins contribute to these activities

sub build {



sub build {
my ($self) = @_;



sub build {
my ($self) = @_;

my @files = $self->gather_files;



sub build {
my ($self) = @_;


$self->munge_files( @files );



sub build {
my ($self) = @_;



$self->collect_metadata;



sub build {
my ($self) = @_;




$self->write_out( @files );



sub build {
my ($self) = @_;




}



How do you pick
plugins?


There is no default config.


@Basic

...but don’t just rush to use @Basic without understanding it. You should understand what DZ is doing so that you can
understand what goes wrong, if anything goes wrong -- and something will go wrong.

There is *no* default conﬁguration for Dist::Zilla. The @Basic bundle exists as a useful starting point, but I doubt anybody
would use only @Basic. There’s just too much that you can gain by adding on top of it.

The Basics
[GatherDir]
[PruneCruft]
[Manifest]
[ManifestSkip]
[MakeMaker]
[License]
[Readme]
[MetaYAML]
[ExtraTests]
[ExecDir]
[ShareDir]
[TestRelease]
[ConfirmRelease]
[UploadToCPAN]

@Basic’s goal is to do all the stuff almost everyone wants, and to let you delete ﬁles you don’t need, but @Basic will *not* touch
any of your ﬁles on disk.

The Basics
[GatherDir]
[PruneCruft]
[Manifest]
[ManifestSkip]
[MakeMaker]
MANIFEST
[License]
[Readme]
[MetaYAML]
[ExtraTests]
[ExecDir]
[ShareDir]
[TestRelease]
[ConfirmRelease]
[UploadToCPAN]


The Basics
[GatherDir]
[PruneCruft]
[Manifest]
[ManifestSkip]
[MakeMaker]
MANIFEST
[License]
Makefile.PL
[Readme]
[MetaYAML]
[ExtraTests]
[ExecDir]
[ShareDir]
[TestRelease]
[ConfirmRelease]
[UploadToCPAN]


The Basics
[GatherDir]
[PruneCruft]
[Manifest]
[ManifestSkip]
[MakeMaker]
MANIFEST
[License]
Makefile.PL
[Readme]
LICENSE
[MetaYAML]
[ExtraTests]
[ExecDir]
[ShareDir]
[TestRelease]
[ConfirmRelease]
[UploadToCPAN]


The Basics
[GatherDir]
[PruneCruft]
[Manifest]
[ManifestSkip]
[MakeMaker]
MANIFEST
[License]
Makefile.PL
[Readme]
LICENSE
[MetaYAML]
README
[ExtraTests]
[ExecDir]
[ShareDir]
[TestRelease]
[ConfirmRelease]
[UploadToCPAN]


The Basics
[GatherDir]
[PruneCruft]
[Manifest]
[ManifestSkip]
[MakeMaker]
MANIFEST
[License]
Makefile.PL
[Readme]
LICENSE
[MetaYAML]
README
[ExtraTests]
META.yml
[ExecDir]
[ShareDir]
[TestRelease]
[ConfirmRelease]
[UploadToCPAN]


Cruft Minimizers


Cruft Minimizers

[PkgVersion]


Cruft Minimizers

[PkgVersion]
[PodSyntaxTests]


Cruft Minimizers

[PkgVersion]
[PodSyntaxTests]
[PodCoverageTests]


Cruft Minimizers

[PkgVersion]
[PodSyntaxTests]
[PodCoverageTests]
[AutoPrereq]


Cruft Minimizers

[PkgVersion]
[PodSyntaxTests]
[PodCoverageTests]
[AutoPrereq]
[AutoVersion]


Cruft Minimizers

[PkgVersion]
[PodSyntaxTests]
[PodCoverageTests]
[AutoPrereq]
[AutoVersion]
[NextRelease]


Version Control

[@Git]

[@Subversion]

[@Mercurial]

[@SVK]

this is a place where it *might* be reasonable to use a bundle when you start

Pod::Weaver


package YourApp;

=head1 NAME

YourApp - my awesome app

=head1 VERSION

version 1.001

=cut

our $VERSION = 0.001;

=head1 DESCRIPTION

This app is awesome.

=head1 METHODS

=head2 this_method

This method does stuff.

=cut

method this_method { ... }

=head2 that_method

Also stuff.

=cut

method that_method { ... }

=head1 AUTHOR

Margo Yapp <myapp@example.com>

=head1 LICENSE

Copyright (C) 2008, Margo Yapp.

This is distributed under the terms of the accidental death and
dismemberment license and if you redistribuet this document you
will be “accidentally” deathed or dismembered. You have been
told.

=cut

1;

Here’s a .pm ﬁle

package YourApp;

=head1 NAME

YourApp - my awesome app

=head1 VERSION

version 1.001

=cut


=head1 DESCRIPTION


=head1 METHODS

=head2 this_method


=cut


=head2 that_method

Also stuff.

=cut


=head1 AUTHOR


=head1 LICENSE


told.

=cut

1;

The =name section is annoying.

package YourApp;
# ABSTRACT: my awesome app

=head1 VERSION

version 1.001

=cut


=head1 DESCRIPTION


=head1 METHODS

=head2 this_method


=cut


=head2 that_method

Also stuff.

=cut


=head1 AUTHOR


=head1 LICENSE


told.

=cut

1;

We’ll replace it with a comment.

package YourApp;

=head1 VERSION

version 1.001

=cut


=head1 DESCRIPTION


=head1 METHODS

=head2 this_method


=cut


=head2 that_method

Also stuff.

=cut


=head1 AUTHOR


=head1 LICENSE


told.

=cut

1;

The =version section is redundant.

package YourApp;


=head1 DESCRIPTION


=head1 METHODS

=head2 this_method


=cut


=head2 that_method

Also stuff.

=cut


=head1 AUTHOR


=head1 LICENSE


told.

=cut

1;

Drop it.

package YourApp;


=head1 DESCRIPTION


=head1 METHODS

=head2 this_method


=cut


=head2 that_method

Also stuff.

=cut


=head1 AUTHOR


=head1 LICENSE


told.

=cut

1;

Even the $VERSION is redundant, since we want it constant across the dist.

package YourApp;

=head1 DESCRIPTION


=head1 METHODS

=head2 this_method


=cut


=head2 that_method

Also stuff.

=cut


=head1 AUTHOR


=head1 LICENSE


told.

=cut

1;

our overarching METHOD section is dumb

package YourApp;

=head1 DESCRIPTION


=method this_method


=cut


=method that_method

Also stuff.

=cut


=head1 AUTHOR


=head1 LICENSE


told.

=cut

1;

let’s just use =method for them all

package YourApp;

=head1 DESCRIPTION


=method this_method


=cut


=method that_method

Also stuff.

=cut


=head1 AUTHOR


=head1 LICENSE


told.

=cut

1;

Repeating the author everywhere is annoying, too.

package YourApp;

=head1 DESCRIPTION


=method this_method


=cut


=method that_method

Also stuff.

=cut


=head1 LICENSE


told.

=cut

1;

Drop it, use author info found in DZ conﬁg.

package YourApp;

=head1 DESCRIPTION


=method this_method


=cut


=method that_method

Also stuff.


=head1 LICENSE


told.

=cut

1;

The license is gigantic! Ugh!

package YourApp;

=head1 DESCRIPTION


=method this_method


=cut


=method that_method

Also stuff.

=cut


=cut
1;

Drop it.

package YourApp;

=head1 DESCRIPTION


=method this_method


=cut


=method that_method

Also stuff.

=cut


1;

Now our ﬁle is simple, just the unique docs and code it needs. It ﬁts on one legible slide!

package YourApp;

=head1 DESCRIPTION


=method this_method


=cut


=method that_method

Also stuff.

=cut


1;

And is about half Perl.

and you get all of that stuff autogenerated by adding this to your dist.ini

[PodWeaver]


Converting Your Dist


- create dist.ini


- create dist.ini
- remove a bunch of files


- create dist.ini
- delete a bunch of stuff from leftover files


- create dist.ini
- delete a bunch of stuff from leftover files

- and Dist::Zooky, too


Questions
so far?

Creating New Dists


dzil build
dzil test
dzil install
dzil release

so, we already talked about these commands, which all operate on an existing distribution directory to build a ﬂeshed-out CPAN
distribution. to mint a brand-new dist, we use...

dzil build
dzil test
dzil install
dzil release

dzil new

dzil new!

the big difference is that the ﬁrst set of commands work on an existing dist, so there’s a dist.ini

we don’t have a dist.ini yet, because there’s no dist dir yet. we need a...

profile.ini

this ﬁle sets up the plugins that you’ll use to mint a new dist

(don’t worry, if you don’t make one, there *is* default behavior -- but it’s so incredibly simple that you probably don’t want it)

to understand how this works, we need to look at how minting works

[GatherDir::Template]


root = files


root = files

[DistINI]


root = files

[DistINI]

[Git::Init]


How Dist::Zilla Mints


sub mint {


sub mint {
my ($self) = @_;


sub mint {
my ($self) = @_;



$self->make_module( $module );


sub mint {
my ($self) = @_;






sub mint {
my ($self) = @_;




}


see how there’s no root section? We *could* add one, but it would probably be the same across multiple proﬁles we set up, so
we can put this stuff in another location:

root = files


root = files

[DistINI]


root = files

[DistINI]

[Git::Init]


config.ini

global (per-user) conﬁguration

~/.dzil/config.ini


[%User]
name = Ricardo Signes
email = rjbs@example.org

[%Rights]
license_class = Perl_5
copyright_holder = Ricardo Signes

[%PAUSE]
username = RJBS
password = PeasAreDelicious

these aren’t plugins; global conﬁguration is loaded before we have a Dist::Zilla object to plug into

instead, these are stashes; basically, hunks of data for plugins to look up; they can be shared, generic, referenced by name, etc
etc etc

here we see our default author, our default license/legal info, and default PAUSE upload credentials

dzil setup


Minting a New Dist

- create config.ini (in ~/.dzil)
- maybe configure or install a profile
- run dzil new


Writing Plugins!


Writing Plugins is Easy!


Writing Plugins is Easy!
(and awesome)


sub build {
my ($self) = @_;




}

This is what I showed, earlier, as a simpliﬁed example of how Dist::Zilla builds stuff. To understand how plugins work, we need
to de-simplify a little.



Take this line... what happens is a bit more like this:


my @mungers =
grep { $_->does(‘FileMunger’) }
$self->plugins;

for my $plugin (@mungers) {
$plugin->munge_files( @files );
}

we call a method on a bunch of delegates, where the delegates are all of the (undifferentiated) plugins that perform a given rol

$obj->does( $role )

package Some::Class;
use Moose;
with ‘Some::Role’;

LEARN MOOSE

Roles to Make Plugins Go


BeforeBuild


BeforeBuild
FileGatherer


BeforeBuild
FileGatherer
FilePruner


BeforeBuild
FileGatherer
FilePruner
FileMunger


BeforeBuild
FileGatherer
FilePruner
FileMunger
PrereqSource


BeforeBuild
FileGatherer
FilePruner
FileMunger
PrereqSource
MetaProvider


BeforeBuild
FileGatherer
FilePruner
FileMunger
PrereqSource
MetaProvider
AfterBuild


BeforeBuild
FileGatherer
FilePruner
FileMunger
PrereqSource
MetaProvider
AfterBuild

BeforeArchive


BeforeBuild
FileGatherer
FilePruner
FileMunger
PrereqSource
MetaProvider
AfterBuild

BeforeArchive
BeforeRelease


BeforeBuild
FileGatherer
FilePruner
FileMunger
PrereqSource
MetaProvider
AfterBuild

BeforeArchive
BeforeRelease
Releaser


BeforeBuild
FileGatherer
FilePruner
FileMunger
PrereqSource
MetaProvider
AfterBuild

BeforeArchive
BeforeRelease
Releaser
AfterRelease


Let’s write a plugin!


BuiltOn


BuiltOn
package Dist::Zilla::Plugin::BuiltOn;


BuiltOn
use Moose;


BuiltOn
use Moose;
with ‘Dist::Zilla::Role::FileGatherer’;


BuiltOn
use Moose;

sub gather_files {


BuiltOn
use Moose;

sub gather_files {
my ($self) = @_;


BuiltOn
use Moose;

sub gather_files {
my ($self) = @_;
my $file = Dist::Zilla::File::InMemory->new({


BuiltOn
use Moose;

sub gather_files {
my ($self) = @_;
name => ‘built-on.txt’,


BuiltOn
use Moose;

sub gather_files {
my ($self) = @_;
content => scalar `uname -a`,


BuiltOn
use Moose;

sub gather_files {
my ($self) = @_;
});


BuiltOn
use Moose;

sub gather_files {
my ($self) = @_;
});

$self->add_file( $file );


BuiltOn
use Moose;

sub gather_files {
my ($self) = @_;
});

}


BuiltOn

[BuiltOn]


use Moose;

has filename => (
is => ‘ro’,
default => ‘built-on.txt’,
);

sub gather_files {
my ($self) = @_;
name => $self->filename,
});

}


BuiltOn

[BuiltOn]
filename = build-host.txt


Let’s write a another!

(this will talk about plugin ordering)

AddShebangs


...and then just one more...

AddShebangs
package Dist::Zilla::Plugin::AddShebangs;



AddShebangs
use Moose;



AddShebangs
use Moose;
with ‘Dist::Zilla::Role::FileMunger’;



AddShebangs
use Moose;

sub munge_file {



AddShebangs
use Moose;

sub munge_file {
my ($self, $file) = @_;



AddShebangs
use Moose;

sub munge_file {
next unless $file->name =~ /.pl$/;



AddShebangs
use Moose;

sub munge_file {

my $content = “#!$^Xn”



AddShebangs
use Moose;

sub munge_file {

. $file->content;



AddShebangs
use Moose;

sub munge_file {

. $file->content;

$file->content( $content );



AddShebangs
use Moose;

sub munge_file {

. $file->content;

}



AddBlame


AddBlame
package Dist::Zilla::Plugin::AddBlame;


AddBlame
use Moose;


AddBlame
use Moose;

sub munge_file {


AddBlame
use Moose;

sub munge_file {
next unless $file->name =~ /.p[lm]$/;


AddBlame
use Moose;

sub munge_file {

my $content = “# BUILD BY $ENV{USER}n”


AddBlame
use Moose;

sub munge_file {

. $file->content;


AddBlame
use Moose;

sub munge_file {

. $file->content;

}


[GatherDir]
[PruneCruft]


[GatherDir]
[PruneCruft]
[AddShebangs]
[AddBlame]

this is actually a problem

[GatherDir]
[PruneCruft]
[AddShebangs]
[AddBlame]

print “Hello.n”;

If we start with this extremely powerful library ﬁle...

[GatherDir]
[PruneCruft]
[AddShebangs]
[AddBlame]

#!/usr/bin/perl

The shebang gets added, just like we wanted.

[GatherDir]
[PruneCruft]
[AddShebangs]
[AddBlame]
# built by rjbs
#!/usr/bin/perl

then the comment -- meaning the shebang is no good, because it doesn’t start the ﬁle

[GatherDir]
[PruneCruft]
[AddBlame]
[AddShebangs]
#!/usr/bin/perl
# built by rjbs

then the comment -- meaning the shebang is no good, because it doesn’t start the ﬁle

In Conclusion...


Dist::Zilla is..?


Dist::Zilla is:
- judges will accept:
- awesome
- huge
- stupid


We are Friendly
- irc.perl.org #distzilla
- http://dzil.org/
- mailing list
- http://rt.cpan.org/

we will try to answer your questions

Thank you! raaaaaaaaar!


Dist::Zilla: Eliminate Boilerplate for Easier CPAN Authoring

Recomendados

Recomendados

Más contenido relacionado

Similar a Dist::Zilla: Eliminate Boilerplate for Easier CPAN Authoring

Similar a Dist::Zilla: Eliminate Boilerplate for Easier CPAN Authoring (20)

Más de Ricardo Signes

Más de Ricardo Signes (8)

Dist::Zilla: Eliminate Boilerplate for Easier CPAN Authoring