All the Perl that's Practical to Extract and Report

And another thing...

acme on 2002-07-11T20:21:44

Things I don't like: CPAN modules which depend on modules which aren't actually on the CPAN, modules that fail their own tests, modules without a Makefile.PL, modules that don't generate a Makefile, modules which compile C code during 'perl Markfile.PL', modules which require sane user input for configuration (ie not just return for every question). And that's just for starters. I've only done module distributions with names that match /^[U-Z]/. I'm sure I'll find some more as I go along... ;-)

Ah, maybe we need a guide

2shortplanks on 2002-07-11T21:27:15

Okay, maybe we do need a guide of how to write a module properly so it can be automatically installed.

I have an install script that installs all them modules I need at work and I do run into the same kind of problems.

Interactive modules are a pain. But what do we do about it?

  • By default don't ask questions? Not very userfriendly. What should we do about optional features?
  • time out after a few seconds of inactivitly (easy to implement for all concerned, but a pain in the rear if I'm not watching my computer like a hawk and I need to change some options)
  • Have an eviromental variable that can be set to provide data or say "accept all defaults" (the Template Toolkit way)
  • Have some form of config script that you can edit?
I was thinking the other day about writing a module based on Gravel. Now, as you know, gravel is a C module you can download and install from source from sourceforge. Now, if you've got LWP installed then I can download and install that for you (assuming you have a real computer with a real compiler installed)

Now the interesting questions:

  • Should I download it? What if it's already installed and I can't just find the header files for some reason. Should I ask now?
  • Should I ask before downloading? What if you're not online?
  • Is LWP a dependancy of this module, or is the ebuild (words I don't understand) of gravel a dependacy? Or both? Or one or the other?
See, it all gets really complicated really quickly.

Re:Ah, maybe we need a guide

acme on 2002-07-12T07:57:36

Well, I'm not going to try and change the world this week. I appreciate that it's not all as simple as it first seems, but what I'm going to concentrate on is getting CPAN in Gentoo. I already have a couple of workarounds and dependency additions etc., so I'm going to hack and slash until it all just works ;-)

After I've done that, we can go back and decide what would have made things easier for me and what the best solution might be. Of course, most talk about CPAN is just that - we need to get the module authors interested in it too or it'll never happen.

Re:Ah, maybe we need a guide

bart on 2002-07-17T12:11:16

Interactive modules are a pain. But what do we do about it? By default don't ask questions? Not very userfriendly. What should we do about optional features?

Why, command line options to "perl Makefile.PL", of course. Of course? Eh, the concept is there. I don't know how extensible it is, to use your own command line options.

if it works for apache...

TeeJay on 2002-07-12T12:59:25

I know when I have installed apache I have been able to avoid interaction with the make / install process, even when integrating SSL, Perl, etc.

some kind of option to use-default, use-env or use-file instead of interactions would be very useful. Does ABW's tool that installs TT do something along those lines?