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?


RJBS


ME!!!

also awesome!

I give away almost all my useful software on CPAN

RJBS- cake and pie (and doughnuts)


ME!!!

also awesome!



- cocktails and beer


ME!!!

also awesome!




- shooting zombies


ME!!!

also awesome!




- 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 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 <[email protected]>’, 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 <[email protected]>’, 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




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




- 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





- 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 <[email protected]>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 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

=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 <[email protected]>

=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 youwill be “accidentally” deathed or dismembered. You have been told.

=cut

1;


Here’s a .pm file

package YourApp;

=head1 NAME


=head1 VERSION

version 1.001

=cut


=head1 DESCRIPTION


=head1 METHODS

=head2 this_method


=cut


=head2 that_method

Also stuff.

=cut


=head1 AUTHOR


=head1 LICENSE



=cut

1;


Here’s a .pm file

package YourApp;

=head1 NAME


=head1 VERSION

version 1.001

=cut


=head1 DESCRIPTION


=head1 METHODS

=head2 this_method


=cut


=head2 that_method

Also stuff.

=cut


=head1 AUTHOR


=head1 LICENSE



=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



=cut

1;


We’ll replace it with a comment.


=head1 VERSION

version 1.001

=cut


=head1 DESCRIPTION


=head1 METHODS

=head2 this_method


=cut


=head2 that_method

Also stuff.

=cut


=head1 AUTHOR


=head1 LICENSE



=cut

1;


The =version section is redundant.



=head1 DESCRIPTION


=head1 METHODS

=head2 this_method


=cut


=head2 that_method

Also stuff.

=cut


=head1 AUTHOR


=head1 LICENSE



=cut

1;


Drop it.



=head1 DESCRIPTION


=head1 METHODS

=head2 this_method


=cut


=head2 that_method

Also stuff.

=cut


=head1 AUTHOR


=head1 LICENSE



=cut

1;


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


=head1 DESCRIPTION


=head1 METHODS

=head2 this_method


=cut


=head2 that_method

Also stuff.

=cut


=head1 AUTHOR


=head1 LICENSE



=cut

1;


our overarching METHOD section is dumb


=head1 DESCRIPTION


=method this_method


=cut


=method that_method

Also stuff.

=cut


=head1 AUTHOR


=head1 LICENSE



=cut

1;


let’s just use =method for them all


=head1 DESCRIPTION


=method this_method


=cut


=method that_method

Also stuff.

=cut


=head1 AUTHOR


=head1 LICENSE



=cut

1;


Repeating the author everywhere is annoying, too.


=head1 DESCRIPTION


=method this_method


=cut


=method that_method

Also stuff.

=cut


=head1 LICENSE



=cut

1;


Drop it, use author info found in DZ config.


=head1 DESCRIPTION


=method this_method


=cut


=method that_method

Also stuff.


=head1 LICENSE



=cut

1;


The license is gigantic! Ugh!


=head1 DESCRIPTION


=method this_method


=cut


=method that_method

Also stuff.

=cut


=cut1;


Drop it.


=head1 DESCRIPTION


=method this_method


=cut


=method that_method

Also stuff.

=cut


1;


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


=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 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]




[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]




[DistINI]

[Git::Init]



config.ini


global (per-user) configuration

~/.dzil/config.ini


[%User]name = Ricardo Signesemail = [email protected]

[%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 ùname -a`,

BuiltOn



sub gather_files { my ($self) = @_; my $file = Dist::Zilla::File::InMemory->new({ name => ‘built-on.txt’, content => scalar ùname -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 ùname -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!


Documents

Dist::Zilla - Maximum Overkill for CPAN Distributions