in reply to Best way to manage package versions?
-
We are using Perl in our project, soon we will have few additional programmers working on a same project.
Today I'm using regular 'require' to get all other .pm files with functions.
Any time there is a team of more than one the following disciplines should be enforced (IMHO):
- Change Control: meaning some form of formal tracking of who is changing what and what the purpose of the change is and an understanding of the impact.
This is crucial in preventing miscommunications both within the team and between the team and stakeholders and aids in the credibility of the team itself. This can be a simple as a spreadsheet to using Trac to something more complex. In some situation pre-qualification and change approval meetings should be held prior to changes being made. These can be as simple as sitting down with a stake holder and validating that the changes you are about to make fit within their needs/desires. - Version Control: This is one area you should not fool around with or minimize.
Pick a system that works for the entire team such as Subversion, GIT, CVS or any of a myriad of solutions out there. Even my own personal programming projects are all subject to version control under Subversion. If nothing else it gives you the luxury of "falling back" to a previous version if things go sideways. - TEST TEST TEST!! Taking the time to write tests for your modules and/or programs (scripts?) will pay you back in dividends later on in terms of fewer bug reports or complaints from your customer community be it external customers or just (!) your boss. Get familiar with the Test::* family of CPAN modules. You'll be glad you did.
I'm not sure what you mean by this:
-
Today I'm using regular 'require' to get all other .pm files with functions.
Now I thinking how we will work with that, if other programmers will edit one of the functions file and make an error , it will crush all program.
Maybe best way to move all code to packages, and use 'use' package function to get functions I need.
If you are writing modules there is one approach, if you are writing (for lack of better word) libraries of functions there is another. To my way of thinking modules are self contained cohesive units that mimic an object oriented system. (whew!) I stop just short of making parallels between Perl modules and C++ (or Java) classes. They are not quite the same although there is some resemblance.
If I create a file "Foo.pm" and put in it:
and in a Perl script use:sub a { print "letter a"; } sub b { print "letter b"; } sub mother_mary { print "whispers softly"; } 1;
When I run the above code I get:require Foo; mother_mary(); print " "; b(); print "\n";
BUT! if I change this to a true module such that:$ perl require.pl whispers softly Letter B
something completely different happens:package Foo; sub a{ print "Letter A"; } sub b{ print "Letter B"; } sub mother_mary { print "whispers softly"; } 1;
something completely different happens. The three subs in "Foo.pm" are no longer in the main context but become part of their own context "Foo". You can get around that by using Exporter and friends and possibly using export tags to group functions together.$ perl require.pl Undefined subroutine &main::mother_mary called at require.pl line 3.
My personal preference though would be to have a code review and figure out what groups of functions should be grouped together as object oriented modules. Maybe you can make your code much more organized and have more effective units for unit testing. Key thought being make your modules as self contained as possible.
Peter L. Berghold -- Unix Professional
Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg