Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

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

by swl (Vicar)
on Oct 15, 2021 at 23:06 UTC ( #11137612=note: print w/replies, xml ) Need Help??

in reply to PAR::Packer shebang + PAR::Heavy missing

Re-reading this I think I see what you are trying to do now (although not the full context). We probably need to see some code to show how you are setting things up.

For #1, there is no standard shebang. It is maybe clearer to call the script using the perl idiom as then you can be more sure of which perl is used. It's what I tend to do, but others will have different views.

For #2, PAR::Heavy is part of the PAR distribution. You should not need it in your script unless you are trying to use PAR archives packed using PAR::Packer. And even then it is simpler to just pack the whole script into a stand-alone exe and have the user call that. This is also one of the points raised by Marshall in 11137280.

What to do depends on details we have not been given but I'll list some possible options.

If you are distributing scripts for users to call then use pp on each system to pack self-contained executables. Then you don't need to worry about what version of perl is on each system, which version is in use at the time, or what non-core libraries are installed. If you have many scripts then it's easy enough to write a build script to pack a series of such files.

(This is more complex, probably more so than is necessary). If you are using a single master script to call others then you can pack each script as an executable or a PAR file, pack these with the master script (see the --addfile option for pp), and then have logic in your script that calls PAR files when it is run under PAR by testing for $ENV{PAR_0}. It can also conditionally require any PAR libraries in that case so non-PAR systems do not need them (e.g. something like use if $ENV{PAR_0} PAR). If $ENV{PAR_0} is false then call any scripts directly. An issue with this approach is that it requires duplication of any calling logic as there are now two ways of calling each file.

And just to note, files packed using pp --addfile ... can be found under $ENV{PAR_TEMP}/inc.

Replies are listed 'Best First'.
Re^2: PAR::Packer shebang + PAR::Heavy missing
by kaldor (Beadle) on Oct 17, 2021 at 18:51 UTC

    I've not given a lot of context, it's true : I'm trying to package a collection of Perl 5.8 scripts (actually the PerlPowerTools) as a single file, runnable anywhere and installable without knowledge of the Perl ecosystem (or with limited access rights).

    For Windows, the obvious solution is to build an executable (no issue encountered so far). For other systems (most of them come with Perl installed), I see two inconvenients in building an executable as you suggest : 1) small source scripts (1MB) turn into a big executable (10MB) and 2) a different executable would be needed for every possible CPU, right? Please correct me if wrong, that's not my area of expertise. I agree with you that an executable solves many issues, but in this case they are non-existent, because the scripts are pure old Perl 5.8.

    But maybe PAR::PAcker is not the right tool for that : what I did not understand is that an external PAR (not packed!) is needed to run a script packed with 'pp -P', and more confusion came because PAR seems to be shipped by default with macOS Perl and Strawberry Perl (even if not a core module). I thought the (uncompressed) Perl code present at the beginning of the packed file would be enough to extract the rest (Zip) transparently (again, please correct me if wrong).


      Is 10MB really that big these days? If that is the total size then I don't see the problem since none of your target environments seem to be resource limited. If it is 10MB per exe then size is something to be concerned about given the number of utilities (and a quick check indicates that's the case).

      You also aren't restricted to 5.8. PerlPowerTools has passes for many recent perl versions across a range of OSes on CPAN Testers.

      I guess a more general question is whether you need to use the perl variants of these tools given that they are likely to be available on the unix variants, and there are ways of getting them for windows through systems such as cygwin and msys2? Strawberry perl comes with at least some of these utilities under its c/bin dir, so you could distribute those as a start. If you can determine where they are sourced from then you can probably get more from there.

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (7)
As of 2023-02-05 14:57 GMT
Find Nodes?
    Voting Booth?
    I prefer not to run the latest version of Perl because:

    Results (31 votes). Check out past polls.