in reply to 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
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

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.
  • Comment on Re^4: 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^5: 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 jethro (Monsignor) on Apr 06, 2011 at 15:14 UTC

    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

      Ah ok, I understand more now. I guess Python people have to make it this way, that they must go through this hassle of creating personal egg files for each platform and python version for each library dependency needed and then host them on their server for automatic download because they don't have many other alternatives like we have.

      I agree with all of your comments, in the end the CPAN way is much better and if I'm thinking correctly if you are providing the public with an application you can use Module::AutoInstall to provide the same CPAN automatic dependency download and installation during initial application setup, essentially the same but better than that mentioned with the eggs and Python

        files for each platform and python version

        See PEP 384 Defining a Stable ABI

        The idea is to phase this need out for as many modules as possible. It means using a restricted API though, and it will not be suitable for quite a few modules.

Re^5: 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 14:19 UTC
    Eh? Then we're back to commercial solutions, perl2exe, perlapp ... oh look, ppmx again , its the egg
      Sorry maybe there was a misunderstanding, apologies I meant never seeing for example an application written in Perl that you download and install and during the setup it automatically fetches PAR files of all the CPAN dependencies it needs and puts these somewhere that then when I run the application it just magically knows where and how to load these.

      But later in this thread it was made clear why no one would do it this way because you would need to create .par files for each supported version of Perl and for each platform for that dependency... pain in the neck :)

        Check out PAR::Repository and/or PAR::Repository::Client.

        More specifically, before discrediting PAR for what you want, you might want to read it's documentation. It contains this snippet:

        use PAR { repository => 'http://foo/bar/' }; use Module; # not locally installed!

        P::R::Client even has an auto-upgrade mode. Furthermore, for generating large sets of reusable packages, you can use PAR::Dist::FromCPAN or PAR::Dist::FromPPM.

Re^5: 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 tsee (Curate) on Apr 09, 2011 at 17:30 UTC

    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?

      Ok yes maybe you do see it in companies... I work in the open-source world and as I said have never seen this for Perl-based projects/apps/systems/servers that are publicly available.
Re^5: 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 InfiniteSilence (Curate) on Apr 09, 2011 at 18:33 UTC

    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

      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?

      Maybe you didn't see the synopsis for local::lib, but yes, there is such a tool, and its called cpan/cpanp/cpanm, local::lib isn't required or even necessary

      You can then simply copy/rsync the lib to your target machines.

      If you have rsync, compile install perl in your home directory, and simply rsync the entire perl tree

        Maybe you didn't see the synopsis for local::lib, but yes, there is such a tool, and its called cpan/cpanp/cpanm, local::lib isn't required or even necessary ...

        Maybe I'm a little slow on the uptake or something but I don't see how an interactive cpan client this solves the problem. I was saying that a good solution would be something that would work automatically -- that is, without human intervention -- to download and compile some specified list of modules and log all errors on a particular target system.

        Lots of times I get excited about a particular module until I get a list of target systems and then try to compile all of the existing modules and their dependencies. Sure enough, one or more of the modules' dependencies fails tests, so I need to roll up my sleeves and figure out whether the features that do not work are even going to be used. If not, I'll then see if I can get away with a forced install. Otherwise, I have to blacklist that module version for all of my target machines until the problem is fixed or I get around to fixing it.

        What would help in this process is to have a 'helper' that runs off and compiles my modules in a safe directory and logs all errors in a nice format OR tells me that everything compiled cleanly. This should happen, I'm guessing, once per night and should check for the latest versions of all of my modules before it does this.

        Now, specifically, how could I accomplish that?

        Celebrate Intellectual Diversity