Distributing applications via CPAN
CPAN is a very good system to distribute libraries we call packages or modules. What about applications? There is a section on CPAN that was supposed to distribute scripts but it never took off. Is CPAN ready to be used to distribute applications? If not, what is missing?
Padre
For Padre, which is a desktop application, we use CPAN as our primary way of distributing the source code. You can install it by just typing
cpan Padre
That's OK, but we also know that in order to provide a better user experience and to have better control on what is used in the application we need to distribute a packaged version of it, batteries inside, in binary format. That's why we have the various stand-alone versions of Padre, that's why we ask the downstream Linux/BSD distributions to include it and that's why Padre is going to be part of Strawberry Perl Professional for Windows
I think in Padre we solved the installation of the the non-code files fairly well by installing everything in the share/ directory (we use Module::Install and call install_share; or actually nowadays we call install_share_with_mofiles;) and then accessing those files using
my $share_dir = File::ShareDir::dist_dir('Padre');
Ack
How is it done in other applications?Ack is another (command line) application on CPAN, albeit a very small one. It is built from a small script and a few modules. People can install it directly from CPAN but for better user experience Andy is also packaging it as a stand alone script. For this he takes the modules and includes them inline the script. That way people can download a single script from the web site and move it around in the office and the only thing they need is a "recent" version of perl. (5.6.1)
What about web applications?
Kwiki
A quick search on CPAN led me to Kwiki which have not seen a release in 3 years and its documentation contains this friendly message: Don't install this CPAN module!. The old code was installing everything via CPAN and then you were supposed to run a command line script to generate an instance of the application.Catalyst
While it is a framework and not an application, we can also look at Catalyst. It is being installed in a similar manner. You install it via CPAN and then you run a command line script to create a directory structure for your application. This structure resembles a standard CPAN distribution that allows the easy generation of a tarball. As far as I understand the way to install that application is to unzip the tarball and setup Apache. As far as I understand it cannot be installed using CPAN.pm.Others?
What other applications are on CPAN and what is their strategy of packaging and installation? What other services does the CPAN ecosystem need to provide in order to make it easier to distribute and install applications through its pipes?BTW Funnily each one of these applications have their own web site.
I blog about Perl.
There is a "script_files" option in Module::Build[1] which covers this. I think I'll try to create a small app and install it via it, and see how that works.
I liked the way Ack did it. Unfortunately there is no one way of doing it, just a few ways people do it (which is what your post shows). I like the way Elliot Shank does it[2].
[1] http://search.cpan.org/~dagolden/Module-Build-0.3605/lib/Module/Build/API.pod
[2] http://elliotlovesperl.com/2009/11/23/how-to-structure-perl-programs/
Installing dependency heavy applications, that also rely on external modules (e.g. Wx in Padre) really brings you into trouble usually when installing from CPAN. So from my point of view, this is a perl developer centric approach that works for this particular target audience.
But to address end-user applications, installation should be provided in binary form, for tested architecures in a mechanism the target system knows (usually meaning the local package management). Because in this case you include the novice user as part of your target audience and (s)he will be able to use known tools to install software as (s)he expects it to work.
So I really appreciate the Strawberry Perl Professional approach, as now my collegues are able to use padre out of the box, enabling them to get more into perl. And same on the linux end for debian, where just installing libpadre-perl will get you what you want.
Making people aware apps exist *and* make them accessible to them (meaning installable without issues) will be the starting point to generate further demand.
Perl people love/use CPAN, End-user don't care. (and btw. I consider myself both).
"What about web applications" ?
For Pod::POM::Web (a web POD documentation browser), the whole application sits in a regular module distributed through CPAN as usual.
Then to start the app, either you do a little bit of Apache config, or you start the standalone builtin HTTP server through the command line :
perl -MPod::POM::Web -e "Pod::POM::Web->server"
Smolder tries to be an application that can be installed from CPAN. But it's definitely painful and has been hard to get right (not that's its right yet either...). Shared files aren't too bad with File::ShareDir, but other things like conf files or data files (like an SQLite database) are harder. Different OSes usually want those in different places and it's hard to please everyone.
Catalyst-based web applications can be installed from CPAN -- examples are MojoMojo (wiki) and Gitalist (git repo viewer). They install the scripts to run standalone servers as well as fastcgi daemon in bin/ you can run from the command line or as a CGI script, as well as a module that you can load from mod_perl.
Also with PSGI/Plack, installing web applications via CPAN becomes easier and possible even if you're not using Catalyst. http://github.com/miyagawa/TheSchwartz-Web is one example (since it's in an early development it's not on CPAN but the directory structure and what not are CPAN ready). It has just one script in bin/ which can be used to run as a standalone server by default or as an FCGI daemon (with -s FCGI) or even as a CGI script. With a few lines of httpd.conf it's ready to run on mod_perl as well.
Also in my RSS-media-viwer application Remedie http://remediecode.org/ as well as github growling app http://github.com/miyagawa/github-growler I used the different tactics.
I've never shipped these applications to CPAN because the target audience is not perl users. (Are you supposed to know how to install Obj-C libraries when you install Mac apps? Of course not)
I use local::lib and cpanm to bundle all prerequisite modules in the package and use Platypus to create a .app bundle for Mac OS X. This is a solution only reliably workable for Mac OS X where they have only one (ignoring PPC :)) architecture. When Snow Leopard came out with perl 5.10.0 (where Leopard has 5.8.8) it got a little complicated though. The technique to create this .app bundle is CPANized as App::BundleDeps.
@miyagawa, thanks.
A few questions:
After installing from CPAN, how can a user customize these applications? Can s/he create customized templates? Where do those templates go and how will the application know about them?
Can the user run several instances of the application with different setups/different databases?
Gabor, note that I keep stuff in App::Ack so that the user can use the CPAN shell's ability to check for updates to the app. For the standard Perl user, that might be the way to go. The squashing together of the entire program into one file is for people who are not Perl experts, or who want to carry the program around without having to worry about installing modules on other machines.
> After installing from CPAN, how can a user customize these applications? Can s/he create customized templates? Where do those templates go and how will the application know about them?
That totally depends how applications handle them, but usually with Catalyst based app you can specify the app config file with a command line option or environment variable so you can specify the path or css URL or whatever in the path to let the apps know. Again that totally depends how applications handle them.
> Can the user run several instances of the application with different setups/different databases?
Of course.