http://qs321.pair.com?node_id=780716

jrsimmon has asked for the wisdom of the Perl Monks concerning the following question:

My current project has led me to customize a couple of cpan modules. Now that I've found and changed/fixed the modules to suit my purposes, I've realized I need to do something to prevent future versions of the module from breaking me (I do plan to submit my changes to the module author, once they've been cleaned up a bit).

My only idea so far is to copy the modules in question and create a new package using them. I'm not so sure this is a good idea, though...I wonder if I'd run into conflicts with other modules including the 'real' versions of my edited modules, etc.

So, is there an established method for including user-specific modules rather than modules from the /lib or /site/lib paths? How do you go about tracking/protecting changes you've made to modules installed from cpan?

Replies are listed 'Best First'.
Re: Customizing cpan modules
by moritz (Cardinal) on Jul 16, 2009 at 14:23 UTC
[reply]
Re: Customizing cpan modules
by Ovid (Cardinal) on Jul 16, 2009 at 15:18 UTC

    In addition to the comments of moritz, I would also recommend you create a t/prerequisites.t test which asserts the version numbers of modules you depend on. That way, if something gets upgraded (or downgraded), you can have a test failure. This is of particular importance for local patches.

    Cheers,
    Ovid

    The official Perl 6 wiki.

[reply]
Re: Customizing cpan modules
by brian_d_foy (Abbot) on Jul 17, 2009 at 00:43 UTC
    Set up your own CPAN mirror with exactly the modules you want. Only pull from there. Update only what you want. That's what my DPAN work is all about.
    --
    brian d foy <brian@stonehenge.com>
    Subscribe to The Perl Review
[reply]
Re: Customizing cpan modules
by shawnhcorey (Friar) on Jul 16, 2009 at 19:06 UTC
    I don't know if there is an official way of doing this but you can keep your modifications in your own files without changing those you got from CPAN. 
    use FindBin qw/ $Bin /;
use lib $Bin;

use CPAN::Module;
use MyPatches::CPAN::Module; # must comes second

    [download]
    If you have warnings turned on, you will be notified when a second sub replaces the first.
[reply]
[d/l]
Re: Customizing cpan modules
by pileofrogs (Priest) on Jul 17, 2009 at 04:22 UTC

    What about forking your own module? Instead of making a 2nd Foo::Bar, make Foo::Bar::Mine or whatever. If you're worried about missing important patches to the original, write your code to load the original and change the bahavior. If the original is object oriented, then you subclass and override, if not I think you call it monkey-patching, but it works basically the same. You can also make patches from the current original module and your altered version and the apply the patches to any new version of the original.

    --Pileofrogs

[reply]
      Second this -- or even just making your replacements into local functions if the changes are simple enough?
[reply]
Re: Customizing cpan modules
by leocharre (Priest) on Jul 17, 2009 at 15:02 UTC
    Submit your suggestions, fixes, updates, additions, etc. Have you tried doing that?

    If your changes are so specific to your purposes that they might not be of any use to others, simply place The::Original::Module into namespace YourName::The::Original::Module

    And use that module instead. I understand hacking Standard::Module::Used::Everywhere to do what you want it to, this is sh1++y practice. Bad practice. Bad.

[reply]

      All of our local patches are required to have the URL of the bug report attached to it. This allows future developers to come along and easily see the history, including whether or not the situation was resolved and if we can delete our local patch.

      The end result of this has been several ignored bug reports, including one in which two module authors seem to feel that since their modules don't play well together, the fault likes with the other author. Regrettably, sometimes a fork is required :(

      Cheers,
      Ovid

      The official Perl 6 wiki.

[reply]

      One of the changes is what I believe to be a bug, described here. The other may or may not be a bug, depending on what the original author intended. I intend to submit both of the changes, but I'd like to do so after cleaning them up and having some run-time on them.

      In the mean time, I'm curious as to the best way to make changes to the modules in a way that doesn't lead to horribly disfigured /lib and /site/lib directories. All of the posts in the thread have been extremely helpful.

[reply]

Back to Seekers of Perl Wisdom