Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re: Best way to manage package versions?

by blue_cowdawg (Monsignor)
on Jan 31, 2013 at 18:02 UTC ( #1016369=note: print w/replies, xml ) Need Help??


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.
the left hand expression makes no sense in context with the right hand expression.

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:

sub a { print "letter a"; } sub b { print "letter b"; } sub mother_mary { print "whispers softly"; } 1;
and in a Perl script use:
require Foo; mother_mary(); print " "; b(); print "\n";
When I run the above code I get:
$ perl require.pl whispers softly Letter B
BUT! if I change this to a true module such that:
package Foo; sub a{ print "Letter A"; } sub b{ print "Letter B"; } sub mother_mary { print "whispers softly"; } 1;
something completely different happens:
$ perl require.pl Undefined subroutine &main::mother_mary called at require.pl line 3.
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.

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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1016369]
help
Chatterbox?
[Corion]: Do you want to launch a script and keep the command prompt/console window open?
[Corion]: Do you want to wait for a key press before closing the window?
[LanX]: I want the command line in the history
[tye]: -Mouse
[Corion]: Option a) would mean launching cmd.exe /k c:\path\to\ batchfile- launching-perl- script.cmd. Option b) would be to add pause as the last line of said batch file.
[LanX]: First day after holidays ... and already stressed by the fact that colleagues changed stuff without communication ... apparently I'm the only one trying to fight entropy
[Corion]: LanX: The command is always in the history if you typed it in before. If you didn't type the command into the command line, it will not be there. I think there is doskey which can stuff command lines into the history
LanX damns the cult of CB ;-)
LanX WTF WTF WTF
[LanX]: please forget my last 3 posts

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (13)
As of 2017-03-27 15:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Should Pluto Get Its Planethood Back?



    Results (320 votes). Check out past polls.