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.

about exporter bug

finally exporter with multiple inheritance bug is explained: class::accessor::fast version 0.34 now does some import magic, and in that case export's import sub is not called. so it's neither perl, nor exporter related.

but still, using multiple inheritance cannot be avoided sometimes...

multiple inheritance - why still using it

ovid reacted to the bug i opened against exporter and multiple inheritance, stating that we cpan authors shouldn't use multiple inheritance, since roles exist.

with all due respect to ovid, this is over-simplifying. cpan holds 15000+ distributions, of which maybe 5% is proposing a role-based api (and i think i'm generous). which means that a lot of the modules available needs you to inherit from them^[0]. so what to do when you want to use those modules? yup, multiple inheritance. i know it's bad - but i don't have the choice, mmk?^[1]

i can already predict ovid's answer: my bug was related to inheriting from both exporter and class::accessor::fast^[2], so i should switch to moose to replace the class::accessor bit. right, i plan to do it later on (patches welcome, too).

but in the meantime, i have a module that worked perfectly under 5.10.0, and that breaks under 5.10.1 (i am still not sure if it's perl or exporter or base/parent related). no need to talk of greypan and compatibility accross major perl releases: i'm talking of backward compatibility of minor perl version for regular cpan module with code available here. and even if it's using sub-standard technology - i am entitled to not expect this kind of breakage.


[0] which is not exactly surprizing, since roles are quite new in perl's oo landscape: 2.5 years according to moose's changelog. if you count some time to let the new feature stabilize, get some needed speed boost and gain acceptance, i don't expect to see a lot of non-role based api soon.

[1] i'm not advocating to use multiple inheritance at all costs. ovid is right: if you can, compose classes with roles. really, he is right on this topic. however, the key words here are if you can.

[2] see how both synopsis request you to inherit from them?