<br><br><div><span class="gmail_quote">On 10/10/07, <b class="gmail_sendername"><a href="mailto:victoria-pm-request@pm.org">victoria-pm-request@pm.org</a></b> <<a href="mailto:victoria-pm-request@pm.org">victoria-pm-request@pm.org
</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br>Today's Topics:<br><br> 1. Ubuntu + CPAN ? (Lloyd Budd)<br>
<br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Wed, 10 Oct 2007 10:30:53 -0700<br>From: "Lloyd Budd" <<a href="mailto:foolswisdom@gmail.com">foolswisdom@gmail.com
</a>><br>Subject: [VPM] Ubuntu + CPAN ?<br>To: <a href="mailto:victoria-pm@pm.org">victoria-pm@pm.org</a><br>Message-ID:<br> <<a href="mailto:9712993f0710101030m64691488xe9045dd29063e7e7@mail.gmail.com">9712993f0710101030m64691488xe9045dd29063e7e7@mail.gmail.com
</a>><br>Content-Type: text/plain; charset=ISO-8859-1<br><br><br>I'm using Ubuntu 7.04, is there a method/tool to automate install the<br>libraries that are availabe as Ubuntu packags, and only use CPAN for<br>the ones that aren't?
</blockquote><div><br>Hi Lloyd, <br><br>I have run up against this issue a few times in the past. I usually opt to keep my development application libs completely separate from system libs based on application divide. I might have a unique application that I use combinations of Perl CPAN modules with that are tried and true. I am interested in which module src versions works within the particular application, as module dependency dictates. The CPAN usually installs modules to the system lib, and its possible that particular requirements for my distinctly separate applications would require different versions of a CPAN module. This means that each application gets an install of only the src modules that are needed for that application. It also means you need a build script to put the modules where the application expects to find them, and some sort of environment variable setup in a config some place that lets your application know where to find your perl libs.
<br><br>I have a script that works to check the src dependencies based on an application root, but it assumes a particular directory structure. This script uses Modules::Depends::Intrusive to do its heavy lifting (my version of Module::Depends requires Class::Accessor, File::chdir and YAML). So to recap here are some questions:
<br><br>1. Do you want to install the dependency modules that you need into the system libs, and will this conflict with any other version requirements for other applications you are working on now or in the future? If not then I wouldn't worry too much about using the CPAN.
<br><br>2. Do you want to be able to easily remove the application and all its dependencies at the termination of application development? This would argue for installing the src modules in a specialized directory.<br><br>
3. Will you be packaging up your application to move it around to various install sites? For example, will you be deploying it onto a few different servers? This would definitely argue for installing src modules in a specialized directory, and a build script to build them out repeatedly.
<br><br>I know this answer poses more questions than answers, but the issue is complicated. I do have the the mentioned script if you are interested in seeing how I have tried to solve this problem on an application by application basis. I always opt for the install of required modules into a specialized directory, accompanied with a build script.
<br><br>I have an application starter that I call Workshop, based roughly on the ideas for Matchstick that includes the build script and src modules that allow you to bootstrap a build, including Apache and Mod Perl (I do web development). I can tar that up for you and send it to you if you would like to see a more complete picture of what I am talking about. Here is the link to Matchstick (not much activity for it lately, but the idea is a good one):
<br><br><a href="http://sourceforge.net/projects/matchstick/">http://sourceforge.net/projects/matchstick/</a><br><br>This idea of a 'starter kit' grew out of the build system associated with the Krang CMS, located here:
<br><br><a href="http://www.krangcms.com/">http://www.krangcms.com/</a><br><br>Chuck<br></div></div><br>