koha

slef-reflections on Koha

Installing a complex perl web application
Koha at Crimea 2007
Koha Debian Packages
Survey of OPAC wants

Installing a complex perl web application

Installing a web application with its CPAN dependencies

Posted by mjr 2007-11-29

I fully expect to be told that this is Evil, Bad and Wrong, but what are the drawbacks of moving a MakeMaker tarball into the local cpan download tree and using CPAN::install on it like this?

Other than the usual hackiness-problems with that early draft, I can't see a blocking problem with it. The CPAN shell handles the dependencies. (Don't worry, the eventual debian package will use dpkg to install the dependencies.)

Steffen Mueller commented:

"You're not the first one to think along these lines. Related stuff on CPAN which you might want to check out is:- http://search.cpan.org/~adamk/CPAN- Inject-0.10/lib/CPAN/Inject.pm (to a lesser extent also http://search.cpan.org/~ssoriche/CPAN-Mini- Inject-0.18/lib/CPAN/Mini/Inject.pm ) http://search.cpan.org/~adamk/pip-0.12/lib/pip.pm "

No, I'm rarely original... I'll take a look at those. Thanks! pip looks particularly interesting to me.

Comment on this

Changes in koha New Model Installer

2007-09-17 (Permalink): Stage 1 of the new koha installer uses MakeMaker and some silly tricks to try to install a CGI tree, as well as modules. You can often grab prepatches from mjr-installer if you really want the latest bits sooner.

The biggest user-visible change with this installer (compared to 2.2) is that it's dumb. It's dumb in that it's trying to do the simplest thing that could possibly work and it's dumb in that it doesn't ask the installing user any questions. If you know you want to change things, you can tell it, but it doesn't ask you to confirm everything like the 2.2 installer did.

Almost immediately, that was criticised on IRC. The first criticism was about a related feature that someone else removed earlier in 3.0, really. The second criticism was stalled by the realisation that if we really want an interface that "questions everything" every time, a wrapper script can ask for all the settings and instruct the dumb installer.

I'm not sure whether asking users to confirm everything is a good move, for the sort of reasons in Havoc Pennington's 2002 essay under "The Question of Preferences" - each setting we encourage people to change makes it harder to debug installation problems. That's one of the biggest pains with 2.2 and I think we've started seeing the same happening in 3.0 already. It's not quite "no two installations are identical" but it's not far off.

So, the main installer defaults everything to the best values that I can guess that will work within the constraints. It should work for most people and it should be easier for packagers to override.

I'd still love to hear about how other Perl CGI scripts install, especially if they use MakeMaker for the basics, then use a CGI interface for the rest. Are you writing one?

Comment on this

2007-09-10 (Permalink): It's been a busy week for Koha development, really. Some of my thoughts:-

[Koha-devel] ANNOUNCE: New Installer in master git tree

I announced the new Koha installer. It's not finished (see under KNOWN BUGS), but people are starting to use it, so I thought I'd better announce it. I'll explain more soon.

[Koha] AG KohaLa

The Koha Free Association is about to hold its first General Assembly, so I reposted the announcement. Anyone know what foreign developers should do about it, if anything?

Taking the Open Road: University Libraries Explore Options

Interesting article in E-commerce Times which mentions Koha as one of the more specialist packages libraries are investigating. Good!

Slashdot | Libraries Defend Open Access

Not koha, but funny: Legacy journal publishers don't like Open Access? I'm shocked. Or something. Some of the comments are hilarious. Others remind me why I don't read much /.

Comment on this

2007-09-04 (Permalink): Time to revisit this topic. I asked debian perl for advice on packaging a CGI with modules and my current solution is to use ExtUtils::MakeMaker - I'm just writing the PL files which will generate the configuration files.

I also took a look at Module::Build and PAR::Tutorial but I'm not convinced that they're both as portable and as smooth as if I can do it all from MakeMaker. There are occasional posts about Module::Build problems on lists like this one on ledgersmb- users which worry me. After koha-1.2's bespoke installer, I really want to make it as easy and simple as possible, for both development and use. There are also periodic debates about M::B at perlmonks too.

Maybe we can use PAR later, like this perlmonks post suggests and apparently KrangCMS does.

Now, what have I missed?

Steffen Mueller comments:

"A short* follow-up on PAR. It has mainly to very different applications.

- You can package whole applications with its (Perl module) dependencies into a binary executable and run that.

- You can use PAR as a module in your program to (potentially dynamically) load dependencies or extensions from so-called PAR archives. Those are actually ZIP's with a .par ending.

So if you have a CGI application which depends on modules which aren't available as debian packages, you can use the "PAR::Dist::FromCPAN" module to create .par's for those dependencies which aren't available via debian and include them in a data or lib or whatever non-web-accessible directory of the CGI application. Then, in the app, you do "use PAR '/path/to/the/web/app/par/dir/*.par';". Dependencies will be dynamically loaded from the .par's.

Please note, however, that the above process is quite heavy on the start-up performance if you have a lot of .par's or big ones. You can merge many small ones which gives you some performance gain, but not enough.

Using PAR::Dist::install_par and some hackery, it's possible to install .par'd distributions into an application local path.

I discussed these approaches to greater length and with working example code (including the app-local-installation script) in the bugzilla request tracker, so I won't repeat that here.

Those .par files are binary distributions. I.e. you would have to make include the rebuilding of the .par's in the debian package build process for every architecture - at least if there are any XS modules.

This brings me back to a sore point: The debian PAR is waaay outdated. Since then, PAR was split into PAR (the .par loading part) and PAR::Packer (the packager part) since they're quite separate things. PAR is valuable for the user, PAR::Packer is for developers only. There have been on the order of ten releases for each module since the last debian package. I think this is blocking on somebody not updating (or passing on to debian-perl) a dependency of the modules.

HTH, Steffen

yeah, right."

An anonymous comment:

"Actually, the scary looking LedgerSMB install problem was that the user didn't have Module::Build installed. That dependency is noted in the INSTALL file as part of step 8, "Check Dependencies". Step 7, which is where configure_apache.sh is run, would never report that error as it does not invoke Perl."

Shouldn't the LedgerSMB install be able to check it dependencies? If using M::B means another thing for people to install because they can even start the installation, it's not where I want to go with simplifying Koha.

Another anonymous comment:

"Module::Build is one of the methods LedgerSMB uses to check for dependencies. There is also a Makefile.PL that uses Module::Install if you don't want Module::Build. Both options are primarily there as the semi- optional dependency checking stage. The 1.2 branch of LedgerSMB is not one where you would want to use either of their install functions.

We hope to have the LedgerSMB installation routines simplified in future branches, but we're still working on getting the codebase to a manageable state. I will, however, say that most non-Windows installation failures I've seen at this point have been people not reading the documentation."

Comment on this

2007-05-15 (Permalink): I've been smashing my head against this brick wall for a while and can't decide: is it possible to use MakeMaker or one of the other perl installers to install some modules and some cgi-bin scripts in one action? How?

Update: Tincho writes in How to recognise different types of trees from quite a long way away: About installing a complex perl web application

"In a nutshell, if you only want to process modules and CGIs, you can do it with MakeMaker"

Unfortunately, I think I have lots of templates and images, so I guess I really do need to do something sick and twisted if I want to use MakeMaker.

Jan Hudec commented:

"You can add your own make snippets into MakeMaker script and you can override the snippets generated, so you can do anything with it. The Module::Builder or Module::Install seem less hacky, but also less flexible. I could get MakeMaker preprocess with PDB and M4 and additionally build LaTeX document. I wanted to do that with Module::Build first, but it would take a LOT of programming there."

...so I guess MakeMaker is still my best tool.

Is there some web application that does this already?

No-one seems to know what's long, red, has four wheels and eats grass?

Comment on this
Start of this section
Start of this page
All topics

Koha at Crimea 2007

2007-06-29: On 13 June, Koha was presented to the Fourteenth International Conference: Crimea 2007: Libraries and Information Resources in the Modern World of Science, Culture, Education and Business by Sergey Dubik, V. Stefanik Lvov Scientific Library of the National Academy of Sciences of Ukraine, Lvov, Ukraine. The presentation PDF is online (tip from the author to koha list). It's in Cyrillic alphabet - which language is it in?

2007-07-03: Update: Alexander writes:

"It is in Ukrainian. Preface is in Russian, Ukrainian and English."

Comment on this
Start of this section
Start of this page
All topics

Koha Debian Packages

This email in French asks after my ITP Koha bug and mentions using the list of debian package deps to build most of the dependencies which I only finished building like 3 days ago. You wait ages for a koha/debian developer, then two come along at once.

Comment on this
Start of this section
Start of this page
All topics

A survey of OPAC wants

Dave Pattern has been conducting a survey of librarian views of their OPACs. He's posted the results to his opac-survey blog category and it might make interesting reading for other koha developers. Or maybe I'm just a survey nut.

Comment on this
Start of this section
Start of this page
All topics

Comment form for non-frame browsers.

Comments are moderated (damn spammers) but almost anything sensible gets approved (albeit eventually). If you give a web address, I'll link it. I won't publish your email address unless you ask me to, but I'll email you a link when the comment is posted, or the reason why it's not posted.