in reply to Re: Why is it in some other popular languages fewer steps and potential issues when installing libraries no testing needed and no compilation of C/C++ code done
in thread Why are other popular languages very different from Perl when installing libraries, e.g. no testing needed and no compilation of C/C++ code done

Oh yes thank you for reminding me, I should have remembered that one can get rpms, apt packages and other means to get binary packages.

Just throwing out an idea: is there a way in Perl like I have described in Python to, in a universal way, create binary packages of CPAN distros yourself and package them into one file and that these can be used by Perl without having to unpackage the file? The ones listed are all very particular to different types of OS. Maybe this should be invented for Perl to make things easier for beginners and dependency management. Maybe PAR?

  • Comment on Re^2: Why is it in some other popular languages fewer steps and potential issues when installing libraries no testing needed and no compilation of C/C++ code done

Replies are listed 'Best First'.
Re^3: Why is it in some other popular languages fewer steps and potential issues when installing libraries no testing needed and no compilation of C/C++ code done
by Anonymous Monk on Apr 06, 2011 at 13:44 UTC
[reply]
[reply]
      Ok, yep I mentioned PAR... but another just another silly question and please pardon me if I just haven't seen the right apps, I just have never seen any major app written in Perl that uses PAR to provide easy one file packaged CPAN library dependency management, my apologies but when you don't see anyone using it for such a purpose you are wary of doing it yourself. In Python these eggs are very common.
[reply]

        The disadvantage of prepackaged bundles like eggs or par files is that maintainers have to provide one for every target machine or sometimes even distribution.

        On the other side (the user side) I think perl users are accustomed to cpan, they usually see no reason to look for PARs, maybe with the exception of windows users. Why change when the current system works?

        A really sore point about cpan is that it may conflict with perl packages installed by a distribution. Other than that there is nothing complicated about it, maybe only that there is no GUI (that I know of) for newbies

[reply]
        Eh? Then we're back to commercial solutions, perl2exe, perlapp ... oh look, ppmx again , its the egg
[reply]

        Having maintained PAR for five years and written quite a large chunk of the PAR-related tools, let me tell you that it's just not true that PAR is not used for packaging large applications. People from quite a few large and well known companies have contacted me directly for (free and private, sigh) support over the years. At least one of them mentioned that he was using PAR to deploy applications to ~40k computers in the corporation.

        Personally, I have packaged applications with a few hundred thousand lines and many, many CPAN modules (Perl & XS) successfully for multiple operating systems.

        Is this sufficient?

[reply]

        Here's a wild thought -- isn't there a single, easy-to-use tool that will automatically download, test, and install Perl modules for a particular environment like App::Magpie does for Mageia Linux, but using something like local::lib? You can then simply copy/rsync the lib to your target machines.

        If this could run in the background, find the latest versions of desired Perl modules, and log error reports somewhere it would satisfy corporate/organizational needs because groups of people who care about fast installs tend to be using the same computing environments.

        Celebrate Intellectual Diversity

[reply]

In Section Seekers of Perl Wisdom