File Coverage

blib/lib/Dist/Milla.pm
Criterion Covered Total %
statement 6 6 100.0
branch n/a
condition n/a
subroutine 2 2 100.0
pod n/a
total 8 8 100.0


line stmt bran cond sub pod time code
1             package Dist::Milla;
2              
3 1     1   83513 use strict;
  1         10  
  1         27  
4 1     1   439 use version; our $VERSION = version->declare('v1.0.21');
  1         1599  
  1         5  
5              
6             1;
7             __END__
8              
9             =encoding utf-8
10              
11             =head1 NAME
12              
13             Dist::Milla - Distribution builder, Opinionated but Unobtrusive
14              
15             =head1 SYNOPSIS
16              
17             > milla new Dist-Name
18             > cd Dist-Name
19              
20             > milla build
21             > milla release
22              
23             =head1 DESCRIPTION
24              
25             B<Milla is a Dist::Zilla profile>. It is a collection of
26             L<Dist::Zilla> plugin bundle, minting profile and a command line
27             wrapper. It is designed around the "Convention over Configuration"
28             philosophy (Opinionated), and by default doesn't rewrite module files
29             nor requires you to change your workflow at all (Unobtrusive).
30              
31             Experienced CPAN authors who know how to write CPAN distributions can
32             keep writing the code like before, but can remove lots of cruft, then
33             replace L<Module::Install> and L<ShipIt> with L<Dist::Zilla> and Milla
34             profile for authoring, while you don't need to I<add> anything other
35             than a shiny new L<cpanfile> (optional), and a simple C<dist.ini>
36             saying:
37              
38             [@Milla]
39              
40             =head1 CONVENTIONS
41              
42             Milla is opinionated. Milla has a slightly bold assumption and
43             convention like the followings, which are almost compatible to the
44             sister project L<Minilla>.
45              
46             =over 4
47              
48             =item Your module is Pure Perl, and files are stored in C<lib>
49              
50             =item Your executable file is in C<script> directory, if any
51              
52             =item Your dist sharedirs must be in C<share> directory, if any
53              
54             =item Your module is maintained with Git and C<git ls-files> matches with what you will release
55              
56             =item Your module has a static list of prerequisites that can be described in C<cpanfile>
57              
58             =item Your module has a Changes file
59              
60             =back
61              
62             If you have a module that doesn't work with these conventions, no
63             worries. Because Milla is just a Dist::Zilla profile, you can just
64             upgrade to L<Dist::Zilla> and enable/disable plugins that match with
65             what you need.
66              
67             =head1 GETTING STARTED
68              
69             # First time only
70             > cpanm Dist::Milla
71             > milla setup
72              
73             # Make a new distribution
74             > milla new Dist-Name
75             > cd Dist-Name
76              
77             # git is already initialized and files are added for you
78             > git commit -m "initial commit"
79              
80             # Hack your code!
81             > $EDITOR lib/Dist/Name.pm t/dist-name.t cpanfile
82              
83             # (Optional; First time only) Make your build: This will get some boilerplate for git
84             > milla build
85             > git add Build.PL META.json README.md && git commit -m "git stuff"
86              
87             # Done? Test and release it!
88             > $EDITOR Changes
89             > milla build
90             > milla release
91              
92             It's that easy.
93              
94             You already have distributions with L<Module::Install>,
95             L<Module::Build> or L<ShipIt>? Migrating is also trivial. See
96             L<Dist::Milla::Tutorial/MIGRATING> for more details.
97              
98             =head1 WHY
99              
100             =head2 WHY Dist::Zilla
101              
102             A lot of you might have heard of Dist::Zilla (dzil). If you already
103             use it and love it, then you can stop reading this, or even using this
104             module at all.
105              
106             If you heard of dzil and think it's overkill or doesn't work for your
107             module, this is why Milla exists.
108              
109             If you have tried dzil ages ago and thought it was slow, or couldn't
110             find how to configure it to do what you want it to do, Milla will be
111             just for you.
112              
113             First, let me tell you what's the reason to like Dist::Zilla.
114              
115             Dist::Zilla doesn't do the job of installing of your module. So you
116             can focus on the authoring side of things with dzil, while letting
117             MakeMaker or Module::Build(::Tiny) to do the installation side of things. I
118             like this design. David Golden also has written L<an excellent blog
119             post|http://www.dagolden.com/index.php/752/why-im-using-distzilla/>
120             explaining more details about what this means.
121              
122             That said, I myself have avoided switching to Dist::Zilla for a long
123             time. I actually tried a couple of times, but ended up giving up
124             switching to it. You can google for "Hate Dist::Zilla" and will be
125             able to find rants by similarly frustrated developers.
126              
127             In my observation, typical problems/dislikes around Dist::Zilla can be
128             categorized into one of the following thoughts.
129              
130             =over 4
131              
132             =item Dist::Zilla is slow
133              
134             =item Dist::Zilla has too many dependencies
135              
136             =item Dist::Zilla is obtrusive
137              
138             =item Dist::Zilla makes contributing difficult
139              
140             =item Dist::Zilla isn't just worth it
141              
142             =back
143              
144             Let's see how we can address them by using Milla, one at a time.
145              
146             =over 4
147              
148             =item Dist::Zilla is slow
149              
150             Moose, the object system Dist::Zilla uses under the hood, has been
151             improved a lot for the past few years, and your development machine
152             has got a much better CPU and SSD as well. For me personally, with all
153             of Milla plugins loaded, C<milla nop> takes roughly 1.5 second, which
154             I would say is acceptable since I only need to run it at a
155             distribution creation time and release time. More on that later.
156              
157             =item Dist::Zilla has too many dependencies
158              
159             This is true, and Milla doesn't solve that problem, because it I<adds>
160             more dependencies on top of Dist::Zilla.
161              
162             For a quickstart with Milla-like distribution building environment
163             without installing "half of CPAN", see the sister project L<Minilla>.
164              
165             =item Dist::Zilla is obtrusive
166              
167             This was my main motivation for not switching to Dist::Zilla - the
168             thought that using Dist::Zilla would require me to change my workflow.
169              
170             The truth is, Dist::Zilla doesn't I<require> you to change your
171             workflow by itself. But a lot of popular plugins and workflow suggests
172             doing so, by using stuff like PodWeaver, which requires you to switch
173             to Dist::Zilla for everything and then generate the boilerplate, or
174             munge your modules from there.
175              
176             I don't care about the real boilerplate such as C<MANIFEST>,
177             C<META.json> or C<LICENSE> auto-generated, but don't personally like
178             the idea of generating documentation or munging code.
179              
180             I want to edit and maintain all the code and docs myself, and let the
181             authoring tool figure out metadata I<from> there, not the other way
182             round.
183              
184             B<With Milla, you don't need to change your workflow>, and it won't
185             rewrite your C<.pm> files at all. Like Module::Install's C<all_from>,
186             most of the metadata is figured out from your module and git,
187             automatically.
188              
189             =item Dist::Zilla makes contributing difficult
190              
191             This is true for most Dist::Zilla based distributions.
192              
193             Milla copies the plain C<META.json> and C<Build.PL> into the git
194             repository you automatically bump on every release. And there won't be
195             any code munging process required for the release (except bumping
196             C<$VERSION> automatically).
197              
198             This means that the git repository can be installed as a standard CPAN
199             distribution even without L<Dist::Zilla> installed, and collaborators
200             can just hack your modules, run the tests with C<prove -l t> and send
201             a pull request just like a normal module without using dzil at all.
202              
203             B<It's just a releaser who has to install and use Milla>.
204              
205             =item Dist::Zilla isn't just worth it
206              
207             Dist::Zilla has a lot of plugins to search from, and it's so easy for
208             you to spend a few days until you settle with the configuration you
209             need. B<That is exactly why Milla exists>.
210              
211             If you have tried Dist::Zilla before, you might have shared the same
212             experience with me, where the default Basic profile doesn't do
213             much. And when you started wondering or asking what other authors are
214             doing, you would be overwhelmed by the amount of plugins and
215             complexity introduced by the clever workflow.
216              
217             Milla provides a sensible set of defaults that will work for 90% of
218             people, and you don't need to waste time configuring your PluginBundle
219             or searching for the plugin you need.
220              
221             =back
222              
223             =head2 WHY NOT Module::Install
224              
225             I loved Module::Install. I love how it automatically figures out what
226             I want to do with a single C<all_from> line. I liked the cleverness of
227             its bundling itself into C<inc>. But I know many collaborators hated
228             it because you have no idea what plugins have to be installed when you
229             use some funky plugins, and your users are puzzled when they try to
230             install from the git repository because it says C<Can't locate
231             inc/Module/Install.pm>. This problem can be fixed, but I was not
232             interested in doing so.
233              
234             =head1 FAQ
235              
236             =head3 So you basically wrote a simple PluginBundle and some wrapper, and give that a name?
237              
238             Yes. That's the whole point. Think L<Dist::Zilla> as a framework
239             (because it is!) and Milla is a (thin) application built on top of
240             that.
241              
242             =head3 That's so egoistic for you! Why not just Dist::Zilla::PluginBundle::Author::MIYAGAWA?
243              
244             Part of the reason might be my egoism. But think about it - if I
245             switched to Dist::Zilla and recommend everyone to use, I have to say,
246             "Hey, the way I use dzil is kind of cool. You can get that by using my
247             C<@MIYAGAWA> bundle".
248              
249             Wouldn't that be more egoistic than giving it a different name?
250              
251             I wrote my own L<PSGI> implementation, and didn't give it a name
252             PSGI::MIYAGAWA - it's called L<Plack>. I wrote a kick-ass, lightweight
253             CPAN installer, and didn't give it a name CPAN::Installer::MIYAGAWA -
254             it's called L<cpanm>.
255              
256             Because I I<think> this can be recommended for many people, and want
257             to make it better by incorporating contributions, I gave it a
258             different name other than my own personal name bundle.
259              
260             =head3 Dist::Zilla feels overkill. If you don't munge code/docs, what's the point?
261              
262             I agree that it is still overkill. But as of this writing, there's no
263             software other than Dist::Zilla that can correctly create a CPAN style
264             distribution other than L<ExtUtils::MakeMaker> and L<Module::Build>,
265             and I think they're wrong tools for I<authoring> distributions.
266              
267             Check out L<Minilla> if you think Dist::Zilla is overkill and want a
268             lightweight replacement that achieves the same goal but does less.
269              
270             =head3 Milla?
271              
272             As stated above, I've been loving the cleverness of Module::Install (MI),
273             but felt its limitation. Milla is an attempt to put Module::Install's
274             smartness into Dist::Zilla (without the C<inc> mess).
275              
276             M::I + Zilla = Milla.
277              
278             Milla should also remind you of Milla Jovovich, but I couldn't make up
279             any correlation about it, besides Resident Evil is such a great
280             videogame and movie.
281              
282             =head1 AUTHOR
283              
284             Tatsuhiko Miyagawa E<lt>miyagawa@bulknews.netE<gt>
285              
286             =head1 CONTRIBUTORS
287              
288             Ricardo SIGNES wrote L<Dist::Zilla>.
289              
290             David Golden wrote L<Dist::Zilla::PluginBundle::DAGOLDEN>, which I
291             cargo culted a lot of configuration from, for Milla bundle.
292              
293             Tokuhiro Matsuno has beaten me to writing L<Minilla>, which resulted
294             in me going the Dist::Zilla plugin route. L<Minilla> is a sister
295             project, and we try to make them compatible to each other and make it
296             as trivial as possible to switch from/to each other.
297              
298             =head1 COPYRIGHT
299              
300             Copyright 2013- Tatsuhiko Miyagawa
301              
302             =head1 LICENSE
303              
304             This library is free software; you can redistribute it and/or modify
305             it under the same terms as Perl itself.
306              
307             =head1 SEE ALSO
308              
309             L<Dist::Zilla>, L<Minilla>
310              
311             =cut