davinci-resolve-mcp 4.8.7 → 4.8.8
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +67 -0
- package/README.md +1 -1
- package/README.zh-CN.md +2 -2
- package/install.py +1 -1
- package/package.json +1 -1
- package/src/granular/common.py +1 -1
- package/src/server.py +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -2,6 +2,73 @@
|
|
|
2
2
|
|
|
3
3
|
Release history for the DaVinci Resolve MCP Server. The latest release is summarized in the root README; older entries live here to keep the README focused.
|
|
4
4
|
|
|
5
|
+
## What's New in v4.8.8 — a test that reaches a Resolve launcher fails
|
|
6
|
+
|
|
7
|
+
Test-only. No tool, action or runtime code changed.
|
|
8
|
+
|
|
9
|
+
### Fixed
|
|
10
|
+
|
|
11
|
+
- **`test_granular_destructive_op.McpSchema` asked for a Resolve connection ten
|
|
12
|
+
times per run.** `test_every_hooked_tool_advertises_the_override_and_nothing_else_new`
|
|
13
|
+
called `hasattr(value, "__granular_destructive__")` on every global of every
|
|
14
|
+
granular module. Ten of those modules hold `resolve = ResolveProxy()`, and the
|
|
15
|
+
proxy's `__getattr__` calls `get_resolve()`, which falls through to
|
|
16
|
+
`_launch_resolve()` when nothing answers. Measured on v4.8.4 with the granular
|
|
17
|
+
`_launch_resolve` replaced by a counting stub: a full
|
|
18
|
+
`python -m unittest discover -s tests -t .` run reached it 10 times, once per
|
|
19
|
+
module, all from this test and from no other. With Resolve closed, each reach
|
|
20
|
+
would have run `open` on the application. Since v4.8.5 the guard's `get_resolve`
|
|
21
|
+
answers `None` first, so the launcher is no longer reached, but the scan still
|
|
22
|
+
asked for a connection. It now reads the marker with `inspect.getattr_static`
|
|
23
|
+
and asks for nothing. The new `test_the_module_scan_asks_for_no_connection`
|
|
24
|
+
fails if it asks again.
|
|
25
|
+
|
|
26
|
+
### Changed
|
|
27
|
+
|
|
28
|
+
- **A test that reaches a launcher now fails.** Until now the guard's stand-in
|
|
29
|
+
recorded the attempt in `LAUNCH_ATTEMPTS` and the test passed. pytest printed
|
|
30
|
+
the list in its summary without failing the run, `unittest` never read it, and
|
|
31
|
+
every entry recorded under `unittest` read `<unknown test>`. Now every
|
|
32
|
+
`unittest.TestCase` runs under a cleanup that fails it when an attempt was
|
|
33
|
+
recorded during the test or since the previous test finished, which covers
|
|
34
|
+
imports and class fixtures. Plain pytest functions get the same check from an
|
|
35
|
+
autouse fixture in `tests/conftest.py`. Each attempt fails exactly one test.
|
|
36
|
+
Each entry names the test and the module that called the launcher, for example
|
|
37
|
+
`tests.test_x.Case.test_y (called from src.granular.common)`. A test that calls
|
|
38
|
+
the stand-in on purpose deletes its own entry, as `test_offline_guard_granular`
|
|
39
|
+
already does, and passes.
|
|
40
|
+
|
|
41
|
+
### Validation
|
|
42
|
+
|
|
43
|
+
- New `tests/test_offline_launch_check.py` runs small inner tests that reach the
|
|
44
|
+
granular launcher through a `ResolveProxy`, the compound launcher through the
|
|
45
|
+
real `get_resolve`, and a launcher from `setUpClass`. Each reach fails exactly
|
|
46
|
+
one inner test; the `setUpClass` reach fails the class's first test and not its
|
|
47
|
+
second. An inner test that deletes the entry for its deliberate call passes. With the `TestCase.run`
|
|
48
|
+
wrapper removed, 4 of its 6 tests fail.
|
|
49
|
+
- The v4.8.4 `McpSchema` test fails under the new check when the guard's
|
|
50
|
+
`get_resolve` is swapped back to the real one. It records 10 attempts, each
|
|
51
|
+
`…McpSchema.test_every_hooked_tool_advertises_the_override_and_nothing_else_new (called from src.granular.common)`.
|
|
52
|
+
With `hasattr` restored in the scan, the new pin test fails with
|
|
53
|
+
`asked for a connection`.
|
|
54
|
+
- Full suite, `python -m unittest discover -s tests -t .`: 3,756 tests. No test
|
|
55
|
+
failed the launch check, and `LAUNCH_ATTEMPTS` was empty at exit. The 11 errors
|
|
56
|
+
are the same as on v4.8.5 in this environment (no `numpy` or `requests` in the
|
|
57
|
+
venv, plus `test_offline_fallback` and `test_lut_file_controls`).
|
|
58
|
+
`python -m unittest discover -s tests`, the runner that skips `tests/__init__.py`,
|
|
59
|
+
gives the same result.
|
|
60
|
+
Both runs used a scratch `sitecustomize` tripwire, because Resolve was open on
|
|
61
|
+
the machine. It set `sys.modules["DaVinciResolveScript"] = None`, answered any
|
|
62
|
+
later import with a recording module, pointed `DAVINCI_RESOLVE_BRIDGE_CONFIG`
|
|
63
|
+
at a file that does not exist, and blocked `Popen` of the application. It
|
|
64
|
+
recorded no `scriptapp` call and no launch in the test process or in any of its
|
|
65
|
+
59 child processes. The children were kept away by the tripwire's `None`
|
|
66
|
+
entry, not by this change. The control-panel children noted under v4.8.5 are
|
|
67
|
+
still outside the in-process guard.
|
|
68
|
+
- pytest is not installed here, so the `conftest.py` fixture was not run locally.
|
|
69
|
+
CI runs `python -m pytest tests -q`.
|
|
70
|
+
- No Resolve behavior changed, so no live Resolve run is required. None was made.
|
|
71
|
+
|
|
5
72
|
## What's New in v4.8.7 — an append Resolve refuses is reported as a failure
|
|
6
73
|
|
|
7
74
|
### Fixed
|
package/README.md
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
English | [简体中文](README.zh-CN.md)
|
|
4
4
|
|
|
5
|
-
[](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
|
|
6
6
|
[](https://www.npmjs.com/package/davinci-resolve-mcp)
|
|
7
7
|
[](docs/reference/api-coverage.md)
|
|
8
8
|
[-blue.svg)](#server-modes)
|
package/README.zh-CN.md
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
[English](README.md) | 简体中文
|
|
4
4
|
|
|
5
|
-
[](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
|
|
6
6
|
[](https://www.npmjs.com/package/davinci-resolve-mcp)
|
|
7
7
|
[](docs/reference/api-coverage.md)
|
|
8
8
|
[-blue.svg)](#服务器模式)
|
|
@@ -12,7 +12,7 @@
|
|
|
12
12
|
[](https://www.python.org/downloads/)
|
|
13
13
|
[](https://opensource.org/licenses/MIT)
|
|
14
14
|
|
|
15
|
-
> 本翻译对应 v4.8.
|
|
15
|
+
> 本翻译对应 v4.8.8 版 README。如与英文原版有出入，以 [英文原版](README.md) 为准。
|
|
16
16
|
|
|
17
17
|
一个 Model Context Protocol (MCP) 服务器，让 AI 助手通过官方脚本 API 控制 DaVinci Resolve Studio（达芬奇）。它提供完整的 API 覆盖，外加带护栏的工作流助手，涵盖剪辑、媒体池整理、渲染设置、审阅标记、调色、Fusion、Fairlight、项目生命周期任务、扩展开发，以及不碰源媒体的媒体分析。
|
|
18
18
|
|
package/install.py
CHANGED
|
@@ -37,7 +37,7 @@ from src.utils.update_check import (
|
|
|
37
37
|
|
|
38
38
|
# ─── Version ──────────────────────────────────────────────────────────────────
|
|
39
39
|
|
|
40
|
-
VERSION = "4.8.
|
|
40
|
+
VERSION = "4.8.8"
|
|
41
41
|
# Only hard floor: mcp[cli] requires Python 3.10+. There is no upper bound —
|
|
42
42
|
# Resolve's scripting bridge loads into newer interpreters on recent builds
|
|
43
43
|
# (Python 3.14 verified against Resolve Studio 20.3.2). Older Resolve builds
|
package/package.json
CHANGED
package/src/granular/common.py
CHANGED
|
@@ -93,7 +93,7 @@ if not logging.getLogger().handlers:
|
|
|
93
93
|
handlers=[logging.StreamHandler()],
|
|
94
94
|
)
|
|
95
95
|
|
|
96
|
-
VERSION = "4.8.
|
|
96
|
+
VERSION = "4.8.8"
|
|
97
97
|
logger = logging.getLogger("davinci-resolve-mcp")
|
|
98
98
|
logger.info(f"Starting DaVinci Resolve MCP Server v{VERSION}")
|
|
99
99
|
logger.info(f"Detected platform: {get_platform()}")
|