All the Perl that's Practical to Extract and Report

Perl Applications (revisited)

davorg on 2003-01-21T10:51:07

A few days ago, brian d foy wrote a journal entry asking for example of end-user applications written in Perl. He got a number of responses, but most of the apps that people came up with were aimed at developers. Very few of them were the kind of thing that users would... er... use. Why is that?

I think that one of the major reasons is CPAN. Don't get me wrong. Obviously I think that CPAN is great. It's one of Perl's greatest strengths. But I also think it's preventing people from writing applications written in Perl that are aimed at end-users - because end-users won't be installing CPAN modules in order to run their applications.

Looking back, I see that this isn't news - even to me. I made a decision that the nms programs would only use standard modules as we wanted to make things as easy as possible for people to install them. We realised that most people using the programs wouldn't want to get involved in all that. Even tho' things like CPANPLUS make installing modules really easy, it's still a step that end-users typically won't want to take.

Just this morning I saw someone on PerlMonks say that they wouldn't use a particular module in their application as it needed about 15 other modules from CPAN in order to work and they couldn't expect their customers to do that.

So what do we need to do? Well, we need to make it easier to bundle up an application with all of it's required modules. We then need to come up with some way to install an application which also installs the bundled modules (but only if they aren't already installed - and taking into account things like version numbers). Oh, and it needs to be able to install them in such a way that you don't need to be root in order to install them.

There's a lot to think about. But the Perl community has done already achieved something like this. The standards for CPAN module installation make it very simple for a developer to install modules. We need to enhance and simplify this process so that it can handle application installation.

Has anyone already been thinking along these lines? Will Perl 6 help us solve any of these problems?

PAR?

2shortplanks on 2003-01-21T11:09:49

Re:PAR?

davorg on 2003-01-21T11:16:19

Oooh.... that does look interesting. I'll investigate further. Thanks.

Hmm.

koschei on 2003-01-21T12:17:56

Which module had too many requirements? Or, which thread? I tend not to follow perlmonks (it's not my style of interface; needs more of a usenet / mailing list approach for me to like it; same with slash really).

People often complain that some of mine have too many requirements, but I generally don't pay attention to them. I use the modules because they make my life easier.

I can live happily whether they install my module or not. (I think Ask mentioned that WWW::Shorten had a number of requirements, most of them once removed from W::S itself.)

Re:Hmm.

davorg on 2003-01-21T12:28:10

It was in the chatterbox. I think it was Net::SSH::Perl or something like that.

But the issue isn't really that it has too many prerequisites. For the audience I'm talking about, even one prerequisite (that they then have to install) is too many :)

Re:Hmm.

koschei on 2003-01-21T12:52:06

I'm not entirely fond of ExtUtils::AutoInstall in a Makefile.PL of a module, but I do like it in the Makefile.PL of an application. Mind you, not enough applications come with Makefile.PLs.

I can happily see that such things are necessary. I'm just a snob about my (somewhat crappy) modules and programs =)

Like many of those reading, I upgrade my modules regularly. I run 5.8.0.

Perhaps unlike many of those reading I find it irritating when someone writes a workaround for a bug that was eliminated over 2 years ago rather than have people upgrade the module in question. If they're not going to expend effort, why should I? Sure, they may not know enough. Or things may not be easy enough. But will it ever be? Will they ever know enough? Do they give a damn?

Perl 6 will make this a bit easier

Elian on 2003-01-21T14:48:20

You'll at least be able to ship a single bytecode file that has everything compiled into it, at least all the perl bits. Any C extensions will be somewhat problematic for portability reasons, as you're not going to be able to embed real compiled code, but there might be something we can do about that--perhaps some sort of archive/installer thingie that can handle a zip or tar file with the pieecs in it. (Perhaps even the source, though I wouldn't look forward to an install of an app that wanted to rebuild Tk, for example)

Movable Type does it

barbie on 2003-01-21T17:02:04

The weblog application Movable Type includes a bundle of all the Perl modules which can either be installed under your local cgi directory or in the Perl install directory.

In general apps like Movable Type are aimed at people who don't always have access to the Perl install directory, so it explains how to upload via FTP the directory structure as is. Obviously this wouldn't work too well with anything that needed compiling.

PAR looks like a great idea to make this easier.

GNU autotools

jdavidb on 2003-01-21T18:29:34

I built a few small-scale applications for distribution to different machines at my last job using GNU autoutils (autoconf and automake). I put needed modules (usually locally created modules, but could just as well be .pms extracted from module distributions) in a private lib/ directory, and used autoconf to preprocess my program, adding a use lib pragma and other things to insure all the right libraries got used. This would also be a nice way to avoid version conflicts.