At 9:39 PM -0500 2/27/03, Sherm Pendley wrote:On Thursday, February 27, 2003, at 08:01 PM, Daniel Stillwaggon wrote:
Any perl application could ship with all of the perls and modules that it requires in its .pkg. Before installing, it would do a quick query and find out which, if any, of these perl modules/versions would need to get installed in addition to the core program, and create a bom accordingly.
That's a very interesting idea - I've been thinking along those lines for a future CamelBones installer, which would examine the target system and install a 5.6.*- or 5.8.*-compatible version of CB, as appropriate.
It seems like it would bulk up the download, though. For many folks, disk space is plentiful - but bandwidth is not. For the shared CB in /Library/Frameworks, I've been thinking of having the initial download consist of nothing but a tiny installer app, which would examine the system and suggest what packages to download and install.
The bigger issue, honestly, is dependent modules. I put together a simple client for the PerlMonks chatterbox ages ago, as a test, and it works pretty well, but it requires a whole host of modules be installed into the system perl, and I dodn't work out a good way to either include them with the program or check to make sure they were there when the program fired up.
A way to do packaging would be good, though there are licensing issues there that you don't have to deal with when using system-installed code.
What about PAR / pp ?
from the man page:
pp creates standalone executables from Perl programs,
using the compressed packager provided by PAR, and the
dependency detection heuristics offered by Module::Scan-
Deps. The programs are stored verbatim without compila-
tion.Marcus
