Option for installer-script per package, that is run after Reapack installed

[mespotine]

I would like to ask for a way to run an installer script right after ReaPack has installed my scripts on the user's computer, so I can do some preparations/setup that I can do only on the user's computer, not beforehand.

Lokasenna's Gui Lib needs a setup-script to be run before it can be used, which could be done during ReaPack update with such a script, so the user doesn't need to do it(and accidentally forget it) anymore.

My personal usecase would be the following:
When somebody installs Ultraschall-API, not everyone develops so not everyone needs my extensive html-docs. So I would like to be able to just generate them, if the user wants to right after the installation of Ultraschall-API using ReaPack.
That way, I just need to deploy my source-files but can omit the html-files and reduce the size of the installation-package by 14MB. So only the users needing my docs would get them generated.

Currently, I would need to have two index-files presented, one with the docs, one without, but this is too much hassle and therefore I install everything instead.

So a way to run an install-script(that gets immediately deleted after that) would be awesome for such tasks.

I'm not sure, whether it would be a good idea to have two options for it:

1. run directly after installation (for scripts)
2. run after next startup when ReaPack is loaded(for extensions that need Reaper restart)

[cfillion]

Why not provide the optional content as another package in the same index?

[mespotine]

For this particular usecase, making the docs optional would even work. However, I plan on doing some more customizable docs in the future, where I need the flexibility of a script and where an optional package would not help.
Let me give you three examples of usecases for an install-script for Ultraschall-API:

1. As many people prefer XRaym's approach for docs, I plan to make scripts, that generate the docs in XRaym's or my visual style. And they'll be able to switch between them.
   With an installer-script, I could create the design the users would want. They could even choose to use XRaym's approach for my Config-Var-docs but use my design for API-docs. Or the other way round, whatever works for them.
   There would be no way to create all possible combinations for doc-styles as optional packages, I can generate them only on the user's computer.
   I could limit it to either the one or the other one and people need to choose, which might work but only "once" but would take away flexibility.

2. The API-docs are huge. But not all functions are needed for everyone. In fact, I think that many scripters have their go-to-functions that they need time and again.
   So I plan on making custom-docs for that case. So people could choose to create a lightweight-documentation with just selection of api-functions or functions from certain use-case-contexts.
   Like "Create a docs with All Razor-Edit and All Marker-Functions in one docs cause that's all I need."
   Now, over time, new functions might be added or docs/descriptions might change.
   With an installer-script, I could update their docs to reflect that automatically.
   So if the devs add new marker-functions or razor-edit-functions or if I update docs(typos, etc) I update them in these custom-docs automatically with my install-script.
   This I couldn't do at all with optional packages, as there's no way to create all docs for all users in all combinations. I need to create and update them on the user's system.
   And I don't want to force them to do this manually, as stuff like this tends to be forgotten.

3. This one is total different usecase from the ones above, that could only be done with an install-script.
   When somebody wants to use Ultraschall-API, they have to type in a long and tedious line of

   dofile(reaper.GetResourcePath().."/UserPlugins/ultraschall_api.lua")

but what I would prefer is to give them the option of using

require("ultraschall_api")

instead, which is easier to remember and faster to type.

For this to work, I need to install a lua-file at a certain-destination.
For instance: ResourceFolder/ultraschall_api/init.lua in portable installations on Windows.
With ReaPack, I can not do this, as I can only access many subfolders in the resource-folder but not add a new one on my own and install a file exactly there.

I had thought about asking you for this option in ReaPack when I realized, that the position of the init.lua file depends on the operating system Reaper is running on AND if it's installed portable or not.
Means, the folders Lua is looking for the init.lua-file differ on each platform and by portable vs stationary installation.
So with portable installations on Windows, I can do it as above.
But on Mac and Linux, the file must be positioned in another place which becomes messy. And even when it's installed as portable, this location changes.

So, I would like to place them using an install-script in the appropriate locations so users could use require("ultraschall_api") on all systems regardless.
I tried to find another way, but I couldn't, so I either let users do stuff by hand or keep them do dofile in the future.

Sure, most of these use-cases could be solved by inidividual solutions one way or another but all of them I could solve with an install-script the exact way I need to do this to not bother the user.

I also have plans for future repos, that have even more different usecases for such an install-script(but their development isn't far enough yet to describe these usecases properly).

I have tried to workaround this stuff with other ways, but everytime I think about ways, I end up with the same idea of "this should be done while ReaPack-installation by me using an install-script while Ultraschall-API is installed to not bother the user with additional management they have to do by hand".

(Sorry for the overly long reply... 🙈) )