Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re^2: Professional development with Perl - how it's done?

by techcode (Hermit)
on May 29, 2006 at 07:11 UTC ( #552258=note: print w/replies, xml ) Need Help??


in reply to Re: Professional development with Perl - how it's done?
in thread Professional development with Perl - how it's done?

You shouldn't modify modules from CPAN. Otherwise, upgrading removes your changes. If you need to make changes, you should write a wrapper around it. If you can't, you should be working with the author to incorporate your changes back into the mainline.

Not so anymore :D

I don't know for others, but with Subversion it's possible to mix it. You first import some module, then make a brach and change it the way you like. After some time author uploads a new version to CPAN (with hopefuly a patch that you sent to him/her - so there is no need for anything else). You import that as well - and SVN can give you a new version from the author, with your custom code ... How cool is that!?!?

I must admit I haven't tried it yet - but you can find info on that in the SVN book... I think it's under -Vendor Branches-.

If something needs compiling on a machine that doesn't have the tools, then you have a problem no matter what you do. Something on one machine will (almost) never work on another machine, particularly if it's a different OS (like compiling on Linux to work on Windows).

Of course that something compiled for Linux wont work on Windows and the other way around :D I was thinking along the lines of having an older machine with OS that client has (FreeBSD or Linux in 99.99% cases) to compile the code myself ...


Have you tried freelancing? Check out Scriptlance - I work there.
  • Comment on Re^2: Professional development with Perl - how it's done?

Replies are listed 'Best First'.
Re^3: Professional development with Perl - how it's done?
by dragonchild (Archbishop) on May 30, 2006 at 02:50 UTC
    You import that as well - and SVN can give you a new version from the author, with your custom code ...

    You have obviously not used SVN's merging tools. While very nice when they work, they often don't work, requiring a lot of hand-merging. Frankly, it's much better just to use the CPAN shell to install the version you want to install. Most of the time, installing the latest and greatest will be good enough.

    I was thinking along the lines of having an older machine with OS that client has (FreeBSD or Linux in 99.99% cases) to compile the code myself ...

    Assuming you're running the same Perl version. 5.6 and 5.8 are NOT XS-compatible. This means that something compiled against 5.6 will NOT run with 5.8 and vice-versa. 5.10 is rumored to be XS-incompatible with 5.8. The solution you're looking for is a list of prerequisites that you (or the client) install on the client machine. Period. Anything else is asking for more trouble than you want to deal with.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      You have obviously not used SVN's merging tools. While very nice when they work, they often don't work, requiring a lot of hand-merging.

      The wonderful SVK can help a lot there.

      Frankly, it's much better just to use the CPAN shell to install the version you want to install. Most of the time, installing the latest and greatest will be good enough.

      I prefer having my dependencies under source control outside of CPAN. Makes integrating them with the rest of my build much easier, and helps those occasions that aren't "most of the time" become less painful.

        I use SVK - while better than SVN,
        • that's not saying much
        • it still has issues

        Incompatible changes still have to be merged by hand. Some CPAN modules may change a couple lines a release. Then, there's modules like DBM::Deep that will add and remove whole files and those that stay will be significantly changed, even though the API and behavior that you care about hasn't changed at all.


        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re^3: Professional development with Perl - how it's done?
by aufflick (Deacon) on May 30, 2006 at 04:13 UTC
    I really don't think modifying CPAN code is good practise, unless it's to fix a serious bug that you then give back to the author.

    If I really want to modify the behaviour of a CPAN module and it's not reasonable to subclass (or I couldn't be bothered ;) I usually inject my own subs/methods into the namespace from my own code. That way you don't need to carry around modified CPAN modules. And with any luck, minor upgrades to the cpan module won't break your addins (which are hopefully based on documented API anyway).

      I agree - well mostly.

      For instance - I needed to modify one of those modules that takes care of config files. I'm not anymore sure which one it is (nor where it is on my computer - repository should help with organization) - it supports blocks (.ini style). And I needed a list of all the blocks in the config file - but that feature was missing. So I added it ...

      I did send an email to the author, but without response ... guess he didn't wanted to bug with a guy that doesn't know to use diff and submit a patch :D


      Have you tried freelancing? Check out Scriptlance - I work there.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://552258]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (7)
As of 2019-11-12 16:34 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Strict and warnings: which comes first?



    Results (66 votes). Check out past polls.

    Notices?