Extend known installation processes to include modules

I should perhaps stress that I am thinking of InstallShield-like type of delivery.

I've always wondered this: What's to stop a Perl developer from wrapping his application in an InstallShield-like installation program? Modules are just additional required files (a la DLL's and the like). I'm not 100% sure how this works, but if you can install stuff in a directory of the user's choosing plus $WINDOWS, why can't you extend that and install things into $PERL_LIB/site_perl (or however you need to go about determining that destination)?

If you're installing a module once on a single machine, it pays to use stuff like CPAN or PPM. Nevermind that it seems to be buggy for you (I've never had problems). If there's a problem with the tool, report it and/or help to get it fixed.

If you're going from there and mass-distributing an application between different systems, just extend your process to include the modules that your application needs. Go from this:

c:\myapp\myapp.pl
c:\myapp\myapp.conf
c:\myapp\MyModule.pm
[download]

to this:

c:\myapp\myapp.pl
c:\myapp\myapp.conf
c:\myapp\MyModule.pm
$PERL\lib\site_perl\Some\Module.pm
$PERL\lib\site_perl\Another\Module.pm
[download]

Or just 'use lib' in your code, and install Some::Module and Another::Module straight into c:\myapp\!

I really don't understand what the big deal is. If you're already going to have to invent a mechanism to mass-distribute your Perl application, why can't you just take it a trivial step further and include the modules in that? Am I missing something?

It is my opinion that people just don't want to even think about figuring out how to do this extra step, so they invent a "no non-core Perl modules" restriction in their development. It just doesn't make any sense to me. What we need is someone with experience with some of the various installation program toolkits that can tell us how to bundle Perl modules with it in a reliable way (either placing them straight away in the Perl's lib directory (maybe watching for versioning even), or just a simple installation with bundled modules placed in the application's directory).

Comment on Extend known installation processes to include modules Select or Download Code

Replies are listed 'Best First'.
Re: Extend known installation processes to include modules by alien_life_form (Pilgrim) on Dec 05, 2000 at 14:51 UTC
Greetings >I really don't understand what the big deal is There's no big deal... Just not my cup of tea - I do agree that a standard packaging/installation tool would be nice. So much so, in fact, that I would advocate a standard packaging/installation/delivery tool (and as previously noted, PPM appears to have features that go in the right direction for that). >Or just 'use lib' in your code, and install Some::Module >and Another::Module straight into c:\myapp\! That's what I do for my modules. libnet, however is another kettle of fish. >It is my opinion that people just don't want to even think >about figuring out how to do this extra step You are perfectly right. I, for one, would gladly avoid confronting the miseries that await folks that develop/build installation environments. I am also paid to do other things, BTW: my company has two people whose mission in life is solely to take care of the installation process. Which they do, using InstallShield: for me, integrating with their process means having a (possibly CLI) tool that is more or less compatible with this environment, and that is my current quest. Make no mistakes, I am deeply awed by tools such as CPAN and PPM. I just think that we still need an extra mile of effort to get reliable delivery. (I am no python expert and cannot verify it, but reliable sources tell me that python has a tool that packages a full runtime exactly to this end) It's a dirty job, but someone will have to do it... >so they invent a "no non-core Perl modules" restriction If my current project goes through, I will have to confront much more powerful "No perl" and "No apache" biases (this is a WinNT project), and trying to put a cap on complexity makes a lot of sense in this predicament - though it is always a worthy objective, IMHO. This said, I will have to ship mod_perl, all the Apache:: family, and modules of my own devising, so I tend to give a cold reception to accusations of coreness bigotry. >in their development. It just doesn't make any sense to me. If you just think about the entailments of delivering product X for install OR upgrade, in 6 languages and supporting 4 RDBMSs on an arbitrary wintel machine perhaps sense will come. Wanton planners can find they have to manage 48 variants per task, besides accounting for all the possible glitches that system dependencies bring. Linux/Unix is a much more uniform environment, and one in which you can usually count on a sysadmin which some idea of what it is doing. (And even on Linux platform, package dependencies are becoming a headache) On wintel, the seemingly harmless assumption of being able to count on a particular version of IE (because you need its XML control, say) is poison. Which means that every bit of simplification that can be had translates in potentially large final gains >What we need is someone with experience... Wholeheartedly agree. > (about PPM) Nevermind that it seems to be buggy for you >(I've never had problems). Well, bugs are there. This link to deja documents the problems I and many others had with ppm over the last 4/5 months (since their first release of 5.6). Looks like it's been fixed in the latest build (but who knows? it was said before) - and yes, it was reported by many, my humble self included, and a few guys also debugged the problem and posted a pointer to a (server side) module problem. AS took its time to fix it, however. Cheers, alf ---- You can't have everything: where would you put it?	[reply]
Re: Re: Extend known installation processes to include modules by Fastolfe (Vicar) on Dec 05, 2000 at 18:35 UTC
I think we're moving out of context here. Mainly I was railing against those that invent the restriction even though they already have invented or have decided to invent a method of distributing their code to, say, 100 other systems. Even if it's the equivalent of a .zip file. Just put the modules and its pieces in a subdirectory of your build directory, add a 'use lib' pragma, and it should work, no? My only concern is those modules that need to load a shared library of some sort when starting up (libnet?). Is it feasible to re-locate an item like that? Hell, even if you can't relocate, why can't you just add those directories in your archive. It's not like each module must be re-installed on the target machines (unless they're different OS's). Just pack up something like this: `c:\myapp\ c:\perl\site\lib\Net\ c:\perl\site\lib\OtherModule\` [download] Assuming Perl is installed in the same place on each system, your simple .zip distribution process would work. That's why I'm saying it should be trivial to extend an existing installation process. Even an InstallShield installation should be able to adapt to something like this. All the modules are are additional files that need to be unpacked under the Perl root. I suspect the toolkit has means for detecting this directory. Just install your modules and supporting binaries as you would any DLL!	[reply] [d/l]