|Perl: the Markov chain saw|
This is a prime recipe for increasing the number of out-dated Perl modules installed on production machines and giving Perl a bad security rap.Having a bad security rap involves having users (so someone actually cares about your reputation), and having bad security, so there's actually a problem). To have high profile security problems with Perl web apps, we have to have the high profile web applications in the first place. Moveable Type is a high profile web app using this strategy, and I'm not aware that it is contributing to Perl having a reputation of poor security. Having watching many ChangeLogs of Perl modules go by over the years, I rarely see updates because of security vulnerabilities. Changes tend to be bugfixes, new features, and sometimes incompatible changes (which are a real problem). Security updates are rare for Perl modules. When I think of visible Perl code with poor security, I think of the original Matt Wright script archive code, before the NMS project. If users want web software that's easy to install, they will find it, whether it's through projects that bundle like Moveable Type or Dada Mail, in a simple script format, or in another language like PHP.
I'm confused, if you can auto-generate the packages you're presuming that the bundle will work with the latest version of the module. So what's the difference to installing the latest module version into a central place? The only difference I can see is a false sense of security on the part of the user who thinks "this must work because I downloaded the Bundle" and will be all the more disappointed if it breaks.Module::Build allows you to be very precise about the versions of the prerequistes you require. You can set a minimum version, a maximum version, and make exceptions as well. So an author that wants to optimize for stability that can do that, by giving precise version numbers, so a newer prereq wouldn't automatically be included in the bundle. An author could also take the approach of simply setting a minimum version of prereqs, expecting that future versions will be compatible improvement or security improvements. This kind of choice is already exists in Module::Build for module authors, so this is aspect requires no infrastructure changes.
Anything that gets made easier will be done more often.Agreed. This proposal allows people to have an additional definition of "easy". It seems your definition would involve continuing to install and upgrade Perl web apps as you do now, which you can keep doing.
I care much more about Perl getting a bad reputation for its security than I care about the convenience of amateur webmasters
I'm a professional website developer, and this is a problem for me. I maintain CGI::Application and Data::FormValidator and have used them on many projects. Both are installed in a central location on our production web server. Although I'm in charge of reviewing and releasing the code for each, at least once in each case I managed to release a version with an incompatibile change that would break other applications in production if it was deployed, although the older versions worked fine.
This wasn't about security, this was about the realistic impossibility of maintaining complete compatibility when moving a software project forward.
So even as a professional website developer, it's safer choice to deploy specific module versions in production than to use a shared version.
It sounds like Perrin, another respected professional web developer, takes the same approach with Krang, another higher profile Perl web app. I know Jesse Erlbaum, the creator of CGI::Application, is also on the record as recommending putting public modules under source control and deploying private versions of them. (It looks like someone attended a talk he gave, and summarized that point as point 10 under "Implementation").So, professional web developers are already using the approach deploying specific versions of prereqs with applications, and we know it works well for us.
I do agree that dependency handling an installation from CPAN is not as end-user friendly as it could be, but this is a very hard problem to solve correctly. I don't see any merit in auto-bundling software together for the purpose of spewing multiple versions of module all over your harddisk.
I like to think of it as several applications which have the same features and stability as when they were deployed...
Thanks for sharing your concerns with this approach. I'm sure they are shared by others, and it gave me a chance to flesh out the details and justifications some more.