This has to be one of the most jaw-dropping threads I've ever seen on Perlmonks. Had the OS been some sort of Linux, and the vendor was some Linux vendor, the response would have been get yourself a C compiler and learn how to use CPAN.

Instead of skimming the thread, may I recommend reading it? This has been repeatedly discussed.

And do you want a job in our support department telling our thousands of Windows users how to install a C compiler, nmake, configure CPAN, and install the necessary modules they need/want? And in the unlikely event they make it past all of that, are you also willing to take all of the support calls you'll get when a module fails to install but the customer thinks it's our fault because we provide the dedicated server, rather than the module author's fault? People who get a *nix server from us generally have a better understanding of technical issues involved but the Windows folks don't.

I can't tell you how many Windows servers we have (not allowed) but we're the largest hosting provider in the United Kingdom and many of our customers aren't programmers and don't want to be programmers. They just want to install a bulletin board, maybe some blog software, or something similar. They're consumers, not developers, and if they choose Windows, they're used to just installing stuff and forgetting about it.

And do you want a job in our support department telling our thousands of Windows users how to install a C compiler, nmake, configure CPAN, and install the necessary modules they need/want?

Thousands of Windows users who want to program in Perl.

It's not totally out of line to suggest that Perl programmers on any platform learn to manage a C compiler. (I could see an exception for programming students.)

Vanilla/Strawberry don't take that complexity away -- they just provide the compiler and other tools and pre-configure everything so it just works. They also include upgrades to a bunch of 5.8.8 core modules to provide better Windows support out of the box.

It's packaged and standardized complexity instead of complexity that every person frustrated with AS has to figure out and solve for themselves.

If you're talking about Windows end-users of a program written in Perl, then I would imagine the better solution is using PAR or something to package everything they need rather than relying on them to install Perl itself and get necessary dependencies from CPAN or PPMs.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

And do you want a job in our support department telling our thousands of Windows users how to install a C compiler, nmake, configure CPAN, and install the necessary modules they need/want?

Who said anything about giving a C compiler to a user. I was suggesting one for you. Why would I give a customer a compiler when I can simply build a solution for them? This reminds me of a quote from elsewhere...

Perhaps you have forgotten that this is an engineering discipline, not some sort of black magic.

ActiveState, much like all *nix will not provide all of CPAN for download as a package. It simply isn't practical. You can, however, make it easier on yourself by providing your customers a Perl with several hundred extra modules out of the box.

But what is the solution for the modules that you don't provide or ActiveState doesn't build PPMs for? In the case of dedicated hosting customers on Windows, the answer is rather simple. Host your own PPM repository for them.

Here's how it works. Hosting customer calls up with a request for a module to have a PPM built. A level two support person attempts to build the PPM for them in something closer to a development box. Certain modules could be automatically declined like PDL, which requires a Fortran compiler, or modules that require special licensing like DBD::Oracle or DBD::DB2. If it can be built, you add it to your repository. If not, you let the customer know that it is not available at this time, and give them a solution for how you can resolve it through licensing or other means. For modules you can build, you add it to a custom build script of modules to watch CPAN for, so if a new version is released, it just pulls it down and create a new PPM.

As time goes on, you will probably want to make the process more automated, like eliminating the support person from the process, unless problems occur in the build. My guess is that you could even put a web front end on this and let customer request the modules be added by themselves.

That's true that it's relatively straightforward to set up a ppm repository, and build ppm packages with the right tools. A minor point, for archival purposes:

Certain modules could be automatically declined like PDL, which requires a Fortran compiler, or modules that require special licensing like DBD::Oracle or DBD::DB2.

• PDL, as well as PGPLOT, which PDL can use, are available as ppm packages, thanks to the heroic efforts of syphilis.
• ActiveState has worked out the licensing arrangements in order to supply a DBD-Oracle ppm package.
• IBM gave permission for us to provide a DBD-DB2 ppm package.

Had the OS been some sort of Linux, and the vendor was some Linux vendor, the response would have been get yourself a C compiler and learn how to use CPAN.

I agree with almost everything you've said, but I don't know how far I'd get recommending people do just that on Windows.