Search code examples
perluricpandotcloud

Module (not?) being installed because it is up to date (is it?)


I am trying to deploy to dotcloud. My Makefile.PL points that I require URI 1.60. The development.yml file says that as well. The builder claims that the module is installed.

18:38:39: [www] I am snapshotsworker_02/bob-3, and I will be your builder today.
18:38:55: [www] URI is up to date. (1.60)

If I run

dotcloud run www -- perl -MURI -e '1'

It fails with

Can't locate URI.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .).
BEGIN failed--compilation aborted.

This could be correct, because typically modules are installed under ~/perl5. So, I tried:

$ dotcloud run www -- perl -I /home/dotcloud/perl5/lib/perl5 -MURI -e '1'
==> Executing "perl -I /home/dotcloud/perl5/lib/perl5 -MURI -e 1" on service (www) instance #0 (application XXXX)
Can't locate URI.pm in @INC (@INC contains: /home/dotcloud/perl5/lib/perl5 /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .).
BEGIN failed--compilation aborted.

Also strange is that cpanm is not available, although docs say we can use it:

$ dotcloud run www -- cpanm URI
==> Executing "cpanm URI" on service (www) instance #0 (application XXXX)
bash: cpanm: command not found

Any hints?

EDIT: this doesn't seem a problem with this module. Had the same with LWP. And then, still more strange, with HTTP::Date, a dependency on LWP. Something is not working correctly on module dependencies. I never had this problem with old versions of dotcloud client.

Thank you, Alberto


Solution

  • The reason for this behavior is quite simple, but also quite stupid. Here dotcloud folks could be more professionals and have the Perl stack better configured.

    So, in my dotcloud.yaml file I request a perl 5.14.x installation. This is done by adding a symlink in /opt/perl5/perls/current pointing to the version I want (in my case, /opt/perl5/perls/perl5.14.x/). For the Perl web stack the environment is set in a way that this perl is searched first.

    When I run perl through a cron job or through the run option for the dotcloud client, the perl that answers is the one in the system (/usr/bin/perl), that is perl version 5.10.x. Therefore, modules installed systemwide in the perl 5.14.x version are not available (and when I force them to get installed to perl5 home dir, they get available to both versions).

    The solution is to call the perl binary with the correct path, or to configure correctly the PATH environment variable for the standard shell environment (that seems to be different from the web environment).

    It would be great if the folks at dotcloud make this more transparent. One option is to document this issue, another option, is to set the shell environment to use the same perl as the web environment. that shouldn't be so hard.

    Alberto