Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Application Distribution (modules, cpan, etc)

by jettero (Monsignor)
on Feb 17, 2007 at 22:18 UTC ( #600642=perlquestion: print w/replies, xml ) Need Help??
jettero has asked for the wisdom of the Perl Monks concerning the following question:

What do you do for application distribution?

I wrote a semi-fancy gizmo that uses Convert::ASN1 to decode ASN.1 documents into a special proprietary format that our billing system can read. It's a pretty slick little app, but it has been unfortunately and prohibitively difficult to distribute to the different telcos we work with.

I was using PAR so I could distribute a single file — and simply failed to mention how complicated the distribution really was. I ran into terrible trouble trying to run it with Wx when I had run the PAR on an XP machine and tried the resulting .exe on NT, but it technically functioned other than that.

Right up until I hit a strange bug in PAR. Well, I think it was a bug. Certain data in the input TAP files was casuing my application to crash terribly, but only when it was PAR packed. I never did track it down, but Mr. Tang was willing to believe it might be a bug at the time.

In the end I kinda gave up on PAR, despite enjoying how well it normally works; and I now have to log into the different servers, install activeperl, and use ppm to install the whole world (so to speak). It takes quite a while to do, but it's worth it because the app is slick.

Similarly, we have dozens of servers running gentoo. Gentoo would be a particularly poor choice for servers if it wasn't for build hosts. You can build everything just the way you like it in one place and push all the packages out over NFS or even FTP ...

The huge array of perl modules I like are a problem under Gentoo though. Their perl module tree is hopelessly out of date (because it's 10,000 files and 10,000 maintainers), so I hand-crafted an ebuild (named dev-perl/jets-favorites) that stuffs all my favorite modules into a single portage package that I can distribute from my build host. It works pretty well, but it'd be a maintenence nightmare if I wasn't such a die-hard perl nerd.

Non Perl people tend to not like (or even sometimes dread) the CPAN shell. They tend to stick with a raw Perl install, or whatever hopelessly out of date modules come with their OS of choice. The active state PPM installer is really nice — iff you can find a repo or two that you like.

But no matter how you look at it, if you write something using tons of the latest modules from CPAN, you can't reasonably distribute it to average Joe computer users. They're either not capable or not willing to fart around with CPAN or PPM for an hour to get your little program working. (Sometimes it seems they consider clicking [next>>] a hardship.)

Is there some solution for this? or is PAR the only answer for now? How do you handle this problem? Do you even consider it a problem?


  • Comment on Application Distribution (modules, cpan, etc)

Replies are listed 'Best First'.
Re: Application Distribution (modules, cpan, etc)
by rinceWind (Monsignor) on Feb 18, 2007 at 09:49 UTC

    This is a subject of a talk I have given at 2 YAPC conferences: Packaging Perl Applications

    Regarding PAR, Steffan Mueller has taken over the distribution, and done much in the past 6 months; I believe he may be lurking in the monastery. There's also a very active mailing list, and I recommend posting your bug reports there.


    Oh Lord, won’t you burn me a Knoppix CD ?
    My friends all rate Windows, I must disagree.
    Your powers of persuasion will set them all free,
    So oh Lord, won’t you burn me a Knoppix CD ?
    (Missquoting Janis Joplin)

Re: Application Distribution (modules, cpan, etc)
by tsee (Curate) on Feb 18, 2007 at 10:42 UTC

    rinceWind is right. I kind of took over PAR from Audrey since it was in danger of bit rot. Since late 2005, almost all parts of the PAR/PAR::Packer code have been touched one way or another. This is largely due to great cooperation from the PAR mailing list.

    May I ask when you reported the bug? Have you filed an RT ticket? If you did, did I get back to you? I would hope so, at least.


      The reason I never figured out the bug is that it took an absolutely enormous proprietary and secret input file to produce the problem. It would have been enormously difficult to locate and reproduce the problem since it's difficult to edit ASN.1 files by hand and it's even more difficult to get the right string of bits in the right order in the encoded file...

      I was all set to try to figure it out right up until most of the telcos we work with approved the installation of activeperl on the related machines. It's been a couple years. If you changed most of the packer I betcha it would take a different input file to produce the problem — if it's even a problem anymore.


Re: Application Distribution (modules, cpan, etc)
by geekphilosopher (Friar) on Feb 18, 2007 at 08:16 UTC
      I've been meaning to look at that for some time now, but thanks to your gentle nudge, I've applied for their student pricing. Thank god I'm a student... $250 seems a little steep (vs $50). On the other hand, I don't know how cool it is yet — it might just be worth it.

      Update: If you are a perl fan, frustrated by distribution unto the windows platform, this product is completely worth the $250. I've been using my student licensed copy for about four hours and I have already gotten $200 worth of use out of it. I'm likely to re-license this product, or look for a more comprehensive package later on. I'm really impressed.

      And to NatureFocus, below: Yeah, I could have, but I tend to dislike trial editions and the student price was very low, so it was completely worth jumping in headfirst. Had I not paid money for it, I probably never would have actually tried it out.


        I believe they have a 21 day free trial. They may also be in BETA test for version 7 which is free for testing. I have been using Komodo 4.0 for a while and have been pretty happy with it.

Re: Application Distribution (modules, cpan, etc)
by klekker (Pilgrim) on Feb 18, 2007 at 11:19 UTC
    I've got the same problem: I'm admin for some clients and servers running debian and ubuntu.

    For the perl scripts I wrote I need cpan modules and some self-written modules (which are still often edited) on every machine. I ended up installing them on a nfs share that is mounted to every client so that I have only one location to install my modules. So far at least for the pure perl modules.

    For cpan modules I try to use (debian|ubuntu)-packages containing the cpan modules I need, like libconfig-general-perl or libpod-simple-perl. But these packages don't exist for every cpan module. But until today I found all I needed there.

    After I read your article I hope I can give PAR a try when I am less busy. Sounds neat and perhaps it will be enough for my needs.

Re: Application Distribution (modules, cpan, etc)
by DrHyde (Prior) on Feb 19, 2007 at 10:55 UTC
    I maintain a perl application - rsnapshot - which works on a vast number of platforms. Off the top of my head, I know we have users on Linux, *BSD, OS X, Solaris, Irix, HPUX and AIX, and I expect there's a few others too.

    Our standard distribution is a tarball. We then use autoconf and make. Autoconf may be an utter swine, but it works, although if it had been my project from the start we'd use something else - probably a small perl script. Now, we deliberately avoid all third-party modules precisely because of problems that real users (as opposed to perl people) have with getting them to work. If we were to ever rely on someone elses module, we'd bundle it in the tarball, and install in a private .../lib directory.

    I would consider PAR, except that from the docs it seems that I'd need to create a PAR package for each platform, on that platform. That, and PAR doesn't install on one of my main development machines.

      Come on, give me a break. Would you expect to be able to use a DBI which you compiled on linux/x64 to work on Windows/32bit? I don't think so.

      Short of cross-compiling all module dependencies (forget I even said that), there is no way to get any C application to work on a foreign platform. XS modules fall into that category.

      That said, you can build a .par archive of all pure-perl dependencies and that package will work on any platform.

      If your application does not have non-core XS dependencies, you can even use pp's -P option to create a portable perl script with all non-core dependencies embedded. It should subsequently be runnable with a stock perl.

      Additionally, if you build an ELF executable using pp on linux/32, it should work whereever 32bit ELF executables do. By the way: I tried making a binary from rsnapshot. It took about 30 seconds including the download. Of course, I already had PAR::Packer installed.

      As for PAR not installing on your dev machine: Please write to the PAR mailing list about that. We're committed to make PAR work on almost any system.


        cross-compiling all module dependencies (forget I even said that), there is no way to get any C application to work on a foreign platform. XS modules fall into that category.

        This is partially false. While I don't believe it's reasonable or worth the time to cross-compile perl modules, as I think you'd end up arguing with Module::Build and ExtUtils::MakeMaker more than anything else — it is possible to reliably cross-compile all sorts of things. I used to maintain a 3d bumpercars type game (with spaceships) that was never finished (of course) that pulled in SDL/GL and various other things and compiled for ELF and win32 from a single platform.

        Should you choose to do so, you'll find tons of documentation and support for cross compiling under many platforms.


        Come on, give me a break. Would you expect to be able to use a DBI which you compiled on linux/x64 to work on Windows/32bit? I don't think so.
        Which was, in fact, my point. PAR doesn't help. Additionally, it isn't obvious how to use PAR to do things like install an example configuration file in /etc.

        autoconf and tar, on the other hand, do help.

        And the problem with PAR not installing - this is a bog-standard Debian box, with compilers and whatnot. I can't be bothered with subscribing to a mailing list just to report a bug on what is probably the most common platform, especially when it's a bug in software that isn't even particularly useful to me.

Re: Application Distribution (modules, cpan, etc)
by fenLisesi (Priest) on Feb 19, 2007 at 13:28 UTC
    This may not be the direction in which you have started, it may be considered off-topic and it may not be applicable to your particular case, but I would like to mention that for some application types and target environment sets, freely available VMware tools present an appealing distribution alternative. Cheers.
Re: Application Distribution (modules, cpan, etc)
by andye (Curate) on Feb 19, 2007 at 12:34 UTC
    Just a thought - and not something I've done myself - but could perlcc be useful here? best, a.
      but could perlcc be useful here?

      I don't think so. The Perl 5 porters have already decided against the maintenance of perlcc and other tools like JPL. Then what remains is the sound advice by diotalevi in this message to p5p:

      perlcc doesn't work well in any version. You probably want to consider PAR instead.

      and this explanation by 5.9.4 pumpking, Rafael.

      The bytecode compiler and loader and the C compiler were removed because it's a hassle to maintain, they don't work well, didn't match their promises, and are superceded by other solutions (like PAR).

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://600642]
Approved by ChemBoy
Front-paged by McDarren
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (5)
As of 2017-03-25 12:42 GMT
Find Nodes?
    Voting Booth?
    Should Pluto Get Its Planethood Back?

    Results (311 votes). Check out past polls.