How best to "fix" a bug in a standard module?

[kj]

I frequently run into minor bugs in modules downloaded from CPAN.
Aside from the issue of reporting the bug to the modules' maintainers,
there's still the immediate problem of fixing the bug for our own
use.

AFAIC, it is out of the question to replace the installed module
with one I have fixed. Therefore I have settled on just redefining
the buggy sub(s) in the calling code. For example, CGI::Carp::die
does not behave like CORE::die with respect to $@. To correct
this, I have this snippet at the beginning of my CGI script:

BEGIN {
no warnings 'redefine';
my $ccdie = \&CGI::Carp::die;
sub CGI::Carp::die {
@_ = $@ if !@_ and $@;
goto &$ccdie;
}
}

This seems to work fine, but somehow I'm not entirely comfortable
with doing something like this. What pitfalls am I overlooking?
Is there a better approach?

TIA!

kj

 

[anno4000]

I frequently run into minor bugs in modules downloaded from CPAN.
Aside from the issue of reporting the bug to the modules' maintainers,
there's still the immediate problem of fixing the bug for our own
use.

AFAIC, it is out of the question to replace the installed module
with one I have fixed.
Why?

Therefore I have settled on just redefining
the buggy sub(s) in the calling code. For example, CGI::Carp::die
does not behave like CORE::die with respect to $@. To correct
this, I have this snippet at the beginning of my CGI script:

BEGIN {
no warnings 'redefine';
my $ccdie = \&CGI::Carp::die;
sub CGI::Carp::die {
@_ = $@ if !@_ and $@;
goto &$ccdie;
}
}

This seems to work fine, but somehow I'm not entirely comfortable
with doing something like this. What pitfalls am I overlooking?

I don't see any pitfalls. Under normal circumstances your approach
should work.

Is there a better approach?

I think there is. Use your own Perl library (~/lib/perl5/, for
instance), and make it known via $ENV{ PERL5LIB} or "use lib ...".
Then copy the broken module(s) to (an appropriate subdir of) your
lib and fix it there. Then send the author the diff. As they
say, "Patches speak louder than words".

If you want to be an even better member of the open source community,
add tests to the distributions .../t directory that discover the
behavior you have corrected, and also make sure that your fix
doesn't break any of the existing tests.

Anno

 

[xhoster]

I frequently run into minor bugs in modules downloaded from CPAN.

I occasionally find bugs, but more frequently I just have differences of
opinion about things, like when to use carp vs die. Or I want to make
optimizations for either speed or memory that are specific to the way I use
it and not of much general interest.

Aside from the issue of reporting the bug to the modules' maintainers,
there's still the immediate problem of fixing the bug for our own
use.

AFAIC, it is out of the question to replace the installed module
with one I have fixed.

What I frequently do for OO modules is just copy the module to somewhere
else, change the source copy, and then change the "use" statement. (But
not change the class method invocations).

So
use Foo::Bar;
my $b=new Foo::Bar;

becomes:

use FooBar;
my $b=new Foo::Bar;

(After I copy $somelib/Foo/Bar.pm to $mylib/FooBar.pm and modify the
latter, of course.) This can cause problems if other modules you are using
will load the original Foo::Bar themselves.

Therefore I have settled on just redefining
the buggy sub(s) in the calling code. For example, CGI::Carp::die
does not behave like CORE::die with respect to $@. To correct
this, I have this snippet at the beginning of my CGI script:

BEGIN {
no warnings 'redefine';
my $ccdie = \&CGI::Carp::die;
sub CGI::Carp::die {
@_ = $@ if !@_ and $@;
goto &$ccdie;
}
}

This seems to work fine, but somehow I'm not entirely comfortable
with doing something like this. What pitfalls am I overlooking?

If the underlying module gets upgraded, your fix to it may no longer be
compatible. You can confuse people who overlook your redefinition.
Neither pitfall is particularly devastating.

Xho

 

[kj]

Why?

Primarily because among my cow-orkers there are a few whose notions
of what constitute bugs, and whose ability to "fix" them, I don't
trust for a second. If I were to fix a standard module "in place",
as it were, I'd be setting a precedent that'd effectively give
these clowns permission to do the same thing. This is a scary
prospect.

Besides, some other code in our codebase may already expect and
work with the buggy behavior, so the ad-hoc "in place" fixes could
conceivably break this code. Of course, this will happen when the
buggy module gets fixed in a later version, but it looks to me that
letting these fixes correspond to "official" releases of the module
will ultimately result in less cumulative confusion.

kj