Re^2: Professional development with Perl

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: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re^4: Professional development with Perl - how it's done? by adrianh (Chancellor) on May 30, 2006 at 12:05 UTC
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.	[reply]
Re^5: Professional development with Perl - how it's done? by dragonchild (Archbishop) on May 30, 2006 at 14:02 UTC
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: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re^6: Professional development with Perl - how it's done? by adrianh (Chancellor) on Jun 13, 2006 at 12:01 UTC
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).	[reply]
Re^4: Professional development with Perl - how it's done? by techcode (Hermit) on May 30, 2006 at 10:33 UTC
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.	[reply]

In Section Seekers of Perl Wisdom