who cares about dependencies?
I used to worry, now, not so much. Here is my journey to less stress and worry.
Sometimes programmers have to develop applications for production environments that are less than ideal. By less than ideal I mean things like having a Perl version that was End of Life (EOL) December 16 2008, I am looking at you RHEL/CentOS 5.x. Add to that not being able to install CPAN modules or make other changes to the system. The setup I just described is far too common for developers (think shared hosting) and it is frustrating every time you run into it.
One way to solve this problem is to convince the system administrators to install a new system Perl. If that is not feasible App::perlbrew is a great way to have multiple Perl versions with their own CPAN modules. I use perlbrew on my development machine and I have to say it takes the pain out of maintaining multiple Perl versions. Plus it helps me avoid the side effect of breaking the base system when I try to upgrade the default Perl install. I found out about perlbrew from the Task::Kensho recommendation list.
Why not just bundle the dependencies with the application? The first thought I had after thinking that was "I need to check the target operating systems Perl version and what CPAN modules are installed". Then it was "Now I need to package the modules I need into an rpm with the application..." and on and on my thought process went. It made me cringe at all this extra work. Since I am lazy and all that work does not sound appealing I go to metacpan.org to see what is out there.
App::FatPacker is what I found. The synopsis for this module alone shows how sweet and simple it is.
fatpack trace myscript.pl fatpack packlists-for `cat fatpacker.trace` > packlists fatpack tree `cat packlists` (fatpack file; cat myscript.pl) > myscript.packed.pl
I used the above commands on my script file and it just worked. This is great I can now build all kinds of applications and send them to people and not have to worry about their system Perl as much. The one gotcha to fatpacker is that it does not detect runtime require so plan ahead to have local copies of those modules for fatpacker to add in.
I also found Carton which I plan to try out in the future to see what it does different.
I like writing Perl code and since most of it is open source I might as well talk about it too. @KirkKimmel on twitter
Depending on your needs, you may want to take a look at PAR as well. FatPacker can pack all pure-Perl modules just fine. By design, it doesn't do any of these: XS modules, external libraries, perl itself, and additional files (think File::ShareDir, then look at File::ShareDir::PAR).
There's a whole bunch of different tools that are similar to PAR. Most are commercial but not expensive: Cava packager (which has at least a free version, IIRC), and ActiveState's perlapp.
While I'm sold on PAR myself because I maintained it for years, I've heard good things about Cava packager and the author, Mark Dootson, is an all around good and helpful guy.
I am going to give Par and pp a shot right now.
Note that PAR might not be suitable for command-line application which needs to have a fast startup, because at application startup it extracts the bundled modules to the filesystem. This also creates wasted-disk-space problem because the extracted modules cannot be shared with other users (this matters if there are a lot of users on your system).