Skip to content

Commit

Permalink
Merge pull request #20 from Moo-Ack-Productions/milestone-5-0
Browse files Browse the repository at this point in the history
Milestone 0.5.0
  • Loading branch information
StandingPadAnimations authored Oct 10, 2024
2 parents 802e924 + 000ea81 commit 637494f
Show file tree
Hide file tree
Showing 41 changed files with 1,604 additions and 157 deletions.
2 changes: 2 additions & 0 deletions .github/FUNDING.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@
github: StandingPadAnimations
ko_fi: standingpad
4 changes: 3 additions & 1 deletion .pre-commit-config.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,9 @@ repos:
"rich==13.7.0",
"typeguard==4.1.5",
"types-pyyaml==6.0.12.11",
"GitPython==3.1.43"
"GitPython==3.1.43",
"tomli==2.0.1",
"packaging==24.1"
]

- repo: https://github.com/astral-sh/ruff-pre-commit
Expand Down
2 changes: 1 addition & 1 deletion .python-version
Original file line number Diff line number Diff line change
@@ -1 +1 @@
3.8
3.9
232 changes: 232 additions & 0 deletions CHANGELOG.txt
Original file line number Diff line number Diff line change
@@ -1,6 +1,238 @@
# Changelog


# Changelog

## [0.5] - 2024-10-05


### Fix: Make depends_on check occur before module loading

Signed-off-by: Mahid Sheikh <[email protected]>
### Fix: Change action loading to account for additional actions

Signed-off-by: Mahid Sheikh <[email protected]>
### Fix: Make extensions only install in 4.2+
Signed-off-by: Mahid Sheikh <[email protected]>
### Fix: Resolve verification type checks caused by Python 3.8

Signed-off-by: Mahid Sheikh <[email protected]>
### Fix: Fix error with dataclass initialization

Signed-off-by: Mahid Sheikh <[email protected]>
### Fix: Use language-agnostic method for copyright validation

Signed-off-by: Mahid Sheikh <[email protected]>


### Docs: Add documentation on config options

Signed-off-by: Mahid Sheikh <[email protected]>


### Feat: Add depends_on for actions

This allows defining actions that require previous actions to execute
beforehand, like debug actions for specific build configurations.

Signed-off-by: Mahid Sheikh <[email protected]>
### Feat: Add --build-extension-only flag

This allows building only an extension. We don't have one for legacy
builds as we can't easily do that.

Signed-off-by: Mahid Sheikh <[email protected]>
### Feat: Add legacy building to BpyBuild

This allows addons that need to support both extensions and legacy
builds to create both in one go, thus reducing the amount of work
needed to support both older and newer versions of Blender.

Signed-off-by: Mahid Sheikh <[email protected]>
### Feat: Only load modules that are passed in the CLI

This is mostly to make debugging BpyBuild with MCprep slightly
easier, and make it slightly faster overall

Signed-off-by: Mahid Sheikh <[email protected]>
### Feat: Add is_extension to BabContext and compatibility checks

This wires the new compatibility checks in lib_bpybuild_ext to BpyBuild
itself. In addition, this also adds the new is_extension variable to
BabContext in order to make it easier for actions to determine when an
extension is being build

Signed-off-by: Mahid Sheikh <[email protected]>
### Feat(ext): Add the ability to check for compatibility issues

This is to make it easier for developers transitioning from legacy
addons to extensions to find and fix known compatibility issues with
extensions in legacy codebases.

Signed-off-by: Mahid Sheikh <[email protected]>
### Feat: Make extension building the default
Signed-off-by: Mahid Sheikh <[email protected]>
### Feat: Add basic extension building to BpyBuild

This adds the ability to build extensions in BpyBuild, if
build_extension is enabled in the config. At the moment, this does not
handle legacy building.

Signed-off-by: Mahid Sheikh <[email protected]>
### Feat: Return Path in build_ext

Since we need the path in BpyBuild in order to do operations such as
installation, we'll return the path in build_ext

Signed-off-by: Mahid Sheikh <[email protected]>
### Feat: Add validation for blender_version_max

Signed-off-by: Mahid Sheikh <[email protected]>
### Feat: Finished manifest verification and added build generation

Signed-off-by: Mahid Sheikh <[email protected]>
### Feat: Add basic manifest verification

This implements manifest verification solely based on the Blender
documentation, so that my sanity doesn't dip -10. This means that
LibBpyBuildExt will no longer have 100% parity with the Blender
extension builder, at the cost that we can develop this much faster.

The exception to this is for security related checks, such as
blacklisting certain control characters.

Signed-off-by: Mahid Sheikh <[email protected]>
### Feat: Add beginnings of lib_bpybuild_ext

lib_bpybuild_ext (otherwise known as LibBpyBuildExt) aims to be a BSD
implementation of the Blender Extension builder in order to allow
BpyBuild to implement extension building. The goal is to implement 100%
feature parity with the Blender Extension builder, down to verification
checks.

Although ideally we should get this done soon, we're not really in any
rush since MCprep won't move to extensions for a good while. However,
without this, BpyBuild can't implement extensions, so we should try and
move as fast as possible.

Signed-off-by: Mahid Sheikh <[email protected]>
### Feat: Add 4.2+ check when building extensions

Extensions are a 4.2+ feature, so obviously addons that build extensions
should include 4.2 or above in the range of supported versions.

Signed-off-by: Mahid Sheikh <[email protected]>
### Feat: Enforce string restrictions on extension_settings::build_name

`build_name` has string restrictions enforced on it, so for
consistency, `extension_settings::build_name` also has string restrictions
enforced on it.

Signed-off-by: Mahid Sheikh <[email protected]>
### Feat: Add extension_settings::remove_bl_info

This is intended for developers building both an extension and legacy
addon. The idea is that BpyBuild will be able to remove the `bl_info`
dictionary when building an addon as an extension, if and only if the
developer also has extension_settings::build_legacy enabled (otherwise
what's the point?).

This feature is planned to be opt-in, as it involves modifying an
addon's source code. However, perhaps at some point we could possibly
make it the default for building extensions with
extension_settings::build_legacy enabled

Signed-off-by: Mahid Sheikh <[email protected]>
### Feat: Add config options for Extensions

Blender 4.2 recently introduced Extensions to replace the old legacy
addons. As a starting point to support Extensions, this patch adds the
needed config options to support Extensions. These new config options
are:
- build_extension [bool]: the switch to enable extension building
- extension_settings::blender_binary [str]: the path to the Blender
binary needed to build extensions (4.2+)
- extension_settings::build_legacy [bool]: the switch to build a legacy
addon alongside the extension
- extension_settings::build_name [str]: an optional alternative name for
extensions. By default however, we plan to do[build_name]-extension

It should be noted that this patch exclusively adds new config options,
the actual building of extensions is not supported yet. In addition, the
current roadmap for extension support involves the developer passing in
the direct path to the Blender binary, which isn't ideal for versions of
Blender from the Microsoft Store, Snap repo, and Flathub. Perhaps we may
implement our own extension builder.

Signed-off-by: Mahid Sheikh <[email protected]>


### Python: Update minimum support to Python 3.9

The update to Python 3.9 is for several reasons:
- Python 3.8 will be EOL in October
- Python 3.9 introduces better type annotations
- We don't want to be behind with dependencies

Signed-off-by: Mahid Sheikh <[email protected]>
### Chore: Update employment disclaimer

Signed-off-by: Mahid Sheikh <[email protected]>
### Chore: Add disclaimer regarding my employment

Signed-off-by: Mahid Sheikh <[email protected]>


### Refactor: Move list of actions to execute to Api object

By doing this, we can add our own built-in actions at runtime trivially,
without much extra effort

Signed-off-by: Mahid Sheikh <[email protected]>
### Refactor: Move manifest verification to built-in action

With the actions system we have in BpyBuild, it's actually easier to
make an action that performs manifest verification in the main hook.
This way, we get pre-build checks for free.

Signed-off-by: Mahid Sheikh <[email protected]>
### Refactor: Remove build_ext

Building extensions is simple enough, the more important part is
validating the manifest and performing extension checks.

Signed-off-by: Mahid Sheikh <[email protected]>
### Refactor: Replace sys.exit calls with exit_fail

To avoid typing so many characters and repeating ourselves, this patch
adds util.exit_fail, which is equal to sys.exit(EXIT_FAIL), but in an
easier to type fashion.

Signed-off-by: Mahid Sheikh <[email protected]>


### Style: Add proper name-spacing to extension errors

Signed-off-by: Mahid Sheikh <[email protected]>


### Tests: Add test for depends_on

Signed-off-by: Mahid Sheikh <[email protected]>
### Tests: Add legacy building test

Signed-off-by: Mahid Sheikh <[email protected]>
### Tests: Add test for regular extension building

Signed-off-by: Mahid Sheikh <[email protected]>
### Tests: Add manifest files to tests

Signed-off-by: Mahid Sheikh <[email protected]>
### Tests: Add new test dirs for extensions and legacy building

Signed-off-by: Mahid Sheikh <[email protected]>


## [0.4.1] - 2024-06-01


Expand Down
44 changes: 41 additions & 3 deletions bpy_addon_build/__init__.py
Original file line number Diff line number Diff line change
Expand Up @@ -27,11 +27,16 @@
# OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

# Disclaimer: This is not a product from VLK Architects or VLK Experience Design,
# nor is this endorsed by VLK Architects or VLK Experience Design

from __future__ import annotations

import copy
from decimal import getcontext
from typing import Optional

import attrs
import yaml
from rich.console import Console

Expand Down Expand Up @@ -63,18 +68,51 @@ def main() -> None:
with open(cli.path, "r") as f:
data: ConfigDict = yaml.safe_load(f)
config: Config = build_config(data)
api: Api = Api(config, cli.path, cli.debug_mode)
api: Api = Api(config, cli, cli.debug_mode)
context = BuildContext(cli.path, config, cli, api)

if cli.debug_mode:
console.print(context)
if cli.debug_mode:
console.print(context)
if not cli.path.parent.joinpath(config.addon_folder).exists():
print("Addon folder does not exist!")
return

build_path = build(context)
install(context, build_path)
hooks.run_cleanup_hooks(context)

# Build legacy addon alongside extension
#
# To reduce as many issues as possible, we
# treat this as if it were a separate call
# of BpyBuild but with an altered config
if (
(config.build_extension and config.extension_settings is not None)
and config.extension_settings.build_legacy
and not cli.build_extension_only
):
# Remove extension action in a copy
# of additional_actions
additional_actions = copy.deepcopy(config.additional_actions)
if "extension" in additional_actions:
additional_actions.remove("extension")

override_config = attrs.evolve(
config,
build_name=config.build_name + "_legacy",
build_extension=False,
extension_settings=None,
additional_actions=additional_actions,
)

# Change the context object. This is fine
# since this is ran last
context.config = override_config

build_path = build(context)
install(context, build_path)
hooks.run_cleanup_hooks(context)


if __name__ == "__main__":
main()
Loading

0 comments on commit 637494f

Please sign in to comment.