Bug: Blender 4.2 registers addons both as legacy and extensions after using Blender 3.6

[SamuelBilek]

Working with addons that contain both legacy bl_info and the extension-related blender_manifest.toml across several Blender executables of different versions (3.6 - 4.2) with custom BLENDER_USER_SCRIPTS and BLENDER_USER_EXTENSIONS environmentVariables creates clashes with addon registration. Issue described below:

• Start Blender 3.6, all addons load into BLENDER_USER_SCRIPTS
• Start Blender 4.2, all extensions load into BLENDER_USER_EXTENSIONS
• Addons that contain both bl_info and blender_manifest.toml are rocognized by blender twice (As legacy addons from BLENDER_USER_SCRIPTS and as extensions from BLENDER_USER_EXTENSIONS)
• Sometimes both versions of addon get enabled on startup, sometimes only one of them,...

I propose a fix that would also expand the possibilites of users for starting Blender from different executables with different environmentVariables:

• Let's keep the already existing environmentVariables, they will serve as global configuration
• Let's add per-executable environmentVariables. If a variable is defined both in the global configuration and in the executable, the one from the executable is used

In my case it would allow me to have a different BLENDER_USER_SCRIPTS folder for Blender 4.2+ that get's populated only with addons that cannot be used as extensions, while I keep all extensions in the global BLENDER_USER_EXTENSIONS folder.

[Mateusz-Grzelinski]

please tell me: is you addon now linked in both places: in BLENDER_USER_SCRIPTS and BLENDER_USER_EXTENSIONS?

[Mateusz-Grzelinski]

so there are functions that do a basic check for duplicated links, but I just checked and the case you presented is not covered, I just missed it.

This is why I created #184, but I do not have time to finish it.

I think we can call it a bug. The fix would be:

• if True if is_addon_legacy(addon_info.load_dir): create a check that will remove link that targets the same addon from BLENDER_USER_EXTENSIONS
• if False if is_addon_legacy(addon_info.load_dir): create a check that will remove link that targets the same addon from BLENDER_USER_SCRIPTS

If you want to push for the feature with environmentVariables please create new issue where we can discuss it

[SamuelBilek]

I mostly wanted that feature to fix this bug. What you propose sounds like a not so complicated fix. Will you have time to implement it? Or should I do it?

[Mateusz-Grzelinski]

I will not have time to do it, if you have please do. There is already code that does somthing similar, Mark me as reviewer when you create PR

[Mateusz-Grzelinski]

BTW this docs is mostly relevant to the logic that you are going to touch, just skim it, dont read deeply into it https://github.com/JacquesLucke/blender_vscode/blob/master/EXTENSION-SUPPORT.md

[SamuelBilek]

Could you please tell me how do you debug the launch python code in this extension? :)

[Mateusz-Grzelinski]

usually it is easier to add print. Note: print(f"{variable=}") is usually the most conviewnient.

The bootstraping code that lauches debugger is notoriously hard to debug. You can try https://code.visualstudio.com/docs/python/debugging#_debugging-by-attaching-over-a-network-connection but it will take you a while to get it right, I do not have anything ready.

oh and logging in #198 is almost ready - it is still a time issue.

[Mateusz-Grzelinski]

I tried writing some tests for this specific part of code, but they are pretty hard to write https://github.com/JacquesLucke/blender_vscode/tree/master/pythonFiles/tests/blender_vscode

Threat them as experiment, not a hard commitment.

they can be run outside of blender so debugging them is easy.

[SamuelBilek]

I managed to fix my problem just by clearing legacy addon links when creating a new extension link, the question is whether it's enough.