Dear Lazyweb: CGI applications as CPAN modules?

Alias on 2007-01-09T05:43:34

Of late, I've been trying to convert all my code into CPAN distribution, even the stuff that isn't normally done that way.

So far modules, console applications and gui applications mostly work ok, and the new File::HomeDir and File::ShareDir help solve the user resource and read-only data problems.

The next problem for me is CGI applications.

They almost certainly should be buildable as CPAN dists, but we have the problem of the public_html directory.

How do I deal with this? And can one install the CGI without necesarily doing so as root? Do we assume a private Perl? Private lib directory? Do I install public_html via File::ShareDir and then provide a utility to copy it to some target directory?

Other than "I do it by hand", how do you currently solve automated CGI setup? Or how do think it might be done?

---

Not with the tools we have...

tsee on 2007-01-09T08:33:59

I don't think this will work out well with the tools we have.

Let me explain: The default installation paths for the traditional Perl resources are taken from the compile-time %Config hash. This includes various paths for modules and their binary parts, but no concept of user directories, /var/www or any other resources.

Naturally, %Config being populated on perl-compile time cannot and should not provide this information. But scanning the system File::HomeDir-esque during installation and making guesses on behalf of the user can result in (for the user) very unexpected behaviour. For CGI's this path is completely impossible to take. I assume that's why you even ask in your journal and didn't just figure it out for yourself in a second.

Worse yet is asking the user during installation of a CPAN module. These kinds of questions are what makes the lives of sysadmins and cpan testers alike miserable.

What's left? Find a better configuration mechanism for the installation targets of various resources from CPAN. Or keep CPAN and its tools to what they can handle today. I don't think an in-between solution will be beneficial to most.

By the way: these were exactly the issues I was struggling with when I hacked on an external-library-system for Strawberry Perl. With the notable difference that I could build tools myself and didn't have to rely on CPAN(PLUS) in the least.

Good luck!

Steffen

Re:Not with the tools we have...

Dom2 on 2007-01-09T08:39:30

Worse yet is asking the user during installation of a CPAN module. These kinds of questions are what makes the lives of sysadmins and cpan testers alike miserable.

What you need is the installation of some tool in the bindir which can complete the installation. Taking the same approach that e.g. kwiki or rails takes. It does involve packaging all the assets into a Perl module somehow and then extracting them. In fact, a framework that does this might well be a useful CPAN module...

-Dom

Re:Not with the tools we have...

Alias on 2007-01-09T08:44:46

There are at least a few methods for leveraging "their binary parts".

File::ShareDir is built entirely on it. It installs files into the /auto/ lib area.

While I agree that teaching the CPAN infrastructure about the other resource types is likely to be impossible, I'm not entirely sure that asking the user is necesarily a bad idea.

We already let users override the installation paths via things like PREFIX. So in principle the concept of user-driven configuration is not necesarily a bad idea, particularly on small installations.

And since CGI isn't highly scalable that fits in nicely.

Since I wrote this entry I've been reminded of kwiki and the catalyst code-generation programs.

You install the main modules for the application into the system installation, and you put all the rest of the files into /share/. So you have a half-assembled installation.

You then install a secondary installer that you run as a user. This can ask per-instance questions and scan the local system, then generate an installation that is self-contained within a single user's cgi-bin dir, assuming they have one.

On the plus side, they could also then override things like template files, and tweak the configuration later.

It would at least require that the system administrator had installed the main application.

What I do

Shlomi Fish on 2007-01-09T16:57:57

What I normally do in this case, is make sure I can set up a web application using a single script. This script involves a relatively simple call to the constructor of the main module (inherited from CGI::Application or whatever) with some params, and then calling its run() method (and exiting). Then I put an Apache alias to the script to serve it under a certain location.

The application is self-contained and is aware of everything it needs, and is entirely hosted on the URL that it was placed on. This scheme may not work for all web applications, but it works for me.