BpyBuild 0.5.1

Fix issue caught after the 0.5 release where using extension_settings::build_legacy, where the legacy build still ran with the extension action.

Full Changelog (Descending Order)

[0.5.1] - 2024-10-11

Fix: Make built-in extension action exit early when building legacy

Signed-off-by: Mahid Sheikh mahid@standingpad.org

Fix: Rebuild Api object when legacy building to avoid extension action

Signed-off-by: Mahid Sheikh mahid@standingpad.org

Chore: Update CHANGELOG.txt

Signed-off-by: Mahid Sheikh mahid@standingpad.org

BpyBuild 0.5

After several months of work, BpyBuild now supports Blender Extensions!

What's New

Caution

The minimum Python version has now increased from Python 3.8 to Python 3.9, as Python 3.8 is now end of life.

• Support for building extensions
  • Right now, this is opt-in, so the build_extension option needs to be set in the config

   build_extension: true

  • In BpyBuild 0.6, extension building will be the default
  • BpyBuild also has the ability to build legacy addons alongside extensions with extension_settings::build_legacy:

   extension_settings:
   	build_legacy: true

  Note that you may have to override the extension action to include patching for stuff like bl_info removal. Eventually this will be a automatic part of BpyBuild
  • is_extension has been added to the BabContext object, to make it easy for actions to tell if a project is being built as an extension or not
• First release of lib_bpybuild_ext, a BSD licensed implementation of the Blender Extension builder.
  • Due to Blender being GPL licensed, we can't include the upstream extension builder in BpyBuild, so we had to reimplement it from scratch
  • The reimplementation is based on the extension docs, so there are known parity issues.
  • If you encounter any parity issues, please make sure it's documented on the extension docs. If it isn't, update the docs to make sure it's mentioned. Unless it relates to security, we won't accept lib_bpybuild_ext contribuitons that implement undocumented features.
• depends_on has been added for actions. This allows defining that an action depends on other actions to run before it. For example, with the following config, using the depend_dev action will raise an error if dev either isn't passed as well or if it's passed after depend_dev

   build_actions:
   	dev: 
       	script: "dev.py"
       	ignore_filters: 
         		- "*.blend"
     	depend_dev:
       	depends_on:
         		- dev

Small Repository Update

BpyBuild is primarially developed by Mahid Sheikh. If you find BpyBuild to be an improvement on your workflow, please consider dropping a small contribution to Mahid (either through GitHub or Ko-FI), thanks!

Full Changelog (Descending Order)

[0.5] - 2024-10-10

Fix: Make depends_on check occur before module loading

Signed-off-by: Mahid Sheikh mahid@standingpad.org

Fix: Change action loading to account for additional actions

Signed-off-by: Mahid Sheikh mahid@standingpad.org

Fix: Make extensions only install in 4.2+

Signed-off-by: Mahid Sheikh mahid@standingpad.org

Fix: Resolve verification type checks caused by Python 3.8

Signed-off-by: Mahid Sheikh mahid@standingpad.org

Fix: Fix error with dataclass initialization

Signed-off-by: Mahid Sheikh mahid@standingpad.org

Fix: Use language-agnostic method for copyright validation

Signed-off-by: Mahid Sheikh mahid@standingpad.org

Docs: Add documentation on config options

Signed-off-by: Mahid Sheikh mahid@standingpad.org

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 mahid@standingpad.org

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 mahid@standingpad.org

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 mahid@standingpad.org

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 mahid@standingpad.org

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 mahid@standingpad.org

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 mahid@standingpad.org

Feat: Make extension building the default

Signed-off-by: Mahid Sheikh mahid@standingpad.org

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 mahid@standingpad.org

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 mahid@standingpad.org

Feat: Add validation for blender_version_max

Signed-off-by: Mahid Sheikh mahid@standingpad.org

Feat: Finished manifest verification and added build generation

Signed-off-by: Mahid Sheikh mahid@standingpad.org

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 mahid@standingpad.org

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 mahid@standingpad.org

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 mahid@standingpad.org

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 mahid@standingpad.org

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 mahid@standingpad.org

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 mahid@standingpad.org

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 mahid@standingpad.org

Chore: Update employment disclaimer

Signed-off-by: Mahid Sheikh mahid@standingpad.org

Chore: Add disclaimer regarding my employment

Signed-off-by: Mahid Sheikh mahid@standingpad.org

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...

BpyBuild v0.4.1

Minor release, mostly focusing on some quality of life improvements

New in this release

• Actions can now be defined without needing a script. This means purely ignore-filter actions are now possible to define.
• BREAKING CHANGE Actions now have restrictions on characters in names. See the updated docs for more info.
• The config parser has since been moved from cattrs to a custom, handwritten YAML parser.
  • As such, the cattrs dependency has been removed, and BpyBuild now has improved error messages for config errors.
• Version shorthands .. and + have been added, meaning config files no longer need giant lists of versions
  • Currently no documentation exists for them yet, but the test files may be used as reference.

Full Changelog (Descending Order)

[0.4.1] - 2024-06-04

Fix: Version jumps use strings for keys

Due to a weird bug when using Decimal keys, jumps would never properly
work. To work around this issue, we set the keys to be strings instead,
and convert the accumulator to a string

Signed-off-by: Mahid Sheikh mahid@standingpad.org

Fix: Install to newer versions of Blender first

Signed-off-by: Mahid Sheikh mahid@standingpad.org

Fix: Add / to allowed characters list for actions

Signed-off-by: Mahid Sheikh mahid@standingpad.org

Fix: Properly install addon if not already installed

Signed-off-by: Mahid Sheikh mahid@standingpad.org

Fix: Removed redundant argument in build_config

Docs: Added missing parts to signing off section

Signed-off-by: Mahid Sheikh mahid@standingpad.org

Docs: Added missing line breaks

Signed-off-by: Mahid Sheikh mahid@standingpad.org

Docs: Fixed DOC in sign off section

Signed-off-by: Mahid Sheikh mahid@standingpad.org

Docs: Added missing linebreak

Signed-off-by: Mahid Sheikh mahid@standingpad.org

Docs: Added warning for MCprep contributors

Signed-off-by: Mahid Sheikh mahid@standingpad.org

Docs: Clarify info on commits and type checks

Signed-off-by: Mahid Sheikh mahid@standingpad.org

Docs: Added details on name and file restrictions

Feat: Add version shorthands like + and ..

The idea of version shorthands is to reduce the need for comically large
config files with giant lists of versions. Instead of the following:

install_versions:
  - 2.8
  ...
  - 4.0

Developers can now do this:

install_versions:
  - 2.8..4.0

Way better for developer experience

Signed-off-by: Mahid Sheikh mahid@standingpad.org

Feat: Added string input checks

Seeing as build configs are basically untrusted user input, the current
system of not checking if the strings are valid is a pretty big security
risk. As such, BpyBuild now checks multiple parts of the config to make
sure that strings do not contain harmful characters, by limiting what
characters are allowed in the first place.

Feat: Improved errors for config issues

Feat: Added error handling for config parsing

Feat: Actions can now be declared without a script

Chore: Update dependencies

Signed-off-by: Mahid Sheikh mahid@standingpad.org

Chore: Update version to 0.4.1

Signed-off-by: Mahid Sheikh mahid@standingpad.org

Refactor: Changed how install_versions is checked

Previously we checked install_versions with a try-except statement that
would attempt to convert the value to a float and throw an error if it
failed. However, floats in YAML are actual floats, so we can just check
if the float is of the type float with isinstance(ver, float)

Refactor: Migrated from cattrs to manual parsing

Although cattrs was useful for parsing the config data to an attrs
object, it had issues with errors being undecipherable to the end user.
In addition, cattrs seemed too overkill for a simple config. Thus, we've
moved away from cattrs and implemented our own basic parser to manually
parse and construct the Config object, with better errors.

Style: Added docs for BpyError and BpyWarning

Style: Applied Ruff's import sorter to all files

Style: Updated codedocs

Style: Switch to native types with futures

Style: Added TypeDicts for annotation YAML data

Test: Remove xgettext-replacement test

Signed-off-by: Mahid Sheikh mahid@standingpad.org

BpyBuild 0.4

This version of BpyBuild adds an API and hooks. We've also revamped the documentation!

Check out the getting started guide here: https://github.com/Moo-Ack-Productions/bpy-build/blob/main/docs/getting-started.md

[0.4.0] - 2024-04-18

Fix: Add parent folder of script to sys.path

Docs: Redone readme and made Getting Started

Docs: added a getting started section

Docs: added info on argument-less main

Docs: removed working dir references in docs

Docs: added info on post_install in tests for todo

Docs: Added docs for Api object

Feat: added backwards compat for old actions

Feat: add path of missing file in error

Refactor: removed circular import

Style: Reduced indentation

Test: MCprep tests now download in parallel

Test: added MCprep tests for translation builds

Test: added tests with MCprep's source tree

Test: added proper check for post install hooks

Test: added test checking for non-existent configs

Test: added hooks test

Tests: added build tests

Tests: Modified actions to pass tests

Test: added basic test for help argument

Test: Moved test files

BpyBuild rewrite

BpyBuild has been completely rewritten from scratch to make it more ergonomic for developers.

Changelog (generated by git-cliff)

[0.3.0] - 2024-02-02

Fix: Fixed issue with not finding .X0 versions

Test: Added 2.8 to test file

[0.3.0-alpha-2] - 2023-12-19

[0.3.0-alpha-1] - 2023-09-03

Added support for auto-installing

Working on my birthday... sigh

Anyway, Bpy-Build now supports automatically installing to specific
Blender versions, either through the install_versions tag or the -v
argument. Now Bpy-Build's basic functionality has been returned, yay...

Also happy birthday to me ^_^

Changed actions to be Python based

Python based actions means less code to maintain on my end, and more
flexibility on the developer's end, win-win.

Now instead of forcing developers to use a limited subset of commands
and non-portable shell commands (curse you Windows), developers can now
define actions in Python like any regular Python script. No API, no
nothing, just the assumption that the script will be ran in the
intermediate directory.

Updated test recipe in Justfile

Changes to actions syntax

To make parsing easier, actions will now have the following syntax:
!action

This is not yet final, especially as I learn more on how YAML works, but
the final version will likely be simmilar.

Added basic argument parsing and attrs dependency

Since none of the existing libraries for argument parsing have quite
what I want, I decided to write my own argument parser in Python using a
class and attrs (https://www.attrs.org).

Why attrs instead of regular dataclasses? While dataclasses are based on
attrs design wise, attrs has the following advantages:

• Better defaults (good defaults are important)
• Fine control over the class, but nothing too complicated
• Version independence

The last one is important. Bpy-Build needs to support Python 3.9 and
above. Many good dataclass features meanwhile are 3.10+ however, which
means we are unable to use them. This discrepency in version support
will also only get wider as more time passes, hence why version
independence is so important.

Attrs does not have any runtime costs, it performs changes to the actual
class itself and Python bytecode, so the only costs are in Python's
compile time, most of which aren't massive (and likely improved in
Python 3.11 anyway)

While the class makes it seem like YAML will continue to be the config
file format, I'm still deciding between YAML and TOML

Updated pre-commit hook for Mypy

We forgot pretty printing and specifying the folder, whoops

First 0.3.0 Alpha

The first alpha of v0.3.0 is now ready! It's not available on PyPI, but you can build it from source.

Changelog represents all commits made between then and now

Changelog

[0.3.0-alpha-1] - 2023-09-03

Added support for auto-installing

Working on my birthday... sigh

Anyway, Bpy-Build now supports automatically installing to specific
Blender versions, either through the install_versions tag or the -v
argument. Now Bpy-Build's basic functionality has been returned, yay...

Also happy birthday to me ^_^

Changed actions to be Python based

Python based actions means less code to maintain on my end, and more
flexibility on the developer's end, win-win.

Now instead of forcing developers to use a limited subset of commands
and non-portable shell commands (curse you Windows), developers can now
define actions in Python like any regular Python script. No API, no
nothing, just the assumption that the script will be ran in the
intermediate directory.

Updated test recipe in Justfile

Changes to actions syntax

To make parsing easier, actions will now have the following syntax:
!action

This is not yet final, especially as I learn more on how YAML works, but
the final version will likely be simmilar.

Added basic argument parsing and attrs dependency

Since none of the existing libraries for argument parsing have quite
what I want, I decided to write my own argument parser in Python using a
class and attrs (https://www.attrs.org).

Why attrs instead of regular dataclasses? While dataclasses are based on
attrs design wise, attrs has the following advantages:

• Better defaults (good defaults are important)
• Fine control over the class, but nothing too complicated
• Version independence

The last one is important. Bpy-Build needs to support Python 3.9 and
above. Many good dataclass features meanwhile are 3.10+ however, which
means we are unable to use them. This discrepency in version support
will also only get wider as more time passes, hence why version
independence is so important.

Attrs does not have any runtime costs, it performs changes to the actual
class itself and Python bytecode, so the only costs are in Python's
compile time, most of which aren't massive (and likely improved in
Python 3.11 anyway)

While the class makes it seem like YAML will continue to be the config
file format, I'm still deciding between YAML and TOML

Updated pre-commit hook for Mypy

We forgot pretty printing and specifying the folder, whoops