Re: Extend known installation processes to include modules

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?

Comment on Re: Extend known installation processes to include modules

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

Re: Re: Extend known installation processes to include modules
by Fastolfe (Vicar) on Dec 05, 2000 at 18:35 UTC

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]

trivial

extend

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]