Dist::Milla(3pm)

✨ NAME ✨

Dist::Milla — Distribution builder, Opinionated but Unobtrusive 💅

hii bestie, you're reading the Dist::Milla(3pm) page from the User Contributed Perl Documentation set, and honestly? it's a whole vibe. let's get into it 🫶

---

🌸 SYNOPSIS 🌸

> milla new Dist-Name
> cd Dist-Name

> milla build
> milla release

like. that's it. that's the whole thing. iconic 💖

---

🦋 DESCRIPTION 🦋

Milla is a Dist::Zilla profile. no cap. it's a lil bundle of three things: a Dist::Zilla plugin bundle, a minting profile, and a command line wrapper. it's built around the "Convention over Configuration" philosophy — that's the Opinionated part — and by default it does not rewrite your module files, and it does not make you change your workflow at all. that's the Unobtrusive part. slay.

so if you're an experienced CPAN author who already knows how to write CPAN distributions? you can literally keep writing code exactly like before 😌 but you get to delete a whole pile of cruft, and swap out Module::Install and ShipIt for Dist::Zilla plus the Milla profile when you're doing the authoring side. and the way that you don't need to add anything except a shiny new cpanfile (optional, bestie) and a simple dist.ini that just says:

[@Milla]

that's the entire config. no notes. 👑

---

🎀 CONVENTIONS 🎀

okay so Milla is opinionated. it makes a slightly bold assumption, a little set of conventions, and they're almost compatible with its sister project Minilla. here's the list:

• your module is Pure Perl, and files are stored in lib
• your executable file lives in the script directory, if you have one
• your dist sharedirs must be in the share directory, if you have any
• your module is maintained with Git, and git ls-files matches with what you will release
• your module has a static list of prerequisites that can be described in cpanfile
• your module has a Changes file

and if you have a module that doesn't vibe with these conventions? no worries bestie. because Milla is just a Dist::Zilla profile, you can simply upgrade to Dist::Zilla and enable/disable whichever plugins match what you actually need. the door is open 💖

---

🌈 GETTING STARTED 🌈

# First time only
> cpanm Dist::Milla
> milla setup

# Make a new distribution
> milla new Dist-Name
> cd Dist-Name

# git is already initialized and files are added for you
> git commit -m "initial commit"

# Hack your code!
> $EDITOR lib/Dist/Name.pm t/dist-name.t cpanfile

# (Optional; First time only) Make your build: This will get some boilerplate for git
> milla build
> git add Build.PL META.json README.md && git commit -m "git stuff"

# Done? Test and release it!
> $EDITOR Changes
> milla build
> milla release

it's that easy. fr fr. 😭✨

and if you already have distributions built with Module::Install, Module::Build or ShipIt? migrating is also trivial. go peek at "MIGRATING" in Dist::Milla::Tutorial for the full tea.

---

👑 WHY 👑

💜 WHY Dist::Zilla

a lot of you have probably heard of Dist::Zilla (dzil for short). if you already use it and love it? you can stop reading this right now, or honestly just stop using this module entirely. go live your life bestie 🫶

but if you heard of dzil and you think it's overkill, or that it doesn't work for your module — this is why Milla exists.

and if you tried dzil ages ago and thought it was slow, or you couldn't figure out how to configure it to do what you want it to do? Milla is literally just for you. 💅

first, let me tell you what's the reason to like Dist::Zilla.

Dist::Zilla doesn't do the job of installing your module. so you can focus on the authoring side of things with dzil, while letting MakeMaker or Module::Build(::Tiny) handle the installation side of things. I like this design. David Golden also wrote an excellent blog post at http://www.dagolden.com/index.php/752/why-im-using-distzilla/ explaining more details about what this means.

that said, I myself avoided switching to Dist::Zilla for a long time. I actually tried a couple of times, but ended up giving up on switching. you can google for "Hate Dist::Zilla" and you'll find rants by similarly frustrated developers. relatable, honestly. 🙈

in my observation, the typical problems and dislikes around Dist::Zilla fall into one of these categories:

• Dist::Zilla is slow
• Dist::Zilla has too many dependencies
• Dist::Zilla is obtrusive
• Dist::Zilla makes contributing difficult
• Dist::Zilla isn't just worth it

let's see how we can address them by using Milla, one at a time. ⭐

🌸 Dist::Zilla is slow

Moose — the object system Dist::Zilla uses under the hood — has been improved a lot over the past few years, and your development machine has gotten a much better CPU and an SSD as well. for me personally, with all of Milla's plugins loaded, milla nop takes roughly 1.5 second, which I'd say is acceptable since I only need to run it at distribution creation time and release time. more on that later 👀

🦋 Dist::Zilla has too many dependencies

this is true, and Milla doesn't solve that problem, because it adds more dependencies on top of Dist::Zilla. 💀

for a quickstart with a Milla-like distribution building environment that doesn't install "half of CPAN", go check out the sister project Minilla.

🎀 Dist::Zilla is obtrusive

this was my main motivation for not switching to Dist::Zilla — the thought that using Dist::Zilla would require me to change my workflow.

the truth is, Dist::Zilla doesn't require you to change your workflow by itself. but a lot of popular plugins and workflows suggest doing so, by using stuff like PodWeaver, which requires you to switch to Dist::Zilla for everything and then generate the boilerplate, or munge your modules from there.

I don't care about the real boilerplate such as MANIFEST, META.json or LICENSE being auto-generated, but I personally don't like the idea of generating documentation or munging code.

I want to edit and maintain all the code and docs myself, and let the authoring tool figure out metadata from there — not the other way round. periodt.

with Milla, you don't need to change your workflow, and it won't rewrite your .pm files at all. like Module::Install's all_from, most of the metadata is figured out from your module and git, automatically. ✨

💖 Dist::Zilla makes contributing difficult

this is true for most Dist::Zilla based distributions.

Milla copies the plain META.json and Build.PL into the git repository you automatically bump on every release. and there won't be any code munging process required for the release (except bumping $VERSION automatically).

this means the git repository can be installed as a standard CPAN distribution even without Dist::Zilla installed, and collaborators can just hack your modules, run the tests with prove -l t and send a pull request just like a normal module without using dzil at all.

it's just a releaser who has to install and use Milla. everyone else gets to live their best life 😌

⭐ Dist::Zilla isn't just worth it

Dist::Zilla has a lot of plugins to search from, and it's so easy for you to spend a few days until you finally settle on the configuration you need. that is exactly why Milla exists.

if you've tried Dist::Zilla before, you might have shared the same experience as me, where the default Basic profile doesn't do much. and when you started wondering or asking what other authors are doing, you'd be overwhelmed by the amount of plugins and complexity introduced by the clever workflow. 😵‍💫

Milla provides a sensible set of defaults that will work for 90% of people, and you don't need to waste time configuring your PluginBundle or searching for the plugin you need. slay.

💜 WHY NOT Module::Install

I loved Module::Install. I love how it automatically figures out what I want to do with a single all_from line. I liked the cleverness of it bundling itself into inc. but I know many collaborators hated it, because you have no idea what plugins have to be installed when you use some funky plugins, and your users are puzzled when they try to install from the git repository because it says Can't locate inc/Module/Install.pm. this problem can be fixed, but I was not interested in doing so. 🙃

---

🧚 FAQ 🧚

so you basically wrote a simple PluginBundle and some wrapper, and gave that a name?

yes. that's the whole point. think of Dist::Zilla as a framework (because it is!) and Milla is a (thin) application built on top of that.

---

that's so egoistic of you! why not just Dist::Zilla::PluginBundle::Author::MIYAGAWA?

part of the reason might be my egoism. but think about it — if I switched to Dist::Zilla and recommended everyone use it, I'd have to say, "Hey, the way I use dzil is kind of cool. You can get that by using my @MIYAGAWA bundle".

wouldn't that be more egoistic than giving it a different name?

I wrote my own PSGI implementation, and didn't give it the name PSGI::MIYAGAWA — it's called Plack. I wrote a kick-ass, lightweight CPAN installer, and didn't give it the name CPAN::Installer::MIYAGAWA — it's called cpanm.

because I think this can be recommended for many people, and I want to make it better by incorporating contributions, I gave it a different name other than my own personal name bundle. 💅

---

Dist::Zilla feels overkill. If you don't munge code/docs, what's the point?

I agree that it is still overkill. but as of this writing, there's no software other than Dist::Zilla that can correctly create a CPAN style distribution other than ExtUtils::MakeMaker and Module::Build, and I think they're wrong tools for authoring distributions.

check out Minilla if you think Dist::Zilla is overkill and want a lightweight replacement that achieves the same goal but does less.

---

Milla?

as stated above, I've been loving the cleverness of Module::Install (MI), but felt its limitation. Milla is an attempt to put Module::Install's smartness into Dist::Zilla (without the inc mess).

M::I + Zilla = Milla. 🧮✨

Milla should also remind you of Milla Jovovich, but I couldn't make up any correlation about it, besides Resident Evil is such a great videogame and movie. 💀🎮

---

🌟 AUTHOR 🌟

Tatsuhiko Miyagawa <miyagawa@bulknews.net>

---

🫶 CONTRIBUTORS 🫶

Ricardo SIGNES wrote Dist::Zilla.

David Golden wrote Dist::Zilla::PluginBundle::DAGOLDEN, which I cargo culted a lot of configuration from, for the Milla bundle.

Tokuhiro Matsuno has beaten me to writing Minilla, which resulted in me going the Dist::Zilla plugin route. Minilla is a sister project, and we try to make them compatible to each other and make it as trivial as possible to switch from/to each other.

---

💖 COPYRIGHT 💖

Copyright 2013- Tatsuhiko Miyagawa

---

💅 LICENSE 💅

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

---

🎀 SEE ALSO 🎀

• Dist::Zilla
• Minilla

---

and that's the whole page bestie!! 🎉 this was perl v5.42.0, dated 2025-07-25, and you just finished reading Dist::Milla(3pm) — go make a distribution, you absolute icon 👑💖✨