| Subject: | Separate install/run modes |
I am considering to use PAR to create a package that can be installed on any non-Perl system (Win32 only). My reason for choosing PAR is that it can create non-monolithic packages as well. This way I can choose how the package will be run, be it with Perl.exe or a Perl interpreter embedded in my application.
Initially I was looking for something that could package all Perl modules together and then run them on a non-Perl system. Temporary files were out of the question. I quickly discovered that there are no solutions that avoid temporary files completely.
Given that temporary files must be created anyway, I thought why not make them a part of my application. The default of PAR is not to cleanup the temporary files after execution, which makes the files kind of permanent. While the files are permanent, there is no reason why I couldn't install them with my installer into my application directory, and make them really permanent!
This led me to the following idea:
Add a new PAR option that allows us to create "two-step" packages: The first step is a self-extracting package, much like the current packages, only it wouldn't be executed after unpacking. The goal of step 1 would be to create an installation image that can be copied to target systems as such. This image includes all files that are now written under the TEMP\cache directory.
The second-step is the actual execution of the package. This step assumes that all the modules exist as files (with the hashed names), and the only real functionality of PAR would be the redirection of the module names to these files. This way no temporary files would ever be created in step 2. The execution script would include only the code necessary to execute the package this way, leaving much of the current code out (like Zip and Zlip modules).
The only other needed option would be the path to the installation image (currently generated by _tempfile). This could be specified as a parameter to the execution script.
In fact, the first step doesn't even need to create a package, it could just create the target directory structure ready for copying. Creating an intermediate package might be a bit easier to implement in the current version.
What do you think? Is this too close to just copying module files from the Perl distribution and not using PAR at all???