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.
At the other extreme, I'm also building a static variant of CB and associated project templates. An app built with it will be entirely self-contained, with its own embedded libperl and all needed modules. It actually carries less of a space penalty than I'd expected - a static 5.8.0 libperl.a is around 2MB, but once it's linked into an app and stripped for size, it's only about 900KB.
I am leaning towards having a librarian daemon to keep track of everything, accepting queries on some suitable port
Is that really necessary? I'm not saying it isn't, I'm just saying we should at least consider using the mechanisms that are already in place.
If the modules are installed via .pkgs, they'll leave receipts in /Library/Receipts - and if they're installed with the CPAN dance, they'll appear in 'perllocal.pod'.
sherm--
C programmers never die - they're just cast into void.
