R – How to manage Perl module dependencies

dependencieslegacymoduleperl

I'm currently in a project which develops using a framework developed by another department as the base. We are currently introducing quality standards (at last, yay!) in our department, but it's currently impossible to introduce those to the other department. As a consequence, we are working against a constant moving target without either API stability or stable releases, which is stressful at the very least.

Since we are trying to fix things at our end first, we'd like to secure ourselves as far as it gets against changes in the "upstream" a.k.a. framework code. We'd envisioned hard module dependencies:

  1. Using only certain version ranges of framework modules, defined in code.
  2. Using a unit-test check to ensure that all necessary versions are still available.
  3. Every version range extension requiring peer-review of framework code.

That's the plan so far. Now the questions:

  1. Is it sensible? If not, any other ideas?
  2. How does one implement this in perl? Using use Module we can only define the lowest version code is supposed to work with.

Best Answer

It's a very sensible plan, and I implement it through a private CPAN-like repository that I've been calling 'DPAN'. You select the distributions and versions that you want from the real CPAN (or BackPAN), and create your own repository from it. Your CPAN clients point only at this repository, effectively freezing versions to exactly what you want. You only upgrade when you want to.

Additionally, the DPAN allows you to easily add not only your own local, private code, but to modify third party packages to fix problems with their installations, etc. I have a complete justification for the idea in the Summer 2009 issue of The Perl Review. You can also see my slides from my Creating Your Own CPAN talk at YAPC::Russia.

If you're interested in this sort of solution, check out my MyCPAN::App::DPAN module. It takes a directory of distros and does the rest for you. You point your CPAN client at it (and ensure that it won't connect to the internet) and that's that.

Once you can make your own repository, you can easily make a testing repository. Dump the versions that you think you want to upgrade into it, deploy the code on your testing server, and collect the results. If you don't like the results, you can easily change the repository.

The next big step in my DPAN work is to take an existing Perl installation, with whatever modules you might have installed, and create the repository that would give you that installation state. I have all the major pieces I need to do the work, but I've been a bit busy getting a couple of customers running with the first bits.

If you'd like to hear more about this stuff, just let me know. :)

Related Topic