I don't know if this will ever become widespread, but I've occasionally found the need to include something other than the code in a script (e.g. an .exe as a helper, some image in a specific folder).
Currently, my approach is to encode the resource as Base64 and embed it in the code so the file can be generated at runtime. It works, but it's not very elegant since it adds a lot of bulk to the script package.
And although you can manually put resources in the .opusscriptinstall, there doesn't seem to be a clean way to have them extracted programmatically when the script is installed.
Maybe it would make sense to add support for this, so that exportkey.xml could contain a section referencing a resource within the same file, along with the path where it should be extracted (with support for Opus aliases such as /dopusdata or /dopusdata/User Data). When installing it, DOpus could also let the user know that the script wants to install some additional resources.
I think that would be a pretty clean way to handle it.
I know you could simply tell the user to download and copy the resources to a specific location, but from my own experience, what seems super easy to one person can be pretty confusing to someone else .
I'd love to hear what you guys think, both script users and authors.
(Seems you can actually add any file type there, FWIW, although I did not try it in depth or do anything beyond adding it in the UI and then cancelling the change. Maybe it's already possible, if you don't mind it being in the wrong category in the script editor. Having a section for "other" or "binaries" would make sense, either way, as a few scripts need those now.)
Yes, you can put stuff inside the .osp package, but that would be a bit different from what I was suggesting. It depends on what you want to store I guess and for what purpose, and it does have some drawbacks:
It still takes up extra space.
You can't run an .exe directly from there, so you'd need to extract it every time. (AFAIR, there's no way to programmatically extract it from the package itself without the user having some specific archive-related configuration.)
Instead, if the .opusscriptinstall could act as a kind of one-time deployer, with the ability to specify destination paths (and even create them if necessary), similar to how software installers work, that could make things much cleaner. No special UI would be needed. Authors could edit exportkey.xml directly and include the necessary files.
.