In Item 110: Compile and install your own perls, you saw how to install multiple versions of
perl and to maintain each of the installations separately. Doing something with one version of Perl doesn’t affect any of the other versions.
You can take that a step further. Within each installation, you can use a source control system to manage your Perl modules. In this post you’ll use git, which has the advantage that you don’t need a server.
First, install your
perl into its own directory:
% ./Configure -des -Dprefix=/usr/local/perls/perl-5.10.1 % make test % make install
Second, before you do anything else with your newly installed
perl, put your new directory into source control:
% cd /usr/local/perls/perl-5.10.1 % git init % git add . % git commit -a -m "Initial installation of Perl 5.10.1"
You’re not quite done there, though. You’re on the master branch:
% git branch * master
You want to keep at least one pristine branch that is the initial state of your
perl installation. You can always come back to it:
% git checkout -b pristine Switched to a new branch 'pristine'
Leave that branch alone and switch back to master:
% git checkout master Switched to branch 'master'
From here you can do many things, but you probably want to consider the
master branch your “stable” branch. You don’t want to commit anything to that branch until you know it works. When you install new modules, use a different branch until you know you want to keep them:
% git checkout -b unstable Switched to a new branch 'unstable' % cpan LWP::Simple % git add . % git commit -a -m "* Installed LWP::Simple"
After using your newly installed modules for awhile and deciding that it’s stable, merge your
master. Once merged, switch back to the
unstable branch to repeat the process:
% git checkout master Switched to a new branch 'master' % git merge unstable % git checkout unstable
Anytime that you want to start working with a clean installation, you start at the
pristine branch and make a new branch from there:
% git checkout pristine % git checkout -b newbranch
If you aren’t tracking your
perl in source control already, just tracking a
unstable branch can give you an immediate benefit. However, you can take this idea a step further.
With just one
perl installation, you can create multiple branches to try out different module installations. Instead of merging these branches, you keep them separate. When you want to test your application with a certain set of modules, you merely switch to that branch and run your tests. When you want to test against a different set, change branches again. That can be quite a bit simpler than managing multiple directories that you have to constantly add or remove from
2 thoughts on “Manage your Perl modules with git”
Another excellent article. Thanks!
I find this easier to do in my $HOME directory – no need to be nervous … even (or especially) after a few perlbrews :-)
To be ornery I sometimes do this *purposefully* without git :grin: and use http://fossil-scm.org/ instead.
Come here from time to time to think about this approach, but how common is it really?
Since the article has been written, we now have Docker, Snap, FlatPack and stuff, which go in a similar direction, encapsulate dependencies somehow. But looking at all my different Perl apps, if I would bundle each of those with a Perl and it’s dependencies, updating those bundled items introduces a lot of maintenance work. Not to mention that one needs to deal with different OSes as well, not only Linux vs. Windows, but different versions and distributions of those as well in the worst case.
OTOH, some of those things might be automated again using some CI-tool like Jenkins, one could use GIT-submodules and especially the availability of branches makes dealing with multiple versions of Perl a lot easier.
Things seem ambivalent…
Comments are closed.