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.
  • 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
    --
      ---ict / Spoon
    • 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 :)

      • 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 year
        --
          ---ict / Spoon
  • 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 T
  • The weblog application Movable Type [movabletype.org] 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.

  • 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.

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers