perlmeditation markjugg <h3>The problem</h3> <p>Installing a Perl web application should be as easy as "1. Unpack 2. Upload 3. Visit URL for configuration". Typically it isn't this easy, especially when the application follows the best practice of re-using CPAN modules. </p> <p>By contrast, my average experience installing a PHP web application has been impressively easy, approximating the three step process I outlined above. </p> <p>There's certainly nothing about the language itself that restricts this ease use. DadaMail has basically <a href="http://mojo.skazat.com/installation/">got it</a>.</p> <p>The DadaMail difference is that bucks the norms of CPAN culture. It doesn't exist on CPAN, and it bundles the modules it depends on from CPAN rather than requiring the users to fetch them themselves. </p> <readmore> <h3>CPAN was designed with geeks in mind, not end users.</h3> <p>Having end users get modules themselves from would a better experience if it were designed for them. As an installation <code>cpan</code> appears to primary desired for users who run as root and have a shell and and compiler handy. Sure, there are documented ways to install modules as a non-root user, but it Shouldn't Be That Hard.</p> <p>As a result, Perl apps aren't seeing the user base that they could. For example, <a href="http://search.cpan.org/perldoc?WWW::Selenium::Utils">selenium-regen</a> is a nice helper script for use with <a href="http://www.openqa.org/selenium"> Selenium</a>. It comes bundled in the WWW-Selenium-Utils distribution. It would be useful to a lot of people outside of the Perl community, but fussing with installing related CPAN modules is required to use it. </p> <h3>The merits of bundling prequisites</h3> <p>Some people react negatively to the idea of bundling prerequisites, as DadaMail has done. When you do this, the argument goes, it will be difficult to deploy upgrades of the bundled modules because you now have several copies in use with one copy in each bundle.</p> <p>Doing sysadin for a website development and hosting company, I've had the chance to experience the recommended "everyone uses one copy" philosophy. I'll be clear this has significant drawbacks as well. This design assumes that upgrades tend to make things better and that backwards compatibility is maintained. In practice, the only thing for certain about an upgrade is that Something Changed. The more projects that depend on that module, the greater chance there is that one them depended on the behavior before the change happened.</p> <p>So while this approach may save module installation time, it potentially destabilizes the overall system, and requires quality assurance testing of all the projects that use the required module. Attention may still be needed to be given to many projects hosted on the server.</p> <h3>A little infrastructure may go a long way.</h3> <p>I have a vision for an alternate way to access CPAN that addresses these concerns. </p> <p>This site would be designed for end-users and end user applications, not necessarily programmers and modules. However, unlike all the "script archives" out there, this system would be designed for projects built primary with CPAN modules. </p> <p>When a user clicks a download link here, they would receive a tar ball which bundles all the distributions the project depends on. The distribution authors would only need to generate hints about these in a normal CPAN upload. The infrastracture would take care of generating the tar balls. </p> <p>The result would be something that could be unpacked and uploaded, without additional installations or command line fussing. </p> <h3>Handling Perl XS</h3> <p>Handling Perl XS code would be the trickiest part of this system. "XS" code is C code compiled for a particular architecture. </p> <p>Here we can follow in the footsteps of how Linux distributions already handle this for Perl XS code: by making binary packages for each target architecture. </p> <p>From my initial poking around, it seems we have the key tools to address this systemically, by automatically (or easily) generating and uploading platform-specific binaries for each distribution which directly uses XS. </p> <a href="http://par.perl.org">PAR</a> generates platform-specific binaries for Perl distributions. Adding PAR integration to a typical Perl distribution is so easy that it could be automated in many cases. For a typical Makefile.PL, you can simply <code>use inc::Module::Install;</code> instead of <code>ExtUtils::MakeMaker</code>, and then add a line at the bottom like: <code> par_base('MARKSTOS'); </code>. Now <code>make par</code> is available to generate a PAR file made just for your platform. <h3>In Conclusion</h3> <p>Making Perl applications easier to deploy helps us all. Our work becomes more accessible to others, lowering the bar for gaining new users and contributors.</p> <p>Historically, The infrastructure of CPAN has been a tremendous assest our community. Let's take the lesson of the value of good infrastructure and use it to expand the reach of Perl. </p> <!-- Node text goes above. Div tags should contain sig only --> <div class="pmsig"><div class="pmsig-20513"> <P> [markjugg|Mark Stosberg] </div></div>