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!

on testing

testing is good for your modules. even the ones you know work as intended. case in point: i wanted to refactor curses::toolkit::object::coordinates to use moose.however, refactoring such a core component of curses::toolkit without a test suite did not sound such a good idea...

therefore i wrote some tests for this module - and i discovered 2 bugs in this class. a small one that made an error message totally useless, and a serious one that affected the semantics of some methods.

so, not counting the fact that refactoring was quite easy once the test suite was in place, i also found some real bugs in the code. those tests were not very funny to write, but at least i know that the roi was very good! :-)

tk::action to simplify access to a gui action

in a typical graphical application, menu entries are often also available in toolbars or other widgets. and sometimes, you want to enable or disable a given action, and this means having to update all those entries and widgets everywhere this action is allowed / forbidden.

this is not fun.

therefore, i wrote tk::action, a module to help managing actions in a tk gui: just create a new object, associate some widgets and bindings with add_widget() / add_binding() and then de/activate the whole action at once with enable() or disable().

simple and efficient, as you can see on this synopsis: