>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?