docs: Document Cinema 4D custom plugins and reorganize Plugins section - #472
Merged
Cherie-Chen merged 7 commits intoJul 7, 2026
Merged
Conversation
Cherie-Chen
enabled auto-merge (squash)
June 26, 2026 22:34
github-actions
Bot
added
the
waiting-on-maintainers
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Cinema 4D conda packages now support a Plugin Sync hook that downloads your own plugins from S3 onto render workers at session start and registers them with Cinema 4D via g_additionalModulePath. Document the feature (under the customer-facing name 'Custom plugins'), its support matrix, the S3 path conventions, and an upload example. Also reorganize the README so 'Plugins' is a single top-level section with two sub-categories: ## Plugins ### 3rd party plugins (Arnold, V-Ray, X-Particles, Cargo, Red Giant) ### Custom plugins (S3-based delivery of your own plugins) Per-plugin headings (Autodesk Arnold, Chaos Group V-Ray, etc.) move from h3 to h4, and their installation/licensing/compatibility headings from h4 to h5, to preserve the hierarchy depth. Adds a new docs/FAQ.md with custom plugin Q&As covering the support matrix, on-worker plugin location, no-plugin behavior, and the Cinema 4D 2024 caveat. Signed-off-by: Cherie-Chen <58997764+Cherie-Chen@users.noreply.github.com>
Cherie-Chen
force-pushed
the
docs/plugin-sync-cinema4d
branch
from
June 26, 2026 22:38
3e64791 to
a1c3fcd
Compare
…ion=3.10
numpy 2.5.0 added PEP 695 'type' statement syntax to its type stubs
(numpy/__init__.pyi line 737):
type _Falsy = L[False, 0] | bool_[L[False]]
This is Python 3.12+ syntax. mypy's [tool.mypy] python_version = '3.10'
config tells mypy to parse files as Python 3.10, so it rejects the
stub with:
Type statement is only supported in Python 3.12 and greater [syntax]
Pinning numpy < 2.5 (resolves to 2.4.x) keeps the stubs parseable
under the existing mypy config. Newer numpy bumps will need a coordinated
move of mypy.python_version to 3.12 once Python 3.10/3.11 are dropped
from the support matrix.
Surfaced by the macos-latest, 3.13 lint job failing on PR aws-deadline#472 — that
job's cached hatch venv had been refreshed (Python patch roll) so pip
resolved numpy to 2.5.0; the macos-3.11 job kept its older cached
numpy 2.4.x and continued to pass.
Signed-off-by: Cherie-Chen <58997764+Cherie-Chen@users.noreply.github.com>
The intro bullet under '## Plugins' described all six listed plugins as 'packaged for you', but two are exceptions: - Cargo works with no extra fleet or submitter configuration; there is no Deadline Cloud package involved. - Red Giant uses a host configuration script rather than a conda recipe, so its setup path is different from the conda-packaged plugins (Redshift, Arnold, V-Ray, X-Particles). Reword the bullet so the summary matches what the per-plugin sections below actually say, and add a pointer to those sections. Addresses the claude-review bot inline comment on README.md line 255 in PR aws-deadline#472. Signed-off-by: Cherie-Chen <58997764+Cherie-Chen@users.noreply.github.com>
Cherie-Chen
removed
the
waiting-on-maintainers
Cherie-Chen
commented
Jun 26, 2026
| types-pyyaml == 6.* | ||
| # for integ tests | ||
| numpy == 2.* | ||
| numpy >= 2.0, < 2.5 |
Contributor
Author
There was a problem hiding this comment.
This was needed to resolve build error like https://github.com/aws-deadline/deadline-cloud-for-cinema-4d/actions/runs/28269192142/job/83762822726?pr=472
Contributor
There was a problem hiding this comment.
We discussed offline, maybe we can only restrict it for non-Python 3.12?
karthikbekalp
left a comment
karthikbekalp
left a comment
Contributor
There was a problem hiding this comment.
Thanks for adding this, added a few comments as we discussed offline.
| @@ -0,0 +1,32 @@ | |||
| # Frequently Asked Questions | |||
Contributor
There was a problem hiding this comment.
Hmm, I think we are moving most of our docs like FAQ to our docs.amazon.com: https://docs.aws.amazon.com/deadline-cloud/latest/userguide/maxon-cinema-4d.html ?
| types-pyyaml == 6.* | ||
| # for integ tests | ||
| numpy == 2.* | ||
| numpy >= 2.0, < 2.5 |
Contributor
There was a problem hiding this comment.
We discussed offline, maybe we can only restrict it for non-Python 3.12?
The fix in c76acf2 caps numpy at 2.4.x unconditionally, even on Python 3.12+ runners where the mypy PEP 695 parse issue does not force us to hold numpy back (numpy 2.5.0 requires Python >= 3.12 anyway, so pre-3.12 runners already resolve to 2.4.x on their own). Use a PEP 508 environment marker so that: - Python < 3.12: numpy >= 2.0, < 2.5 (unchanged behaviour) - Python >= 3.12: numpy == 2.* (unpinned within the 2.x major) This lets Python 3.12+ runners pick up newer numpy 2.x releases as they land, while continuing to shield mypy under python_version=3.10 from the PEP 695 'type' statement in numpy 2.5+ stubs. Addresses review feedback on PR aws-deadline#472: only restrict the pin for non-Python 3.12 runners. Signed-off-by: Cherie-Chen <58997764+Cherie-Chen@users.noreply.github.com>
The custom-plugin FAQ added in a1c3fcd duplicated the flow used for other Deadline Cloud DCC user-facing FAQs, which live in the public service documentation at https://docs.aws.amazon.com/deadline-cloud/latest/userguide/maxon-cinema-4d.html rather than in this repository. Drop the file. README.md 'Custom plugins' section already covers the S3 path conventions, support matrix, on-worker location, and no-plugin behaviour, so no in-repo content is lost. Follow-up: mirror the same Q&As into the user guide. Addresses review feedback on PR aws-deadline#472. Signed-off-by: Cherie-Chen <58997764+Cherie-Chen@users.noreply.github.com>
…3.10 The Code Quality job on Python 3.13 was still failing after ed83c3e split the numpy pin. On Python 3.12+ runners the new marker lets pip install numpy 2.5+, whose stubs use PEP 695 'type X = ...' syntax, and mypy was rejecting them under the hard-coded [tool.mypy] python_version = "3.10": numpy/__init__.pyi:737: error: Type statement is only supported in Python 3.12 and greater [syntax] type _Falsy = L[False, 0] | bool_[L[False]] mypy's 'python_version' setting is a global override that fixes the syntax level for *all* files it parses — source and stubs alike — so capping it at 3.10 makes newer stubs unusable even on Python 3.13 runners where the code would run fine. Remove the override. mypy now uses the running Python's major.minor as its target, so each Code Quality matrix job checks against its own Python version: - ubuntu/windows/macos, py3.10 : mypy targets 3.10, numpy 2.4.x (per pin) - ubuntu/windows/macos, py3.11 : mypy targets 3.11, numpy 2.4.x (per pin) - ubuntu/windows/macos, py3.12 : mypy targets 3.12, numpy 2.5.x, PEP 695 OK - ubuntu/windows/macos, py3.13 : mypy targets 3.13, numpy 2.5.x, PEP 695 OK The py3.10 matrix job still guards against accidentally-introduced 3.11+ syntax in the codebase, so we don't lose the minimum-version type check. Verified locally on Python 3.10 (numpy 2.2.6) and Python 3.13 (numpy 2.5.1): ruff, black --check, and mypy src test all pass. Signed-off-by: Cherie-Chen <58997764+Cherie-Chen@users.noreply.github.com>
| @@ -85,7 +85,6 @@ packages = [ | |||
| ] | |||
|
|
|||
| [tool.mypy] | |||
There was a problem hiding this comment.
Removing python_version = "3.10" means mypy will now infer the target version from whatever interpreter it runs under (per CI, likely the newest supported, 3.13). Since the project still declares requires-python = ">=3.10", type checking will no longer be evaluated against the 3.10 floor — 3.10-incompatible typing constructs (e.g. newer typing/stdlib symbols, syntax gated on later versions) could slip through unflagged. If dropping this was intentional, consider pinning to the lowest supported version (python_version = "3.10") rather than removing it, so mypy validates against the minimum you commit to supporting.
Prior workflow run on 5287760 failed only in step 6 'setup ubuntu-latest' of the reusable python build workflow (apt-get exit code 100 — transient mirror flake); all other 11 matrix jobs were cancelled by fail-fast, not by real errors. Verified locally that ruff, black --check, and mypy src test all pass on Python 3.10 (numpy 2.2.6) and Python 3.13 (numpy 2.5.1) after 5287760. Empty commit to trigger a fresh run. Signed-off-by: Cherie-Chen <58997764+Cherie-Chen@users.noreply.github.com>
karthikbekalp
approved these changes
Jul 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
[Fixes: N/A](docs: Document Cinema 4D custom plugins and reorganize Plugins section)
What was the problem/requirement? (What/Why)
The
cinema4dconda package supports a hook that downloads custom Cinema 4D plugins from a Job Attachments S3 bucket onto the render worker at session start (registering them with Cinema 4D viag_additionalModulePath), but this capability was not documented anywhere. Customers had no way to discover it or learn the expected S3 path conventions.Additionally, the existing README had a top-level
## 3rd party pluginssection with no organizing parent. Adding a second plugin-related concept alongside it called for a clearer information hierarchy.What was the solution? (How)
Document the new capability of loading custom plugin with it's limitations.
What is the impact of this change?
Documentation only. No code, schemas, conda recipes, or runtime behavior change. Customers who use Cinema 4D 2025 or 2026 can now discover and configure the customer plugin hook without internal support guidance.
How was this change tested?
Rendered both
README.mdanddocs/FAQ.mdto verify markdown syntax and that the heading hierarchy renders correctly under the new## Pluginsparent.Verified the cross-link from
docs/FAQ.mdto../README.md#custom-pluginsresolves (GitHub auto-anchors### Custom pluginsas#custom-plugins).Spot-checked that all per-plugin subsections (Arnold, V-Ray, X-Particles, Cargo, Red Giant) still render with their content intact after the heading-level demotion.
No code paths changed, so no unit or integration tests were run.
N/A: No changes to the submitter, adaptor, or any Python code.
Was this change documented?
This PR is the documentation. The new content lives in:
README.md—## Pluginssection (reorganized) with new### Custom pluginssubsectiondocs/FAQ.md— new file with custom-plugin Q&AsNo schema files, docstrings, or other docs are affected.
Is this a breaking change?
No. Documentation-only change. The heading-level demotion under
## Pluginsdoes not break GitHub anchors for the per-plugin sections — GitHub anchor IDs are derived from heading text, not depth, so deep links like#autodesk-arnoldstill resolve.By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.