Which module path does the script's own interpreter load on each laptop? I'd start there; the names on the SDK folders don't tell you what's running.
简体中文界面。帖子、指南及政策正文保留原文;未对原文作自动翻译。
Why does the rebuilt laptop reject a working SDK call?
VictorChan1055 · 2026年8月8日 05:33 UTC
20 条回复
The paths differ: our vendor folder on the old laptop, an installed package on the rebuilt one. I'd compared the scripts and completely missed what they imported.
2分@VictorChan1055 Preserve your working copy and compare the two function signatures. Recreating it in an isolated environment should answer the laptop part of the problem.
18分@AnilBrooks0810 Too certain. Matching the SDK might fix the argument error while dependencies or the launcher still differ.
11分You're right about my wording. Matching the SDK starts the comparison; it doesn't finish it. Include the interpreter, dependencies and launcher, then compare the documented read-only result.
13分@AnilBrooks0810 I've found a signature difference exactly where the argument is rejected. Both SDK copies are preserved, and our working laptop is still untouched.
18分My first instinct would've been to change that argument. Why not just match the installed package's signature?
9分It could remove the local error. You'd still need matching SDK documentation and confirmation of the controller pairing; accepting the arguments doesn't establish the rest of the behaviour.
7分@AnilBrooks0810 I had a terminal pointing at one environment and a shortcut at another on my setup. My triumphant fix covered exactly one way of launching it.
12分I've checked the launcher we actually use as well. It points to that installed package, so the path difference isn't just from my terminal session.
16分@AnilBrooks0810 Are the controller and SDK meant to have matching version numbers? I don't know whether those numbers belong to the same scheme.
11分Treat them as separate identifiers unless the documentation says otherwise. Look for a stated pairing, or send both identifiers to support for confirmation.
17分@AnilBrooks0810 Our maintenance record and the controller version screen agree. The loose end is the vendor folder: I haven't tied it to an identifiable release archive.
6分Checksums help compare copies. They won't identify the publisher, release or supported pairing for your mystery folder.
12分@LuisArcher0434 Any local edits? They could prevent an archive checksum match.
19分@WillBennett0748 There's no history with that folder, and I can't tell whether it's been edited. I've left the source as unknown rather than attaching a likely-looking release number.
13分Your identifiers, signature comparison and sanitized traceback should make a useful support request. Describe the vendor folder as untraced so they don't mistake it for a known release.
15分@AnilBrooks0810 Once you know which copy it's, is a dependency list enough to make the next rebuild less painful?
6分@NadiaBennett0726 Add SDK source, interpreter, launch instructions and controller ID. Keep a sanitized read-only result too, so you've got a baseline.
6分Those known paths and identifiers are in my setup note. I've left the SDK origin blank; a tidy guess would only make the next rebuild harder.
10分