Include source and build paths vars in run scripts

[TheDuckCow]

This is coming back to the thing I keep mentioning which is the slowest part of trying to follow test driven development: running tests often is painful, as it takes several minutes to just put the addons in place. With the old system, all installs with the fast option would happen in less than 2 seconds.

In my experience and in doing some testing today, the real crux of the problem is a) the large size of blend files and b) the sheer number of (resource pack image) files being created for the zip. No matter what we do, zipping and unzipping all those files will be slow.

My proposal:

• In MCprep, we create a "fast" option that looks like this; this already works quite nicely and runs pretty fast. Thus bypasses the entire time spent on compressing and extracting the resources folder.

  build_actions:
  default: 
  script: "action-scripts/default.py"
  dev: 
  script: "action-scripts/dev.py"
  fast:
  script: "action-scripts/dev.py"
  ignore_filters: 
    - "*.blend"
    - "MCprep_resources"

• Then in bpy build, create a mechanism for "hooks" to be searched for and called from action-scripts, including "pre_removal" and "post_extract" (or whatever names you find best). These would be methods inside an action script which would have args for the source and target path for a single install. These functions, if found, would be called for each action during the corresponding spot.
• Then in MCprep's repo, we could then create an mcprep script under the action-scripts folder (in the MCprep repo) for the fast option (fast.py) which for the first hook (pre deleting existing install) would just move the MCprep_resources to a temp location, and then in the post_extract hook would move it back.

This is probably the simplest thing we could do and, from my standpoint, would be the #1 time saver pretty quickly while doing testing and PR reviews.

Let me know what you think @StandingPadAnimations! Open to other suggestions

[StandingPadAnimations]

Funnily enough I've already thought about creating a basic API for BpyBuild that exposes a couple of variables, namely:

• Project root (the folder where bpy-build.yaml is located`)
• Path of the current stage (we already set the working directory to this as well, but never hurts to have an explicit option)
• Config options (perhaps even allowing custom keys in `bpy-build.yaml)

In addition, for hooks I think we could have them take in a function instead, to make it a bit more flexible, similar to the Python map function.

[TheDuckCow]

The main thought I'm having about the function hooks is whether we have to do some funny things like assume for any given script it does have the given hook and just try/except pass if not, or if we want to do a more inherited class structure.

tbh I still vaguely question if we're over engineering the build system, so I'd personally be fine with the approach of having bpy builder assume each script has a given function and then just gracefully move on via exception if not. It does mean where we currently do subprocess.Popen() for the runner scripts we might want to not always run the whole thing via main and instead have each operation within a function and try to just import/directly call that function. Just an idea.

What do you think of that?

[StandingPadAnimations]

I'm personally not a big fan of looking for the existence of functions in files, it reminds me a bit too much of C. Of course. Overengineering is a good concern to have for when creating something like this, but I think we could get the best of both worlds if we keep things pretty simple.

For starters, BpyBuild could expose a few variables through a global dataclass. What I have in mind is the following:

@dataclasss
class BpyBuildProps:
    project: Path
    cwd_path: Path
    config: Config 

From there, we could have the following hooks, where each hook takes in a basic function of some type, and act like the register function in bpy:

• before_install: Runs before an addon is installed for each version
• after_install: Runs after an addon is installed for each version

In addition, although slightly unrelated, we could also add some basic report_error function for actions in general if something occurs that requires BpyBuild to stop and gracefully exit from building.

I believe with these 2 things, we could cover most use cases, while keeping things ergonomic and easy to maintain. What do you think?

[StandingPadAnimations]

Began working on this in api-addition, though opting to use reserved names like prebuild instead of explicit registration functions. This does make some breaking changes to script requires, notably main functions and if __name__ == "__main__" checks are required now. This is because the API imports modules dynamically, and Python executes all modules when they're imported.

The following hooks are planned:

• prebuild: before building the addon
• preinstall: before installing the addon for each version (ex. if an addon is installed in 5 versions, it'll run 5 times)
• postinstall: after installing the addon for each version
• postbuild: after building and installing

[StandingPadAnimations]

Alright, so I've gotten pre_build and post_install implemented. Now I just need to implement pre_install and post_build

[TheDuckCow]

Great, thanks for working on this!

[StandingPadAnimations]

Hooks have been added now, just need to work on some documentation for said hooks