Extension Support

[StandingPadAnimations]

Blender 4.2 introduces the new Extensions System, which supersedes the old system for addons. As such, there is now a need for BpyBuild to adopt extension support, and work has started on https://github.com/Moo-Ack-Productions/bpy-build/tree/milestone-4-2.

Some things to consider:

• Backwards compatibility with old projects. Obviously we can't make everything extensions by default, at least not for 0.4.2
• Extension building. Should we use the Blender binary under the hood, or reimplement extension building ourselves?
  • Although the Blender extension builder (or more accurately, everything extension related) is written as a standalone Python script, it's licensed under GPL, so we can't include it in BpyBuild without relicensing, which opens a can of worms regarding the BpyBuild API
  • Reimplementing is our best bet, but we'd have to be careful to avoid copying the Blender builder too closely, again due to licensing. Although the Blender script is 3000 lines long, that's with all extension related commands; it's likely that the build command is much, much shorter
  • Alternatively, we could dual license BpyBuild under both GPL and BSD 3-Clause (the current license we use), but that has its own ramifications and is really a last resort
• Building extensions and legacy addons together. How would such a system look?
  • How would actions behave with combined building? Would we restrict actions to running once, or allow seperate actions for extensions and legacy addons?
  • How we go about this would also influence future plans for multi-builds (useful addons involving native code, where each OS has their own build) in general

[StandingPadAnimations]

Tagging @TheDuckCow

[StandingPadAnimations]

Ok, there might be a way around this, but it's a bit complicated. Basically, we'd create some sort of wrapper (that itself would be GPL licensed) with a custom interface that can be accessed with a more permissive license, such as through files or stdout. Since program output is not bound to GPL, this would be possible to use in BpyBuild without requiring a relicense. This doesn't solve redistribution though.

[StandingPadAnimations]

To make development faster, I'm just going to base what the docs say about extensions. I'm not going through a 4000 line that mixes HTML generation and creating a server, with building zip files and verifying the manifest.

I've already opened an issue as there are known requirements for the manifest that are missing from the docs. The way I see it though, if the docs don't mention it, it's not important for me to implement, and if it is important, IMO it's on the Blender Foundation to provide complete documentation (especially when extensions are brand new, they should be documented well).

[TheDuckCow]

Most free plugins will just use the legacy / offline install method, so I'm not overly concerned about this being the way to install MCprep. We can still adopt the extension format though.

If anything,I'm more likely expecting that we'd end up listing MCprep for free on the Blender Market, since they are planning to be an extension hsot for all plugins. I'd have to start paying for the minimum tier (need to double check how much that is) which is their offset for free products/to be a creator, but I don't think it's that much. It would not make really any sense imo to set up our own server, because then users just spend the extra time configuring this extensions server in blender for just a single plugin, when they could have already done the legacy install by that point (which is what will be realistic when first starting anyways).

[StandingPadAnimations]

It would not make really any sense imo to set up our own server, because then users just spend the extra time configuring this extensions server in blender for just a single plugin, when they could have already done the legacy install by that point (which is what will be realistic when first starting anyways).

Yeah BpyBuild won't be implementing server-side components (that would be a nightmare), just extension building and manifest verification. The main thing is BpyBuild won't have 100% feature parity, because we're now going purely off of documentation (eg. BpyBuild won't cap strings at 64 characters for example, because that's not a stated restriction in the docs). Granted, it'll cause some headaches, but the Blender Extension CLI script is extremely verbose...

[StandingPadAnimations]

Alright, pushed some basic manifest verification (https://github.com/Moo-Ack-Productions/bpy-build/commit/cd7faf726a68334e0e1a6344b163bae6212b93e5). Much less then what Blender does, but is technically correct based purely on the docs.

[StandingPadAnimations]

Pushed what is basically a finished extension building library (https://github.com/Moo-Ack-Productions/bpy-build/commit/9edaadbc6e9ef268c77a4823e5400f6563c94551), for addons at least

It's technically correct based on the docs, with these known parity issues (due to not being documented):

• lib_bpybuild_ext allows more then 64 characters for tagline and all permission explanations
• Blender allows ), }, and ] at the end of tagline, lib_bpybuild_ext considers this punctuation and so doesn't allow it. tagline will only allow English characters and numerical digits at the end
• lib_bpybuild_ext enforces the check for copyright info to be either YYYY Name or YYYY-YYYY Name, Blender doesn't (Note: attempting to upstream here)
• lib_bpybuild_ext doesn't have theme support yet, but when it does, it'll let you use what are clearly manifest values only meant for addons, because the docs don't state they're only for addons
• No server (never planned anyway, but in case we wanted to), because Blender doesn't document the general structure of an extension repo
• (Planned, maybe) Enforcing GPL on addons, because bpy is GPL, and there's no mention of an exception for bpy. Therefore, in order to not get in trouble with the FSF, we will enforce addons to be GPL (ironic, considering we wrote this to keep BpyBuild BSD licensed and not use GPL code)

[StandingPadAnimations]

That's one parity issue down, several more to go: https://projects.blender.org/blender/blender-manual/pulls/104844