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

use Perl Log In

Log In

[ Create a new account ]

excalibor (262)

excalibor
  (email not shown publicly)
http://praeter.blogspot.com/

Journal of excalibor (262)

Monday August 14, 2006
03:46 AM

Packaging complexity (huge!)

[ #30620 ]

The other day, the fine folks at Hiveminder announced his new site, made with Perl, using Jifty (http://use.perl.org/article.pl?sid=06/08/08/0249201).

I thought, let's have a look, and went to go for Jifty. It looks really cool! Maybe even as cool as Catalyst looks, yeah.

Holy cow! After three days fighting with CPAN modules, dependencies, failed tests, etc, I have given up.

It probably has to do with the packaging system of my GNU/Linux box and CPAN, which don't go along very well (I mean, there's a difference between doing aptitude install libtest-pod-perl and perl -MCPAN -e 'install Test::Pod', for example). The difference is that in the first case, apt is dealing with dependencies, paths, etc; in the former, it's CPAN, and they don't think the same way.

This is, of course, very frustrating. I had the same experience with Catalyst, and I also gave up (that's why I said that Jifty looks as cool as Catalyst looks, because I haven't been able to try none of them!

My rant is that these framworks are cool, and use a host of standard modules (in the CPAN sense) but they should be available 'batteries included'. I mean: you should not be so fragile as to be useless without all CPAN at hand.

I work behind a firewall, and CPAN access is, let's say, unconvenient. This may be the best of both worlds way of doing this: you offer the option of downloading a tarball with everything that's needed to get the framework going on, and then Makefile.PL (or Makefile, or another program) checks which of the CPAN packages it has downloaded within the tarball it really needs to install on the system.

This is the best of both worlds: I can make a Debian package from the tarball (carefully defining dependencies and so) and use apt to install the packages I am missing (so my system has track of paths, versions, and dependencies) or use CPAN from the local repository.

But I was not offer such a thing. Either it's available on debian packages or in CPAN tarballs, but I have to go fetching dependencies, and some fail (because I have something the way that package doesn't like) and I'm screwed.

So, what possibilities are there to simplify all these complexity so huge frameworks don't need a fresh system (maybe even compiled from the sources) to live happily in production boxes?

Will CPANPLUS solve this? Because if Perl 6 won't be able to benefit from CPAN easily (and I cannot, always, benefit from it by using Perl 5!) then neither Perl 6 nor these frameworks will have an easy path to success in the real world. Specially the web frameworks, with Ruby on Rails, Django, webpy, and all the Java frameworks out there...

(enough ranting, back to work)


List all Journal entries
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.