Using PAR for a relocatable environment

dragonchild has asked for the wisdom of the Perl Monks concerning the following question:

In Kayuda, one of our concerns is how to minimize environmental differences between prod and staging. We use scripts to build environments and the like, but it's still not the same thing. We'd also like to only build the prod environment once, not once for each prod machine.

I just took a good look at PAR for the first time today and it looks like it would be perfect for the job. Assuming identical OSes for staging and prod, I theoretically should be able to build a PAR for my CPAN modules on staging, test it, and push it up to prod on some NFS-mounted partition that all the prod machines can see.

Anyone do this? Tried it and not liked it?

For the record, I'm talking about doing this solely to manage all the CPAN dependencies the app would have, not the actual application code. (At least, for now.) The app code has dependencies on files that cannot reasonably be served from NFS, like images and CSS and JS and the like. Maybe as a second pass.

My criteria for good software:

Does it work?
Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Comment on Using PAR for a relocatable environment

Replies are listed 'Best First'.
Re: Using PAR for a relocatable environment by tsee (Curate) on Apr 19, 2007 at 14:00 UTC
If you intend to create .par archives from lots of CPAN distributions, I suggest you have a look at the PAR::Dist::FromCPAN module and the cpan2par tool accompanying it. It started out as a quick and dirty tool I used for testing PAR::Repository, but it should be quite usable now. Theoretically, it can even follow arbitrary CPAN dependencies. One exception are modules using Module::AutoInstall which break the CPAN.pm dependency checking itself. (Read: They're broken.) In fact, your use case kind of sounds like you could have a look at PAR::Repository / PAR::Repository::Client, too. Just keep in mind that PAR::Repository (the administrative interface which can inject new .par's into the repository) doesn't run on win32 because it needs symlinks. The basic use case of PAR::Repositories on the client side is as follows: `use strict; use warnings; use PAR { repository => 'file:///path/to/repository/on/nfs/' }; # or: # use PAR { repository => 'http://repository/url' }; use Foo; # Foo loaded from the repository if not found locally.` [download] For finer-grained control, you can eschew the interface using PAR and create your PAR::Repository::Client by hand. That way, you can use it to locally install and update the distributions instead of fetching them from the repository, etc. On a side note: you can embed arbitrary data files (i.e. CSS/HTML) into a .par and have them extracted when the .par is loaded. You would find them in the $ENV{PAR_TEMP} directory or so. (The PAR::Environment POD has the details on all the environment variables PAR uses. If in doubt, test.) In the hope this helps, Steffen	[reply] [d/l]

Replies are listed 'Best First'.

Re: Using PAR for a relocatable environment
by tsee (Curate) on Apr 19, 2007 at 14:00 UTC

If you intend to create .par archives from lots of CPAN distributions, I suggest you have a look at the PAR::Dist::FromCPAN module and the cpan2par tool accompanying it. It started out as a quick and dirty tool I used for testing PAR::Repository, but it should be quite usable now. Theoretically, it can even follow arbitrary CPAN dependencies. One exception are modules using Module::AutoInstall which break the CPAN.pm dependency checking itself. (Read: They're broken.)

In fact, your use case kind of sounds like you could have a look at PAR::Repository / PAR::Repository::Client, too. Just keep in mind that PAR::Repository (the administrative interface which can inject new .par's into the repository) doesn't run on win32 because it needs symlinks.

The basic use case of PAR::Repositories on the client side is as follows:

use strict; use warnings;

use PAR { repository => 'file:///path/to/repository/on/nfs/' };
# or:
# use PAR { repository => 'http://repository/url' };

use Foo;
# Foo loaded from the repository if not found locally.
[download]

For finer-grained control, you can eschew the interface using PAR and create your PAR::Repository::Client by hand. That way, you can use it to locally install and update the distributions instead of fetching them from the repository, etc.

On a side note: you can embed arbitrary data files (i.e. CSS/HTML) into a .par and have them extracted when the .par is loaded. You would find them in the $ENV{PAR_TEMP} directory or so. (The PAR::Environment POD has the details on all the environment variables PAR uses. If in doubt, test.)

In the hope this helps,
Steffen

[reply]
[d/l]