feat(blender): Add plugin sync to 5.0 and fix OS detection in 5.1

[godobyte]

What was the problem/requirement? (What/Why)

Two issues addressed in one commit:

1. Blender 5.0 had no plugin sync support. The blender-5.1 recipe shipped activate/deactivate hooks plus an auto-enable startup script in PR #215. Blender 5.0 was left without those hooks, so customers on 5.0 couldn't use the simple-plugins delivery mechanism for their addons.

2. Latent OS-detection bug in the 5.1 activate script. The original Windows check was:

   if [ "$(uname -s)" = "MINGW"* ] || [ "$(uname -s)" = "MSYS"* ] || [ -n "${OS:-}" ]; then
       _SP_OS="windows"
   fi

   [ "$x" = "MINGW"* ] mixes = string-equality with a glob pattern. test/[ doesn't expand globs in operands, so this check never matched MINGW or MSYS. The fallback [ -n "${OS:-}" ] triggered on any environment that happened to export the OS variable, including Linux containers that happen to have it set, which would mis-route plugin downloads to the windows/ S3 prefix.

What was the solution? (How)

5.0 plugin sync:

• Added conda_recipes/blender-5.0/recipe/zzz-blender-plugin-sync-activate.sh and zzz-blender-plugin-sync-deactivate.sh, mirroring the 5.1 layout.

• Added conda_recipes/blender-5.0/recipe/plugin_sync_bootstrap.py — a standalone Python file invoked via blender -b --python <bootstrap> from the activate script. Bootstrap runs once per session during conda env-enter: bpy.ops.preferences.addon_install + addon_utils.enable for each addon, then bpy.ops.wm.save_userpref(). All subsequent blender calls in the session pick up enabled addons from the persisted userpref.

  Why a one-shot bootstrap instead of a startup script: on Blender 5.0.x, scripts in BLENDER_USER_SCRIPTS/startup/ run with a restricted bpy.context (_RestrictContext). addon_install raises AttributeError reading view_layer/scene attributes, and addon_utils.enable fails to import the module since it was never registered in the preferences DB. --python runs outside the restricted context, so install and enable both succeed there.

• The activate script sets BLENDER_USER_CONFIG to a session-scoped path ($OPENJD_SESSION_WORKING_DIR/deadline-plugins/blender-config) so the userpref we write is isolated to the session and gets cleaned up by the worker at session end.

• Updated conda_recipes/blender-5.0/recipe/build.sh to copy all three files into $PREFIX/etc/conda/{activate,deactivate}.d/ and $PREFIX/share/blender-plugin-sync/.

• Added test -f smoke checks for the three plugin-sync files to recipe.yaml.

5.1 OS detection fix:

-if [ "$(uname -s)" = "MINGW"* ] || [ "$(uname -s)" = "MSYS"* ] || [ -n "${OS:-}" ]; then
-    _SP_OS="windows"
-fi
+case "$(uname -s)" in
+    MINGW*|MSYS*|CYGWIN*) _SP_OS="windows" ;;
+esac

case expands glob patterns in match arms, which is what was originally intended. Also adds CYGWIN coverage. Drops the OS fallback so non-Windows environments that happen to export OS aren't mis-detected.

What is the impact of this change?

• Customers on Blender 5.0 can now place plugins under s3://<ja-bucket>/<root-prefix>/plugins/linux/blender/5.0/<addon>/ and have them auto-enable on Deadline Cloud workers, with no manual addon_install/addon_enable calls in their job scripts.
• The 5.1 activate script now correctly detects Windows on Git Bash / MSYS2 / Cygwin and no longer mis-detects Linux environments that export OS. No behavior change on workers where neither condition holds.
• Build artifacts: 5.0 conda package gains ~3 KB of scripts and a ~3 KB Python file under the prefix.

How was this change tested?

1. Unit tests of the activate/deactivate scripts (mocked aws and blender, run on the host):

=== Results: 22 passed, 0 failed ===

Tests cover: silent skip when env vars missing, addon download/reorganization, BLENDER_USER_SCRIPTS + BLENDER_USER_CONFIG export, bootstrap invocation arguments, debug log creation, no startup/ generation, deactivate cleanup, single .py addon handling, missing-bootstrap fallback. (Test scaffolding was developed alongside the internal port; not shipped in this PR but the same script structure runs against the public recipe.)

2. End-to-end on a real SMF worker:

Built the 5.0 recipe with rattler-build, pushed to a dev S3 conda channel, and submitted a job that:

• Sets CondaPackages=blender=5.0.1=hb0f4dca_0 and CondaChannels=s3://...
• The job script does no addon_install/addon_enable calls — relies entirely on the recipe's plugin sync to enable addons before the render runs.
• Verifies via addon_utils.modules() + addon_utils.check() that every uploaded addon is in Blender's enabled list, and that bpy.ops.flip_fluid_operators.* is populated (proves the C++ engine loaded).

Result on the SMF worker (Blender 5.0.1, AL2023):

Plugin Sync bootstrap: addon_install OK for 'flip_fluids_addon'
Plugin Sync bootstrap: enabled 'flip_fluids_addon'
Plugin Sync bootstrap: addon_install OK for 'plugin_sync_test_addon'
Plugin Sync bootstrap: enabled 'plugin_sync_test_addon'
Plugin Sync bootstrap: addon_install OK for 'simple_plugins_test_addon'
Plugin Sync bootstrap: enabled 'simple_plugins_test_addon'
Plugin Sync bootstrap: save_userpref OK
=== bootstrap exit code: 0 ===
...
Enabled addons after auto-enable: ['io_anim_bvh', 'bl_pkg', 'cycles', 'io_scene_fbx',
  'flip_fluids_addon', 'io_scene_gltf2', 'plugin_sync_test_addon', 'pose_library',
  'io_curve_svg', 'simple_plugins_test_addon', 'io_mesh_uv_layout']
PASS: flip_fluids_addon auto-enabled (no manual install/enable calls in this script)
PASS: FLIP Fluids native ops available: 207
Render complete

Pure-Python addons and a compiled C++ addon (FLIP Fluids 1.8.6 built from source on AL2023) both pass.

3. 5.1 OS detection fix:

Verified by inspection that the new case statement matches MINGW/MSYS/CYGWIN against uname -s and that the previous [ ... = "MINGW"* ] form is invalid POSIX shell. No worker regression on Linux — case doesn't match any of the patterns, so _SP_OS stays linux, identical to the previous (broken) behavior on Linux.

Was this change documented?

The behavior is documented inline in the new activate-script header, including a multi-paragraph explanation of why a --python bootstrap is used instead of a startup script (_RestrictContext discussion). The 5.0 README didn't have plugin-sync content before, so no separate README change was needed in this PR. Customer-facing convention docs (S3 path layout) live in the existing 5.1 README and apply unchanged to 5.0.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.