On Fri, 20 Dec 2024 13:01:25 +0000, Darren Harwood wrote: > both create a self-contained, no-dependencies executable containing the > perl engine, required libraries and your source code. with optional > storage of things like resources (images, config files, whatever).
One of the reasons I stopped using this approach is that the resulting program (the binary that you send to the customer) can 'reach out' into the customer environment. It is therefore possible that the program accidentally uses a customer library (of a malicious or non-matching version). With the augmented ppl approach, the perl interpreter that runs the program is strictly constrained to the installed files only. @INC contains only the install directory. Also, it is easy to package the resulting program and its files using e.g. InnoSetup so that the customer only has to deal with a single click on a single file to install the application. Since a number of people here on the list have expressed their needs for such a feature it must be possible to combine forces and turn one of the approaches into a state of the art, robust and well-documented toolkit.