the great renaming: Dist::Zilla::Plugin::CriticTests

oops! kentnl did it again. :-)

this time, dist::zilla::plugin::critictests has been renamed to dist::zilla::plugin::test::perl::critic. once again, change will be trivial for authors [0]. previous module will continue working, for at least one year counting from today.

github repository has also changed and is available here: https://github.com/jquelin/dist-zilla-plugin-test-perl-critic

[0] and this time, i did not fubar-ed the code! :-|

the great renaming: Dist::Zilla::Plugin::CompileTests

in a move to rationalize the plugin namespace of dist::zilla, kentnl started a  great renaming: dzp:compiletests has been renamed to dzp:test::compile

previous module is deprecated, and may be removed later on (but not before one year, that is 2012-08-27). in the meantime, it will continue working (although with a warning).

what does it mean for dzil users? well, nothing much, since old module will continue working as is. however, they should better migrate their dist.ini from:

[CompileTests]

to:

[Test::Compile]

nothing else is needed... for now, since i guess kentnl will continue proposing patches / pullreqs to dzil:*tests plugin authors! ;-)

also, please note that the github repository has been renamed and is now available at a different url. ditto for cpan, since the dist is now named dist-zilla-plugin-test-compile.

supply your own perlcriticrc to dzil test plugin

if you wanted the ability to supply your own perlcriticrc while using dist-zilla-plugin-critictests, then stephen scaffidi is your hero of the day. indeed, he just implemented this - and i had to do the tedious work of typing "dzil release". oh well, i can say that life is difficult. :-)

github power

i started using github somewhere in 2009 iirc. i was a bit reluctant to use it back at that time, especially because of its speed (or lack of, actually)... and because i already hosted my projects of repo.or.cz.

however, i'm now really glad i started using it. speed is no longer a problem, and it provides really nice features. cia integration, network graphs, comments on commits, watching repos (even if i'm not totally happy with it right now), and of course... pull requests!

i was away this week-end, and found 4 pull requests in my mailbox for my modules when i came back. integrating other's work has never been easier with git and github which allows people to fork at will. that's the new way of writing code: create the basic stub of your module, and wait for others to enhance it! :-) git plugin for dist-zilla now supports pushing to a different branch, supports the new dist-zilla-tester framework and the bundle @git now accepts multi-valued args.

dvcs are a bit harder to grasp at first, but once you understand the concepts, they're really a killer application - especially when coupled with a cooperative platform such as github.

dzil activity

of course, you are aware that dzil v2 is out, with lots of exciting new features, brought to you by rjbs and the perl foundation.

but it's only one side of the activity floating around dist-zilla... indeed, as dagolden, aevar and others try dzil, they (of course) like it, and start contributing their own plugins.

here's a list of new plugins landed on cpan... first some additional author tests:

• CheckChangesTests - check changelog
  
• CheckExtraTests - runs xt/ tests, but don't copy them to t/
  
• DistManifestTests - check manifest
  
• HasVersionTests - check all your modules have a version
  
• KwaliteeTests - check your kwalitee
  
• MinimumVersionTests - check minimum perl version needed
  
• PodSpellingTests - check pod spelling
  
• PortabilityTests - check if your code is portable
  
• SynopsisTests - check if code in your synopsis compiles
  
• UnusedVarsTests - detects unused vars
  
• ReportVersions - additional test to report version
  

some plugins to complete meta-data:

• Bugtracker - http://rt.cpan.org/Public/Dist/Display.html?Name=xxxx
• HomePage - http://search.cpan.org/dist/xxxx
  

some plugins to customize your build process:

• ModuleBuild::Custom - for mb
• OverridableMakeMaker - for eumm

some plugins to generate additional files:

• FatPacker - creates a script with all dependencies packed
• InstallGuide - creates an INSTALL file
• ReadmeMarkdownFromPod - README.mkdn file

some plugins to compute your next version number:

• BumpVersionFromGit - version taken from last git tag
• VersionFromPrev - classic perl versions, 1.00 to 1.99

and finally some bundles:

• @AVAR - ævar arnfjörð bjarmason's take on it
  
• @MARCEL - marcel grünauer
• @PDONELAN - patrick donelan

you can install all of them in one go via task-dist-zilla.

they are also available in mandriva, and suggested when installing dist-zilla...

how to obsolete a cpan dist?

my autoprereq plugin for dist-zilla is now going core. however, it's currently existing as a dist of its own within cpan... since the module does not change name, what is needed to make sure rjbs can upload dzil v2 when it's ready? is giving co-maint rights on pause enough? will i have to remove previous tarballs?

the same kind of question can be asked for obsoleting a given module. there's (afaik) no way to tell cpan / cpanplus that foo::bar is replacing bar::foo... those problems are tackled for linux distribution packages, could we reuse some of their logic here?

activity in git plugin for dist-zilla

it's been a busy week for dist-zilla-plugin-git...

first, there was some test fixes to work with latest dist-zilla (thanks to ricardo), and also to support git 1.7.

the git plugin then saw support for annotated tags which is now the default - but christopher madsen restored the possibility to use lightweight tags. he then refactored commit message generation, in order to allow a custom commit message. not only that, but he also brought to ability to specify which files are allowed to be dirty, and automatically committed.

then david golden jumped in, and scratched his itches: support for empty lines in changelog and possibility to specify which branch(es!) to push to. all of that with new tests - and some existing test fixes! \o/

git support in dist-zilla is now in a pretty good shape. report bugs if you miss your pet-peeve... or even better: fork the code and send me pull requests once the code is doing what you want!

announcing git plugin for dist-zilla

pushing lazyness even further, i released a git plugin for dist-zilla. in fact, there are 4 plugins within the distribution. they are kicking in during dzil release, since i've hacked dzil to provide beforerelease and afterrelease roles.

dzp:git:check - this plugin checks that git is in a clean state before releasing. the following checks are performed before releasing:

• there should be no files in the index (staged copy)
• there should be no untracked files in the working copy
• the working copy should be clean. the changelog and dist.ini can be modified locally, though.

if those conditions are not met, the plugin will die, and the release will thus be aborted. this lets you fix the problems before continuing.

dzp:git:commit - once the release is done, this plugin will commit in git if needed changelog and dist.ini (which is a valid target if you happen to set the version manually in it). the commit message will be taken from the changelog for this release.

dzp:git:tag - once the release is done, this plugin will record this fact in git by creating a tag named v$VERSION.

dzp:git:push - once the release is done, this plugin will push current git branch to remote end, with the associated tags.

if you want to use all those neat plugins, you may want to use the git plugin bundle by writing in your dist.ini:

[@Git]

there, one more thing that dzil is doing for me... no more time lost doing those tedious steps - if you're lazy, you should really try it! as usual, comments and feature requests are welcome.

right trimming for dzil autoprereq plugin

autoprereq plugin for dzil used to trim all modules under the dist namespace from the list of prereqs. eg, for dist-zilla dist, it would trim all dist::zilla::* modules.

although good for a first try, it had two problems:

• modules outside of your dist can be trimmed. eg, audio::mpd is requiring some audio::mpd::common modules which are outside of audio-mpd dist.
• if your dist is shipping 2 namespaces, only the modules inside the first namespace are trimmed, and you can end up with a dist with circular deps.
  

the first one is easy to solve with a fixed [Prereq] section in your dist.ini (this is what i've done for audio-mpd). and the second is not really common, so i thought that i could leave dzpa as is...

but dams now uses dzil for the excellent curses-toolkit - which ships curses::toolkit::* and poe::component::curses::* modules. so he complained (rightly) and i had to fix autoprereq plugin.

so, dzpa will only trim modules that are part of the dist, instead of blindly removing the modules under the dist namespace. and this only change fixes at once the 2 problems outlined above. where dzpa used to trim too much and not enough, it now trims just what it has to...

dist-zilla: compile tests can skip some modules

the compilation test plugin for dist-zilla now accepts a parameter to skip some modules. this can be handy to prevent testing some known-to-fail modules - yes, this can happen if your module does stuff assuming a given environment not currently in place (eg: test modules...).

just use the following in your dist.ini file:

[CompileTests]
skip = Test$

the skip parameter is interpreted as a regex, matched against the module name (not the file name of the module). in this example, all modules with a name ending with Test will not be tested for compilation.

external event loops no more part of poe

for those (such as me) that did not spotted it, external event loops for poe are now released as their own distribution. this means they aren't part of the poe distribution anymore, and you should add them to your prereqs...

of course, there's no way that dzil's autoprereq plugin could extract poe::loop::tk from code such as:


so, i had to use the regular prereq plugin to list it as a manual dependency. since dzil is using moose roles, it means more than one plugin can provide the prereqs, so i can continue using autoprereq beside this exception - woohoo!

in conclusion, games::pandemic 1.092660 is on its way, fixing a problem reported by a cpantester (thank you guys - you rock!)

more dzil goodness

i'm happy to announce yet another plugin for dist-zilla: critictests.

in your dist.ini, just add:

[CriticTests]

and dist-zilla will automatically create for you an xt/author/critic.t file that will criticize your code during author tests.

of course, since your code will be munged by dist-zilla, code that passes critics in your repo may fail after being rewritten... case in point: stricture use, since dist-zilla-plugin-pkgversion will insert a version just after the package statement - and thus before any use statements. in order to make your code compliant again, just move the use strict / warnings before the package. indeed, use is lexically scoped, and thus the scope of the use statement will be the whole file.

your code will now look like:

use strict;
use warnings;
package Foo::Bar;

and of course, perlcritic this time will now be happy.

shipping compile tests with dist-zilla

perl community places some emphasis on testing. which is great, since it enhances the overall quality of perl ecosystem.

the first, easiest test that one should provide is basic: making sure the modules compile. we have 2 options here:

• either create a test and add some use_ok('Foo::Bar'). but we then need to update it whenever we add more modules to our distribution - without forgetting to update test count.
• or, to get rid of this burden, ship a test that automatically finds the module and tries to compile them.

but shipping the exact same generic test is boring, and could be automated. which is now the case for dist::zilla with the new module dist::zilla::plugin::compiletests. just add the following in your dist.ini file:

[CompileTests]

and you will get a brand new t/00-compile.t that will test your modules and your scripts one by one. this my take some time if your dist ships a lot of modules having lots of prereqs, especially if they are a bit slow to compile such as Moose. but this will potentially find more compile errors in your modules.

more moose support in dzp:autoprereq

dist::zilla::plugin::autoprereq just gained more moose support: it can now extract the base module declared with:

extends 'Foo::Bar';

it's not perfect since it only extracts the first base class, but i think it will cover 90+% of the cases out there.

autoprereq plugin for dist-zilla gets smarter

i just released dist::zilla::plugin::autoprereq 0.2.0 which now extracts prereqs from moose roles declared with the with keyword ^[0]. also new in this release is the support for skip list, allowing to trim unwanted prereqs.


[0] why, yes, i got some failures for games::pandemic 0.5.0 due to a missing prereq... defined in a role, you guessed it. :-)

even more lazyness with dist::zilla::plugin::autoprereq

who never forgot to list a prereq in their makefile.pl / build.pl / whatever? it happens to me on a regular basis.

now that i started using dist::zilla, prereqs are not listed in a build script, but in dist zilla configuration file. but the problem is the same: prereqs are listed manually. and doing stuff manually sucks.

i had to do something. so i used dist-zilla's plugin infrastructure and just uploaded dist::zilla::plugin::autoprereq. just add:

[AutoPrereq]

in your dist.ini, and it will automatically find your prereqs for dist::zilla to use.

the parsing is somehow very rough: it will just find the lines beginning by use or require. for more advanced / hackish stuff, dist::zilla::plugin::prereq is still available. i still think that it should cover 80+% of the cases. i considered using module::info, but it evals the modules to find the prereqs and the result is damn slow... and speed was more important imo.

note that i plan to add the possibility to add modules manually, in order to add missing modules (or maybe we can use both prereq and autoprereq?), and a skip option to trim modules that should not be added to the list of prereqs.

also, i may change the algorithm used to find prereqs: maybe ppi will be fast enough? we'll see.

but in the meantime, just enjoy not writing anymore those prereqs by hand! :-)

prepender distzilla plugin can add boilerplate copyright

following autarch's advice on yesterday's post, i just uploaded dist-zilla-plugin-prepender 0.2.0 that accepts a copyright option to automatically add a boilerplate copyright at the top of the files.

yet another things that ease an author's life.

i'm still unsure with the strict and warnings options. not because of the test argument, but because of the editing argument. indeed, with padre (the perl ide) doing live syntax check, i want the syntax check to be done with all due stricture...

new distzilla plugin: prepender

when i first heard of dist::zilla, its concepts definitely appealed to me. it took me quite some time (never the good time, plus i needed to create the rpms for mandriva), but i finally managed to try it...

and although i still need to get used to it, i'm already really happy with it. on the new project that i recently started (more on that later on), i'm letting dist::zilla deal with all those pesky copyright, version, pod, etc. stuff.

however, i'm used to add some boilerplate at the top of my files, as the fsf recommends. and i found nothing in dist::zilla to do that... so i just wrote a new plugin for it: dist::zilla::plugin::prepender.

just add the following in your dist.ini file:

[Prepender]
line = #
line = # This file is part of Foo::Bar
line = #
line = # Foo::Bar is copyright...

but it can also be used to enforce some common pragma: since it will be inserted at the top of the file, the pragma will be applied to its lexical scope - the whole file itself in this case:

[Prepender]
line = use strict;
line = use warnings;

since those usages are quite common, i might as well in a future version propose them as options:

[Prepender]
copyright = 1
strict    = 1
warnings  = 1

but i'm not really sure... wdyt?

autoformat and nopaste plugins join padre's nest

after much hesitation, i finally decided to migrate the autoformat and nopaste plugins to padre's svn repository.

not that i prefer svn - after all, i used git for a reason when i started those plugins - but it's handy to benefit of padre's translators for my plugins for free... (btw, if your language is not supported, you're more than welcome to join padre's development team!)

but the nice thing is that gabor told me that if padre gets a good enough git plugin for padre, he will switch padre's repository to git!

good enough here means that even people unfamiliar with git can use it, whatever the platform (yup, windows, i'm staring at you)... and btw, do you remember that there's an on-going contest for best padre plugin?

so what are you waiting for?

best plugin for padre contest

for those of you that missed it, i remind you that you have one month to come up with the best plugin for padre...

take this chance to discover padre, and see how easy it is to work with/on it! what are you waiting for?