Re: A Vision for Easy Web Application Deployment for Perl

[dragonchild]

Several mostly-unrelated comments:

• Perl6 will address the XS issue by assuming you have Parrot installed. Since Parrot does all the heavy-lifting, nearly every CP6AN distro should be "pure-perl".
• The primary issue isn't "How do I install this as a non-root user?" but "How do I install this in a place that my code will find?" You are generally expected to be root because the perl executable has root-only paths hard-coded. It seems to me that we need to do two things:
  1. Provide more documentation/tutorials/whatever to get "use lib" into more use.
  2. Provide an easier way in CPAN(PLUS) to install into a directory on a per-install basis. Maybe something like "install Foo into lib" or "installdir lib\ninstall Foo" or something like that. But, configuring CPAN as a non-root user when there's already a root user requires source-diving and crazy configuration. If you're not a root user, it shouldn't use the root config.
• Building on the prior comment and using Dadamail as an example, Dadamail should be able to specify to CPAN(PLUS) that it wishes to install all the prerequisites into a given directory, assuming that the prereqs aren't already there. You should also be able to specify to Dadamail where your personal installs are, if you wish. Then, Dadamail should be able to build a string of "use lib" items that it places in a special .pm file that it sources in immediately, probably through 'do' because 'use' scopes too much. That kind of work needs to be automated.
• The XS issue in Perl5 is a tough one, especially as most interesting apps will want to use MySQL and DBD::mysql is problematic in a shared-hosting environment. You either compile against 4.1+ or pre-4.1 and the two cannot live together, just like MP1 and MP2 cannot live together. Maybe C-compilers are just a requirement with free ones listed (gcc, MingWcc, etc).
• The interface to CPAN needs improving. The three .gz files that get downloaded shouldn't be that way by default. Whenever I go to cpan, I'm usually issuing 1-3 "install Foo" commands and that's it. cpan should be able to ask some CGI front-end "What's the correct FTP command for grabbing the Foo module?" and let a centralized database do the rest. Here's why - I often want to build my own personal CPAN so that I can use CPAN.pm to update my company's modules on production instead of using SVN. That's just one more thing to install on production machines and I don't like that. (The alternative is bundling and installing by hand which is fraught with danger as befits any by-hand solution.) If the API for CPAN was a clear and simple solution (with maybe a personal CPAN app?), then doing this would be a piece of cake. Imagine that as your upgrade solution for your company's modules!

[markjugg]

Thanks for all the feedback. I want be clear that the "cpan" or "cpanplus" shouldn't be required tools for an end user to have, in part because they shouldn't need to use or understand a shell.

If tools like they are involved at all, they should come into play as part of the web-based configuration step. There the software can ask permission, and then install extra modules under the covers.

[dragonchild]

Sure, if that's how you want things to go. Just embed a webserver and let it do its thang.