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 |