the fr5 identity script imports the wrong cupboard

BrunoAbbott0017 · 3 Feb 2026, 16:03 UTC

Closed
BR
BrunoAbbott0017
The rebuilt laptop rejects an argument in our unchanged FR5 identity script; how do I find the SDK copy behind the working old shortcut rather than choose the folder with the most reassuring name?

13 replies

AN
AnnaCarter1025
Replying to BrunoAbbott0017

Capture the actual interpreter, loaded module path and method signature when launched from each normal shortcut. Compare those before copying anything else; the folder you inspected may not be the folder either application imports

14 points
BR
BrunoAbbott0017
Replying to AnnaCarter1025

Working shortcut imports a local package under the script folder; rebuilt shortcut starts elsewhere and imports the shared SDK.

16 points
BE
BenAdams0109
Replying to BrunoAbbott0017

There's your mismatch. Don't fix it by making every SDK folder the same, though. Some other script may depend on the copy you overwrite.

10 points
JA
JackAdams0167
Replying to BenAdams0109

Ben, yes. I once cleared out a collection of old-looking folders and broke the one teaching example that actually ran. The owner had kept different interfaces for a reason, just not one written anywhere I could find. Bruno, can the maintainer define a dependency set for this identity script and make its launcher use that explicitly? Keep the working copy intact until the supported replacement has been checked. You want an explanation for the next rebuild, not a room full of identical cupboards with one lucky shortcut.

-2 points
AA
AaronCarter0958
Replying to BrunoAbbott0017

Does the working copy have a version you can identify, or is it somebody's edited local file?

20 points
BR
BrunoAbbott0017
Replying to AaronCarter0958

Edited local file, according to the maintainer; signature changed to suit the old call, with no note beside it.

22 points
AN
AnnaCarter1025
Replying to BrunoAbbott0017

Then compare that edit with the documented interface for the supported package and controller version. The aim is not necessarily to preserve the local signature; it is to make the intended read-only call correctly and record why

5 points
BE
BenAdams0109
Replying to BrunoAbbott0017

And keep the edit visible in the comparison. 'Same script' was true, but it left out the local code doing half the adapting.

12 points
JA
JackAdams0167
Replying to BrunoAbbott0017

Was that adaptation doing anything besides changing the arguments?

9 points
BR
BrunoAbbott0017
Replying to JackAdams0167

Only rearranging arguments, maintainer confirmed; the revised script now uses the supported call directly in its own dependency set.

11 points
AA
AaronCarter0958
Replying to BrunoAbbott0017

Try the normal shift shortcut, close it and reopen it, and check the returned controller identity each time. Running from the maintainer's terminal is not the route everyone else inherits.

13 points
BR
BrunoAbbott0017
Replying to AaronCarter0958

Normal shift launch and reopen checks both return the intended controller identity; loaded paths match the documented set, and the teaching folders stayed untouched.

18 points
BR
BrunoAbbott0017
Replying to AnnaCarter1025

Thanks, Anna; following the loaded path found the local edit before I started replacing perfectly innocent folders.

24 points

Discussion closed

This discussion is closed to new replies after six months without activity. Last activity: .