metamod:handling_dependencies

This is an old revision of the document!


How to handle external dependencies (Suggestion)

METAMOD uses a large number of external libraries and this number has increased greatly during the conversion to Catalyst. This document describes the how dependencies will be handled and why we have chosen to handlen them in this way.

Underlying this discussion is a guiding principle that external dependecies is the reponsible of each project. This should increase developer productivity as external libraries can be used when they are available and new features and bug fixes will be available sooner. The downside is that dependency handling takes time. With the solution proposed below we expect that the time required for dependency handling will be minimal.

  1. Access to any relevant module on CPAN. We don't want to be restricted to only the modules or module version available in operating system package repositories.
  2. Installation of specific module versions and not just any version.
  3. Installation on different platforms. For instance installation on both 32 and 64 bit Ubuntu Lucid.
  4. Automatic installation of necessary packages and all dependencies.
  5. Automatic installation also outside of met.no environment. This is necessary for possible adoption by other organisations.
  6. Installed modules should never conflict with other systems installed on the same server.
  7. Installation and upgrading should be simple when inside the met.no system.

In general handling dependencies is hard! There is no perfect solution to all the problems that can arise when it comes to dependencies as there are often conflicting requirements and the underlying infrastructure is not good enough (e.g. different Perl module installers cause problems).

Some of the problems we come across when using CPAN modules:

  • If we should only base the application on packages available in the Ubuntu package repositories we would be quite restricted as:
    • We are currently only using the LTS version of Ubuntu, meaning that we will slowly be out-dated when it comes to new version.
    • Not all of CPAN is available in the Ubuntu package repository meaning that we would have to build packages our selves any way. This would mean that we do not save that much time on using Ubuntu packages.
  • CPAN clients will always install the newest version it can find of a specific module. In this scenario this is not what you want as you want to test METAMOD for specific set of module with a specific version number.
  • Old version of a module or an entire module can be deleted from CPAN.
  • Installing modules to the standard Perl module directories can wreck havoc other Perl programs on the same machine.
  • Installing large dependency chains on a machine takes a time as many modules have large tests suites that should run.
  • Installing large dependency chains increase the likelihood that at least one module will not install correctly. Solving these problems can be trivial, but require human intervention. We want the installation to be automatic.
This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.More information about cookies
  • metamod/handling_dependencies.1287992285.txt.gz
  • Last modified: 2022-05-31 09:23:19
  • (external edit)