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.