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...

migration to moose - step 2

another module converted to moose (and dist-zilla): audio::mpd. migrating the attributes is quite easy, but this time the constructor migration was a bit trickier to do. fortunately, moose lazy building proved handy.

since the module is quite stable by now, i bumped version to 1.x (1.yyyddn even).

one more module with a simplified code-base... next migration will be pococm, and should prove more difficult, but for even more reward (thanks to moosex::poe).

test::corpus::* namespace

both audio::mpd and poe::component::client::mpd share the same files for their regression test suite. this includes some boring ogg files - weighing around 150 kb. although not that much, those files are duplicated between those 2 modules.

moreover, it means that everytime i upload a fix for one of those modules, i'm taking some more space on cpan for those exact same files - they never ever change...

something had to be done. i therefore wanted to split this raw test data, and put it in a module of its own. the other 2 modules would then get rid of the test data, and require the new one during the tests.

the question was of course how to name this module. i asked module-authors for advices, and david nicol proposed the test::corpus::* namespace.

since the idea is quite sound, i then released test::corpus::audio::mpd with the data (with some fixes to bring it up to mpd 0.15.x). audio::mpd has already been migrated to use this. i still need to do it for pococm, though.

anyway, this post is merely about the announce of the test::corpus:: namespace, to hold your test data instead of putting them in your dists. let us know what you think of it.

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.

migration to moose - step 1

as promised, i just migrated audio::mpd::common to use moose. and since i was at it, i also took the opportunity to migrate to dist::zilla!

conclusion: it takes some time to migrate (around half a day?) - and this is a very small dist! maybe i should have not mixed moose and dzil migration... but the resulting code is also easier to read, and better documented now, so it's not a one to one migration.

anyway, i'll continue migrating the mpd related modules to moose, dist-zilla as i find the tuits.

mandriva 2010 coming - which perl modules do you miss?

mandriva's next version (2010.0) is now in version freeze, for a release date in early november. this means that current packages are not allowed to be upgraded to latest version, unless there's a compelling reason to do so (security update, crash or big regression).

there is still, however, the possibility to ship new packages. so if you miss some perl modules in mandriva and you really want them available as rpm packages in 2010.0 version, now is the time to speak up! just add your request as comment to this post, and i'll do my best to fulfill it.