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

Re^4: PAR::Packer shebang + PAR::Heavy missing

by kaldor (Sexton)
on Oct 15, 2021 at 20:54 UTC ( #11137604=note: print w/replies, xml ) Need Help??

in reply to Re^3: PAR::Packer shebang + PAR::Heavy missing
in thread PAR::Packer shebang + PAR::Heavy missing

After (much) more experiments, I've noticed that the result of 'pp -P' works fine between macOS and Windows (I can pack on a platform an run it on the other without problem, both ways).

On the Linux box where it fails to run, PAR::Heavy is not installed, so the error message is actually clear!
On my mac, PAR::Heavy is installed in both perlbrew (probably done by me) and system perl (not done by me, I think).
On Windows (Strawberry Perl), PAR::Heavy is installed by default (in perl\vendor\lib)

So, this module is not a core module, but apparently "most/many" Perl distributions install it, is it correct?
Should it also be present on the Linux server? I suspect it's not available because its dependency Archive::Zip fails to install.

Many thanks all of you for the advice so far.
  • Comment on Re^4: PAR::Packer shebang + PAR::Heavy missing

Replies are listed 'Best First'.
Re^5: PAR::Packer shebang + PAR::Heavy missing
by Marshall (Canon) on Oct 16, 2021 at 22:29 UTC
    Thanks for the update with your testing results!

    I have no idea of how many (percentage wise) of Perl distributions include PAR::Heavy. A Perl distribution will contain all of the CORE Core modules for that release (BTW: to my knowledge this list of CORE Core modules can and does vary between releases). A release may contain other modules past the CORE Core requirements.

    From what you describe, I presume that your code (main + modules) is completely pure Perl source code (no XS modules). Binaries are not compatible between Unix based systems (e.g. modern MacOS) and Windows.

    I distribute applications in 2 different ways.

    (1) For Windows end users: They get a single .exe file. That file contains everything that the user needs independent of whether they have Perl installed or not. Since this file contains the executable of Perl itself, it has to be built upon a Windows system. There cannot be any Perl version or library conflicts because everything is contained within this single .exe file. Typically these programs have a fancy GUI and I don't assume that the end user has read any of the documentation.

    (2) For sys admin level folks: I give them the source code. There might be half a dozen utilities and my modules which are used by those utilities. I haven't had the need yet to make an installable Perl package. The number of people involved is so small that I can talk to each user individually to get their installation "up and running". There is a bunch of documentation that comes with an application like this and I expect the user to read and understand the main documents before they try to do anything at all. This is completely different than "click on it" and "follow the program GUI" that an end-user on Windows gets.

    I guess you are trying to "split the baby" and be somewhere in-between these scenarios?

    In general, a windows user will not have Perl. Nor will they have any knowledge of the "command line". I haven't installed Strawberry Perl myself because I am a long time Active State user. Active State has ended support for their Perl Package Manager tool (ppm). This was nice GUI tool to add packages very quickly because they were pre-tested and it was guaranteed that all dependencies would be satisfied. In the place of ppm, you can create a custom Perl installation file that will include any extra modules that you wish (which actually compile and complete tests according to Active State rules). This can be an .exe or .msi file. You are allowed to re-distribute this file. You have to create a free account on the Active State site to do this, but I've done it. BTW, if you make a Perl installation like this, I strongly recommend adding cpan and cpanm to the build!

    A "partial executable, source code only" will work well if you are distributing code within your organization or close affiliates where you know what versions of Perl are being run. Be aware that the "system Perl" can be quite out of date versus the current release.

      A Perl distribution will contain all of the CORE modules for that release (BTW: to my knowledge this list of CORE modules can and does vary between releases). A release may contain other modules past the CORE requirements.

      Be advised of the differences between CORE and Core. Nomenclature matters.


        Thanks! Post updated.

      Please see my answer to swl for more general info Re^2: PAR::Packer shebang + PAR::Heavy missing

      You're right, I'm kind of targeting users between (1) and (2). I'm currently playing around with the PerlPowerTools, but on the long-term I'd like to find a way, as you say, to "share code within my organization or close affiliates". Most of them having - at best - basic command line knowledge and all of them having zero Perl knowledge (bad press excepted).

      I'd like to thank all of you for the time taken, and the quality of your answers. It's really nice to get help and hear other experiences.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11137604]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (3)
As of 2021-12-05 13:44 GMT
Find Nodes?
    Voting Booth?
    R or B?

    Results (31 votes). Check out past polls.