Perl patching experiences part 1
Recently I looked at submitting code fixes and posted a quick guide. Since that post I managed to find and fix a bug in Params::Util, submitting the appropriate patch. Adam Kennedy (the maintainer of the module) took it further to write the appropriate unit tests to make sure the problem never came about again.
This has made me realize that patches can be more than just code and typo fixes. An ideal patch would include code fix, unit tests for the problem and possibly documentation updates. It could even be code replacement, or alternative versions.
Recently I looked at submitting code fixes and posted a quick guide. Since that post I managed to find and fix a bug in Params::Util, submitting the appropriate patch. Adam Kennedy (the maintainer of the module) took it further to write the appropriate unit tests to make sure the problem never came about again.
This has made me realize that patches can be more than just code and typo fixes. An ideal patch would include code fix, unit tests for the problem and possibly documentation updates. It could even be code replacement, or alternative versions.
I created a patch for Data::FormValidator that provided some Pure Perl
alternatives if XS based modules are not available on a system (yet to
be implemented). You could in turn submit faster XS alternatives to
Pure Perl code.
My latest plugin for CGI::Application is an email module which currently isn't much more than a wrapper around Email::Stuff. When choosing it 2 things put me off. One was the promblem with Pure Perl Params::Util which is now fixed. The other was that is uses Clone which is an XS only module. Upon further inspection, Clone is loaded, but ever actually used. I guess this was a feature Adam was planning but didn't implement. I asked him about it and he said it wouldn't be an issue to remove Clone.
It's been a couple of weeks and the Email::Stuff on CPAN still declares Clone as a dependency. So my CGI::Application::Plugin::Email module currently looks like it doesn't have a Pure Perl option (which is the aim for all of my CGI::Application modules).
I know Adam runs a lot of projects and is very busy. Given his very fast responce to fixing Params::Util when I submitted a patch. My current thinking is that I can give him a worthwhile update to Email::Stuff (more than just a removal of "use Clone;") then it'll be worth updating the CPAN version.
Taking a look at the RT, there is a bug that has been in there for over a year. I'm hoping if I fix this then I'll be able to also fit in the Clone removal.
Results to follow ;)
Lyle
My latest plugin for CGI::Application is an email module which currently isn't much more than a wrapper around Email::Stuff. When choosing it 2 things put me off. One was the promblem with Pure Perl Params::Util which is now fixed. The other was that is uses Clone which is an XS only module. Upon further inspection, Clone is loaded, but ever actually used. I guess this was a feature Adam was planning but didn't implement. I asked him about it and he said it wouldn't be an issue to remove Clone.
It's been a couple of weeks and the Email::Stuff on CPAN still declares Clone as a dependency. So my CGI::Application::Plugin::Email module currently looks like it doesn't have a Pure Perl option (which is the aim for all of my CGI::Application modules).
I know Adam runs a lot of projects and is very busy. Given his very fast responce to fixing Params::Util when I submitted a patch. My current thinking is that I can give him a worthwhile update to Email::Stuff (more than just a removal of "use Clone;") then it'll be worth updating the CPAN version.
Taking a look at the RT, there is a bug that has been in there for over a year. I'm hoping if I fix this then I'll be able to also fit in the Clone removal.
Results to follow ;)
Lyle
Leave a comment