-
Notifications
You must be signed in to change notification settings - Fork 9
Handling Dist::Zilla
Some participants received projects which, if you check their Github repositories, have no Makefile.PL, no Build.PL, meta files (such as META.yml or META.json), or could even have missing tests and missing documentation in the Pod. Instead, those repositories have a dist.ini file. Those are distributions that use Dist::Zilla.
Dist::Zilla is a distribution manager. It uses a configuration file (dist.ini) in order to generate as much as it can for the author, add testing support, and even allow easy releasing of the distribution. While it might take time to get accustomed to dzil (as it is known to its friends), it makes life much easier and that is why many authors choose to use it.
Each dzil configuration is different, but there are a few tips that should be common to all, and I hope these help you contribute to dzil projects with as little headache as possible.
dzil uses plugins for everything. If you open the configuration file you will find a list of plugins, possibly plugin bundles (which is simply a group of plugins), and settings for each of these plugins.
Going over these plugins allows you to understand what dzil does for the release and how it is configured. This helps you avoid raising issues which are actually handled by dzil.
For example, a common plugin is:
[PkgVersion]
PkgVersion creates the $VERSION variable in the Perl modules so the author doesn't have to take care of it. You might have thought about opening an issue for the version variable being missing, but now you know it's actually taken care of by dzil.
Plugin bundles begin with the @ symbol. If you see:
[@Basic]
You now know you need to check the Basic plugin bundle.
Most likely you will be interested in running the tests. While you can usually achieve this with prove -lr t/ in the repository directory (and you still can do this with dzil), some tests are generated by dzil. You can have dzil generate everything necessary and run the tests in fewer characters by running dzil test.
Another way is to ask dzil to build the distribution in a directory and simply leave it there for you to enter, play around with, and run any tests you want. See the next part.
If you're interested in building the distribution, you can simply call dzil build. It will generate both a directory (along with any files it generates as well) and a compressed version of this directory which the author of the distribution could upload to PAUSE.
This is useful if you want to see what dzil generates and try to play with that version. Take into account that changes on generated files (including the altered module files) are useless and you will have to make these changes on the source module files.
dzil also supports various commands which you can install.
cover allows you to run dzil cover in order to provide coverage for the entire distribution. This is better than simply calling cover, because it will generate the distribution and then run the coverage testing on it.
critic allows you to run dzil critic in order to check the generated distribution against Perl::Critic.