Debug Build Support

[StandingPadAnimations]

This adds the ability to create a build of MCprep that can then be debugged using a debugger. Under the hood, this uses Microsoft's debugpy library, which is then installed into the Blender environment using the new wheels system introduced with Extensions (support for which has also been added).

This has been tested with VScode, but in theory should be editor agnostic. Some notes to be aware of:

• MCprep must be manually installed as a debug build, because installing extensions isn't supported in BpyBuild yet
• When using a debugger, the editor must be opened in the directory of the installed extension (ex. ~/.config/blender/4.2/extensions/user_default/mcprep/). Hopefully we can get this ironed out by either including some configs or having the debug action generate them on the fly.
• To build with debug support, run bab -b dev extension debug
• Additional configuration might be required. For example, with VScode, the following configuration needs to be used:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python Debugger: Remote Attach",
            "type": "debugpy",
            "request": "attach",
            "connect": {
                "host": "localhost",
                "port": 5678
            },
            "pathMappings": [
                {
                    "localRoot": "${workspaceFolder}",
                    "remoteRoot": "${workspaceFolder}"
                }
            ]
        }
    ]
}

• This is not yet documented as it's a pretty advanced development feature, there really isn't an easy way to document it (especially as something editor agnostic)

Closes #604

[TheDuckCow]

Just glancing through, I see this also represents embracing the new extension format. I gather that would mean needing to distribute two versions of MCprep right, one in extension format and one as a legacy addon?

[StandingPadAnimations]

We could if we want to, or we could keep using only legacy builds for production. For simplicity, we should just distribute legacy builds, but make sure extension builds keep working for debug build support or for users that want to build an extension instead.

[TheDuckCow]

Main reason for requesting change is to see if I can get the extension build to properly install the debuggy wheel. Same thing happens in 4.2 and 4.3, whether dragging and dropping to install the extension, navigating manually; and same popup appears when trying to manually enable the extension's addon after the extension is installed.

Other points are less important, figure we'd want to make sure this works cross platform, even though I personally probably won't end up using it much.

[TheDuckCow]

It's hard for me to accept but yes, I guess I really have been saying addon incorrectly all these years. Well at least it's better than Godot, which itself somehow references both addons and plugins as interchangeable in different contexts

[TheDuckCow]

We do need internet as well, since we have skin downloads for username and batch.

According to the foundation, we should even try to respect the blender preference for checking if internet access overall is turned on. They don't have a way to force require it, but something for us to contemplate having a popup instead of performing the action in case that setting is off.

[TheDuckCow]

For some reason, when I drag and drop the extension over, I still end up getting this error - any ideasl? Maybe due to being on an m1 apple silicon device, there isn't a wheel? not sure how I can easily debug it further

[StandingPadAnimations]

Strange, the macOS wheel should be universal across both Intel and Silicon. I'll take a look at the action

[TheDuckCow]

Not sure if this would be here, or better over in bpy build - but it feels very broken to allow for installing extension formatted addons into 4.1 and older. Maybe bpy build should have two different lists, one for extension supports and one for legacy addon? Or hard code that if using extension mode, only allow 4.2+ installs (could be a install version filter hook)

or, we could have some metadata where each action has a sublist in the yaml which defines something like compatibility minimums..? Just some ideas.

[StandingPadAnimations]

There are plans for BpyBuild to handle extensions properly (already implemented technically, but some things still need to be finished, such as building legacy addons and extensions at the same time). Compatibility minimums would be something interesting to add for 0.5

[TheDuckCow]

(Also, while not related to the v3.6.1 release, could be nice to merge by then I'd say since this seems pretty close otherwise)

[TheDuckCow]

Approved based on the wheel change we did for osx, knowing we might go a bit further in the future (I won't be using this mode in the meantime anyways)