Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • If you're looking for something with low dependencies and low learning curve, CGI::Application is definitely the way to go. You could also use something like Titanium which is pretty much just a bundle of C::A and some of it's more useful plugins.

    As far as self-contained apps go, you could go the Krang, PAR or CPAN route. All of which have problems:

    Krang
    ======
    PROS - This is what I did for Smolder and it makes installation fairly simple if you know what platforms you're going to deploy to since you can prebuild binaries. BTW, I just copy-pasted the build code from krang (bin/krang_build and lib/Krang/Platform.pm) and modified for Smolder.
    CONS - Several people have approached me about building packages of Smolder for various linux distributions and that's nearly impossible. Since we bundle everything together it's hard to get it to fit into their package managers. It's also pretty non-standard so some people look at it funny when they see the install process.

    PAR
    ===
    PROS - If you go with something like HTTP::Engine for the server and DBD::SQLite for database, then you have a pure Perl solution. You should be able to make a .par file out of that and just say, "Here run this". And there are a lot more people using PAR than the Krang-style build system so you'll get more help from others.
    CONS - PAR is, IMO still very magical and may have problems. Plus I've never used it :)

    CPAN
    ====
    PROS - With a pure-Perl approach like the one I described above for the PAR option you can make it dead simple for any Perl folks to install via the cpan shell. You don't need to self manage your dependencies (like the Krang style). It's also pretty trivial for distro packagers to make a package for their system since doing that for Perl modules is pretty standard stuff.
    CONS - Non-Perl folks will probably not be happy. Especially if they don't have a working CPAN install or the machine isn't connected to the network.

    Hope that helps!