Caleb Cushing's Blog Also known as XenoTerraCide
Posts with the tag Dist::Zilla:

Experience with having a non Dist::Zilla user contribute to a Dist::Zilla project (it's not hard for them or me)

I’ve heard many times that Dist::Zillamakes it harder for people to contribute to the project. This is not true, it is either unfortunately either ignorance or FUD (much like saying Linux is harder to use than Windows). Truly, there are things that some dzil users do that canmake it harder, but it doesn’t have to be that way. Michael Schwern recently contributed to one of my dzil projects without ever realizing I was using dzil, until I told him.

My solution to not using PluginBundle:AUTHOR for dzil is git

I am now tired of updating my dist.ini’s for my Dist::Zillaprojects. For many people this is when they start using a PluginBundle with their authorname. I discussed why you shouldn’t do this a year ago. Now that I’m tired of managing my dist.ini’s on an individual basis I’m going to show you how I’m going to solve the same problem everyone else is, which is getting tired of updating your dzil configuration for all of your projects.

Writing a simple Dist::Zilla::Tester test

Hopefully, someone will use the blog post to write an actual doc patch, seeing as how this is undocumented. I finally wrote A test for DZP::OurPkgVersion with the help of CJM. So I figure it’s best to share the knowledge imparted upon me to all those who are writing plugins without tests. Before we get started I’m going to advise that this test will only check the output that dzil built, if you need it to test anything more sophisticated, you’ll have to learn more.

Creating new projects with dzil new and templates

Here I talked about creating a new catalyst project using a minting profile for Dist::Zilla. If you don’t know how to create a minting profile read that first. I’m sure once you’ve tried that you’ll agree that having a little bit more than the basics in a newly minted dist would be a good thing. first we need to create our profile.ini correctly 1 2 3 [GatherDir::Template] root = repo include_dotfiles = 1 (note: if you’ve got [DistINI] plugin loaded you’ll probably want to remove it) Now you can put any file in the subdirectory repo of your profile (if you leave out include_dotfiles = 1 then anything beginning with a .

Announcing Dist::Zilla::Plugin::Catalyst

So I just recently finished reading Restful Web Services and decided I wanted to go back and play with Catalyst and REST some. The original way to create a Catalyst skeleton is to run catalyst.pl. This creates a lot of nice files to get you started. dzil new basically does the same thing for a generic cpan module. Honestly, without any plugins dzil new isn’t that useful. However, once you add Git::Init , you remove several steps from the creation of a new module and repository.

Solving code generation problems in dzil

Firstly I want to clarify a bit on my opinions of PluginBundle::USERNAME modules, as some comments there have inspired this post. I don’t think you should use them because it makes it harder to disableplugins, and I think Robin Smidsrød put it best: Mostly it is because the Dist::Zilla::PluginBundle::USERNAME doesn’t actually say anything about its intention. It only says use Dist::Zilla as this person does, but what does that actually mean?

please don't use Dist::Zilla::PluginBundle::USERNAME

or create them. Here’s the problem…. (short version is Don’t put PodSpellingTests in them)normally you’d have[pluginA][pluginB][pluginC][pluginXTests][pluginYTests][pluginZTests]and one of them doesn’t work on your system (for whatever reason), well you can just do this.[pluginA][pluginB][pluginC];[pluginXTests][pluginYTests][pluginZTests]the ;is a comment in ini, now dzil won’t use that plugin. But people will say well you don’t want to do that of course I want that plugin enabled. Here’s why you may not temporarily. Casual user X has a bug in /your/ module that’s using dzil, they code up a patch, and they want to run your test suite.

Dist::Zilla vs xenoterracide

Yes, I am invincible! I solved my problemwith Dist::Zilla. If you agree with me that you should be able to install from your git repository, without requiring your users to have Dist::Zilla installed here’s one way of doing it.First install Dist::Zilla::Plugin::CopyTo. Now Edit your dist.ini. Most people probably use one of the Dist::Zilla bundles. Assuming you use Basic here’s what you do.; remove GatherDir from basic so we can specify it seperately[@Filter]bundle = @Basicremove = GatherDir; specify the where your ungenerated source lives[GatherDir]root = src; specify where you want the generated source to live[CopyTo]dir = .

My new Love/Hate Relationship with Dist::Zilla

Dist::Zillais a great release tool, code generator, and it just plain takes the boring part of doing a release away from you.That having been said, it does, imo, horrible things to your source repository. “But, Caleb, it cleans up your source repository you can remove a lot of excess stuff you don’t really need to be storing there”. Well… I disagree, to the point that I’ve used every explicative in the book to express my displeasure.