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.

Packaging complexity (huge!) 9 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Packaging is still a hot item in perl5 land. A few projects have adopted the 'boxed' idea, where they ship a version of their project, along with all the depenendencies needed to bootstrap it and start working.

    This is of course not the type of thing you want to install as your production platform, but gets you testing/developing rather fast.

    Two such projects are Catalyst [catalystframework.org] with their Cat-in-a-Box [handelframework.com] and CPANPLUS [cpan.org] with the cpanp-boxed [cpan.org] tool that is shipped for bootstrapping purposes

    As far as packaging is conc

    • Thanks for the link to Debian CPAN packaging! I guess it will work on Ubuntu as well...

      I'll give it a shot A.S.A.P.!

      --
      $ pugs -M6 -e 'say "use 6 :)"'
      use 6 :)

    • Another worthwhile (and production-worthy) effort is the Shadowcat Catalyst installer [shadowcatsystems.co.uk], a script that sets up some magic and then drives CPAN.pm (and ppm, if necessary) programmatically so that you end up with a working Catalyst without any questions asked. Just fire and forget.

      I used to moan, bitch and gripe about Catalyst installation – but no more, ever since Matt published that script.

      Aside from that: debian.pkgs.cpan.org [cpan.org] is very cool.

  • So ignore your /usr/bin/perl and let Debian maintain it for you. Anything you do with CPAN is just going to muck it up anyway so you might as well just bite the bullet and install your own /usr/local/bin/perl where you *can* install from CPAN.

    • The parallel installation is a good idea, and it's the one I usually maintain in production (we have started using dh-make-perl and apt-get, and so far we are managing to keep everything in control, but our programs don't need more than 20 or 30 CPAN packages; Catalyst of Jifty use many, many more!)

      However this would only patch the problem, not solve it...

      I am thinking here (wild mindstorming with self in here) in a solution of managing complexity through layering: there's the CORE groups of packages (l

      --
      $ pugs -M6 -e 'say "use 6 :)"'
      use 6 :)
      • Er, wow. That's oodles more complex than I suggested. I suggested you sidestep the problem by having a completely separate perl install on your box. Instead of somehow simultaneously solving the packaging problem across CPAN, apt, and all other package systems (assuming you intend your solution to work on other OS distributions), you do an eensy bit of judo and go about your merry way without ever encountering a problem.

        Well.. you get to keep the minor problem that you can never say /usr/bin/perl to get to
        • Well, of course you are right...

          Starting all programs with a she-bang like "#! PATH_TO_PERL" and a good ole sed script on "make" or "make install" will solve the parallel installation `little problem', indeed!

          I just used the sudden inspiration of all these replies to let some brainstorming with myself... your post gave me the best anchor to actually rant it... :-)

          thanks and laters!
          --
          $ pugs -M6 -e 'say "use 6 :)"'
          use 6 :)
  • I should note that recently Catalyst has been putting a lot of work into this problem, and has reduced the quantity and complexity of the dependencies markedly.

    I'd have another shot at it again, if you haven't recently.

    Adam K
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.