"No non-core Perl modules"

WHAT?

No *way*, man. These modules are made to be used, even if they are not installed as standard.

OK, let's see the arguments:

• "this being a particularly acute problem for people stuck on Wintel machines"
  • "where CPAN does not really shine" - for me, it has worked out nearly all the time. The main problem for CPAN are firewalls, but even most firewalls are easily handled by an entry for the http_proxy environment variable.
  • 'make' and a compiler are often unavailable - make: go for nmake (available for free from Microsoft website), compiler: yes, this can be a problem. But most common modules will be somewhere on the net as binary, compiled by a friendly soul. Or are already available as PPM files from ActiveState.
  • "and PPM is sometimes broken." - for me, it nearly always worked out till now. The firewall problem is there, of course, but then you can download any PPM by hand from the ActiveState site with your favorite browser.
• "In general,if you are contemplating a solution that has to be deployed on more than 2 machines, the repeated installation of the same module is something you'd really like to avoid. The argument is only stronger if you want to package and distribute your code to third parties, and you cannot expect to have a perl wizard at the receiving end." - No, no, no. Read the documentation on the CPAN module Bundle features (e.g., the autobundle command). Just build a bundle for the things you want to distribute, and distribute that then. There is a problem here with conflicting versions of modules, but you have this problem with any library use, and there are solutions to that (see also this discussion).
• "am I the only person dismayed by the fact that modules using IO::Sockets now try to perform an install of the entire 5.6?" - No, you're not. That is annoying, for sure.

Reinventing the wheel for something else than educational purposes or big money is a Bad Thing.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

Greetings

>No *way*, man.
To clarify: I have - and use - plenty of non-core modules. But, I can see reasons to try to not to use them in selected situations.

Most of the solutions you propose do address (to various degrees of workability) mostly the maintainance situation, but I fail to see how I could rely on (say) autobundle to deliver a third-party installable application (the way I understand it, autobundle will go through all the make/test/install moves for the needed packages. Now assume the target machine is not connected to/firewalled from the internet?)

I should perhaps stress that I am thinking of InstallShield-like type of delivery. While I do not know PPM very well, from my vantage point it appears to be more suited to this task (packaged delivery of non-core, binary modules) than CPAN.

I have to confirm - sadly - that PPM is somewhat broken in AS5.6 as far as the network part is concerned. I know it does not work on my machine, and, judging from the AS mailing list, the problem has been widespread from at least last July. Despite the reliability concerns this raises, I can envision using PPM as a way to install prepackaged binary modules that can be shipped together with an application.

Versioning is a headache, but it is not unique to perl (ODBC drivers, anyone?) - and, for the modules I use the most, not particularly ugly. (soapbox: what is the reason of keeping libnet, LWP, DBI and all of the CPAN::Bundle stuff out of the core modules? Is anybody really doing without them these days?).

Speaking for myself, non-coreness gets one penalty point (added management complexity), C/C++ extension gets another one, 'SWIG required' gets additional two. This has to be weighted against the added ease of coding that the module brings: as mentioned, Net::FTP passes this test, but Foo::Bar::Baz may not.

Cheers,
alf

-- You can't have everything: where would you put it?

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]

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]

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).

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?

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!