Dist::Zilla - Maximum Overkill for CPAN Distributions

Dist::Zillaraaaaaaaaar!

Tuesday, December 14, 2010

What is Dist::Zilla?

This talk is about your life as a CPAN author.

AWESOME

Any Questions?

also awesome!

I give away almost all my useful software on CPAN

RJBS- cake and pie (and doughnuts)

also awesome!

- cocktails and beer

also awesome!

- shooting zombies

also awesome!

- shooting zombies

- giving away useful software

also awesome!

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 distmaking 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 Makefile.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 Makefile.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 Makefile 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 Makefile.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 files, Pod and all, *for* you so you don’t have to go through this drudgery. Unfortunately, some of these files 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

(files 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

./LICENSE

./Changes

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./lib/YourApp.pm

./t/unit-tests.t

./t/pod-coverage.t

./t/pod.t

./LICENSE

./MANIFEST.SKIP

./Changes

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./lib/YourApp.pm

./t/unit-tests.t

./t/pod-coverage.t

./t/pod.t

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./Changes

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./lib/YourApp.pm

./t/unit-tests.t

./t/pod-coverage.t

./t/pod.t

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./Changes

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./lib/YourApp.pm

./t/unit-tests.t

./t/pod-coverage.t

./t/pod.t

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./lib/YourApp.pm

./Changes

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./lib/YourApp.pm

./t/unit-tests.t

./t/pod-coverage.t

./t/pod.t

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./lib/YourApp.pm

./Changes

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./lib/YourApp.pm

./t/unit-tests.t

./t/pod-coverage.t

./t/pod.t

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./lib/YourApp.pm

./Changes

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./lib/YourApp.pm

./t/unit-tests.t

./t/pod-coverage.t

./t/pod.t

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./lib/YourApp.pm

./Changes

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./lib/YourApp.pm

./t/unit-tests.t

./t/pod-coverage.t

./t/pod.t

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./lib/YourApp.pm

./t/unit-tests.t

./Changes

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./lib/YourApp.pm

./t/unit-tests.t

./t/pod-coverage.t

./t/pod.t

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./lib/YourApp.pm

./t/unit-tests.t

./t/pod-coverage.t

./Changes

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./lib/YourApp.pm

./t/unit-tests.t

./t/pod-coverage.t

./t/pod.t

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./lib/YourApp.pm

./t/unit-tests.t

./t/pod-coverage.t

./t/pod.t

./Changes

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./lib/YourApp.pm

./t/unit-tests.t

./t/pod-coverage.t

./t/pod.t

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

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

./Changes

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./lib/YourApp.pm

./t/unit-tests.t

./t/pod-coverage.t

./t/pod.t

./Changes

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./lib/YourApp.pm

./t/unit-tests.t

./t/pod-coverage.t

./t/pod.t

./Changes

./lib/YourApp.pm

./Changes

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./lib/YourApp.pm

./t/unit-tests.t

./t/pod-coverage.t

./t/pod.t

./Changes

./lib/YourApp.pm

./Changes

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./lib/YourApp.pm

./t/unit-tests.t

./t/pod-coverage.t

./t/pod.t

./Changes

./lib/YourApp.pm

./Changes

./LICENSE

./MANIFEST.SKIP

./Makefile.PL

./README

./lib/YourApp.pm

./t/unit-tests.t

./t/pod-coverage.t

./t/pod.t

./Changes

./lib/YourApp.pm

...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 isAWESOME

...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

- giving away useful software

Dist::Zilla isHUGE

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

- 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 configuration file that sets up your plugins.

dist.ini

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

# How Dist::Zilla builds a dist:

prepare;gather_files;prune_files;munge_files;register_prereqs;setup_installer;write_files;finish;

name = Your-Distlicense = Perl_5copyright_holder = J. Fred Bloggs

[GatherDir]include_dotfiles = 1

[PruneCruft][MetaYAML][MakeMaker][TestRelease][ConfirmRelease]

[UploadToCPAN]user = JFBpassword = 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.

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

here’s a section that defined a plugin, with one option set

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

name = Dist-Zillaauthor = Ricardo SIGNES <rjbs@cpan.org>license = Perl_5copyright_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

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

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

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 test

dzil build

dzil test

dzil install

dzil build

dzil test

dzil install

dzil release

How Dist::Zilla Builds

this is, obviously, a simplification -- but not as great a simplification 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) = @_;

my @files = $self->gather_files;

$self->munge_files( @files );

$self->collect_metadata;

$self->write_out( @files );

$self->write_out( @files );}

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 configuration 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.

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

The Basics

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

MANIFEST

The Basics

MANIFESTMakefile.PL

The Basics

MANIFESTMakefile.PL

LICENSE

The Basics

MANIFESTMakefile.PL

LICENSEREADME

The Basics

MANIFESTMakefile.PL

LICENSEREADME

META.yml

The Basics

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]

Cruft Minimizers

[@Git]

[@Subversion]

[@Mercurial]

[@SVK]

Version Control

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

our $VERSION = 0.001;

=head1 DESCRIPTION

This app is awesome.

=head1 METHODS

=head2 this_method

This method does stuff.

method this_method { ... }

=head2 that_method

Also stuff.

method that_method { ... }

=head1 AUTHOR

Margo Yapp <myapp@example.com>

=head1 LICENSE

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

Here’s a .pm file

package YourApp;

=head1 NAME

=head1 VERSION

version 1.001

=head1 DESCRIPTION

=head1 METHODS

=head2 this_method

=head2 that_method

Also stuff.

=head1 AUTHOR

=head1 LICENSE

Here’s a .pm file

package YourApp;

=head1 NAME

=head1 VERSION

version 1.001

=head1 DESCRIPTION

=head1 METHODS

=head2 this_method

=head2 that_method

Also stuff.

=head1 AUTHOR

=head1 LICENSE

The =name section is annoying.

package YourApp;# ABSTRACT: my awesome app

=head1 VERSION

version 1.001

=head1 DESCRIPTION

=head1 METHODS

=head2 this_method

=head2 that_method

Also stuff.

=head1 AUTHOR

=head1 LICENSE

We’ll replace it with a comment.

=head1 VERSION

version 1.001

=head1 DESCRIPTION

=head1 METHODS

=head2 this_method

=head2 that_method

Also stuff.

=head1 AUTHOR

=head1 LICENSE

The =version section is redundant.

=head1 DESCRIPTION

=head1 METHODS

=head2 this_method

=head2 that_method

Also stuff.

=head1 AUTHOR

=head1 LICENSE

Drop it.

=head1 DESCRIPTION

=head1 METHODS

=head2 this_method

=head2 that_method

Also stuff.

=head1 AUTHOR

=head1 LICENSE

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

=head1 DESCRIPTION

=head1 METHODS

=head2 this_method

=head2 that_method

Also stuff.

=head1 AUTHOR

=head1 LICENSE

our overarching METHOD section is dumb

=head1 DESCRIPTION

=method this_method

=method that_method

Also stuff.

=head1 AUTHOR

=head1 LICENSE

let’s just use =method for them all

=head1 DESCRIPTION

=method this_method

=method that_method

Also stuff.

=head1 AUTHOR

=head1 LICENSE

Repeating the author everywhere is annoying, too.

=head1 DESCRIPTION

=method this_method

=method that_method

Also stuff.

=head1 LICENSE

Drop it, use author info found in DZ config.

=head1 DESCRIPTION

=method this_method

=method that_method

Also stuff.

=head1 LICENSE

The license is gigantic! Ugh!

=head1 DESCRIPTION

=method this_method

=method that_method

Also stuff.

=cut1;

Drop it.

=head1 DESCRIPTION

=method this_method

=method that_method

Also stuff.

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

=head1 DESCRIPTION

=method this_method

=method that_method

Also stuff.

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

- 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 builddzil testdzil installdzil release

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

dzil builddzil testdzil installdzil release

dzil new

dzil new!

the big difference is that the first 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 file 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]

[GatherDir::Template]root = files

[DistINI]

[Git::Init]

How Dist::Zilla Mints

sub mint {

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

$self->make_module( $module );

$self->write_out( @files );

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

[GatherDir::Template]

[DistINI]

[Git::Init]

config.ini

global (per-user) configuration

~/.dzil/config.ini

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

[%Rights]license_class = Perl_5copyright_holder = Ricardo Signes

[%PAUSE]username = RJBSpassword = PeasAreDelicious

these aren’t plugins; global configuration 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

Questions so far?

Writing Plugins!

Writing Plugins is Easy!

Writing Plugins is Easy!(and awesome)

This is what I showed, earlier, as a simplified 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

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

$obj->does( $role )

LEARN MOOSE

Roles to Make Plugins Go

BeforeBuild

BeforeBuildFileGatherer

BeforeBuildFileGathererFilePruner

BeforeBuildFileGathererFilePrunerFileMunger

BeforeBuildFileGathererFilePrunerFileMungerPrereqSource

BeforeBuildFileGathererFilePrunerFileMungerPrereqSourceMetaProvider

BeforeBuildFileGathererFilePrunerFileMungerPrereqSourceMetaProviderAfterBuild

BeforeArchive

BeforeArchiveBeforeRelease

BeforeArchiveBeforeReleaseReleaser

BeforeArchiveBeforeReleaseReleaserAfterRelease

Let’s write a plugin!

BuiltOn

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

BuiltOn

package Dist::Zilla::Plugin::BuiltOn;use Moose;

BuiltOn

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

BuiltOn

sub gather_files {

BuiltOn

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

BuiltOn

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

BuiltOn

sub gather_files { my ($self) = @_; my $file = Dist::Zilla::File::InMemory->new({ name => ‘built-on.txt’,

BuiltOn

sub gather_files { my ($self) = @_; my $file = Dist::Zilla::File::InMemory->new({ name => ‘built-on.txt’, content => scalar `uname -a`,

BuiltOn

sub gather_files { my ($self) = @_; my $file = Dist::Zilla::File::InMemory->new({ name => ‘built-on.txt’, content => scalar `uname -a`, });

BuiltOn

$self->add_file( $file );

BuiltOn

$self->add_file( $file );}

BuiltOn

[BuiltOn]

BuiltOn

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

sub gather_files { my ($self) = @_; my $file = Dist::Zilla::File::InMemory->new({ name => $self->filename, content => scalar `uname -a`, });

$self->add_file( $file );}

[BuiltOn]filename = build-host.txt

BuiltOn

[BuiltOn]

BuiltOn

Let’s write a another!

(this will talk about plugin ordering)

AddShebangs

...and then just one more...

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

AddShebangs

package Dist::Zilla::Plugin::AddShebangs;use Moose;

AddShebangs

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

AddShebangs

sub munge_file {

AddShebangs

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

AddShebangs

sub munge_file { my ($self, $file) = @_; next unless $file->name =~ /\.pl$/;

AddShebangs

my $content = “#!$^X\n”

AddShebangs

my $content = “#!$^X\n” . $file->content;

AddShebangs

$file->content( $content );

AddShebangs

$file->content( $content );}

AddShebangs

AddBlame

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

AddBlame

package Dist::Zilla::Plugin::AddBlame;use Moose;

AddBlame

package Dist::Zilla::Plugin::AddBlame;use Moose;with ‘Dist::Zilla::Role::FileMunger’;

AddBlame

sub munge_file {

AddBlame

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

AddBlame

sub munge_file { my ($self, $file) = @_; next unless $file->name =~ /\.p[lm]$/;

AddBlame

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

AddBlame

my $content = “# BUILD BY $ENV{USER}\n” . $file->content;

AddBlame

$file->content( $content );

AddBlame

$file->content( $content );}

AddBlame

[GatherDir][PruneCruft]

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

this is actually a problem

print “Hello.\n”;

If we start with this extremely powerful library file...

#!/usr/bin/perlprint “Hello.\n”;

The shebang gets added, just like we wanted.

# built by rjbs#!/usr/bin/perlprint “Hello.\n”;

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

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

#!/usr/bin/perl# built by rjbsprint “Hello.\n”;

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

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

Any Questions?

Thank you!raaaaaaaaar!

Dist::Zilla - Maximum Overkill for CPAN Distributions

cpan author

perl module

rjbs cake

peopleused module

main module

useful softwaretuesday

doughnuts cocktails

garbage data

Documents

Carton CPAN dependency manager

Overkill, Issue 12

CPAN Workshop, Chicago 2014

Clone Zilla

Cpan Thesis v1

Insight overkill 2011

Report - Disinfectant Overkill

Road Overkill: Wisconsin Spends Big on Questionable ......

Tunnels & Trolls Solo 7 Overkill

OVERKILL: ISSUE #4

Dist::Zilla - O'Reilly...

Blutgasanalyse, Ultraschall, Antibiotika Overkill ? Dr...

Reviewing CPAN modules

OVERKILL: Issue #2

CPAN-XHE3 size1 - size6

ORANJESPUL FEEST OF OVERKILL?