Extension Addon (Blender 4.2) Preferences show "Warning /\ Policy violation with top level module: <addon_id> about blender_vscode HOT 4 CLOSED

Hello again.
--Is it the full error?-- Oh, ok, you mentioned it is error from preferences.
No output in logs is rare situation. So I will need you to isolate the issue a bit by using some env vars and try to run vs code again:

    "blender.environmentVariables": {
        "BLENDER_USER_CONFIG": "./blender_isolation",
        "BLENDER_USER_SCRIPTS": "./blender_isolation",
        "BLENDER_USER_EXTENSIONS": "./blender_isolation"
    },

In source code of blender I found the test: https://projects.blender.org/blender/blender/src/branch/main/scripts/addons_core/bl_pkg/tests/test_cli_blender.py#L778

        Warn when:
        - extensions add themselves to the ``sys.path``.
        - extensions add top-level modules into ``sys.modules``.

Also try to run ❯ .\blender.exe --command extension list as this is the command used in above test.

commit 319684d8f6e80373401955ef049e96efe5f447d7

Extensions: warn when extensions violate module policies

As each extension has it's own package, any modules it includes must be
imported as sub-modules. Warn if extensions are including themselves
in the sys.path as this breaks name-spacing of extensions.
Show these warnings in the add-on & extensions UI.

from blender_vscode.

Many many thanks, I had added the module to sys.modules (to not having to "from bl_ext.user_default import <id>" as <id>" each time after Blender start or after update). I removed it … that was it.
If you have an idea how to solve the problem above (i.e. how to get the main <id> being automatically imported for the debug window, best also after each update), please tell me.
Thanks again, the issue can be closed :)

from blender_vscode.

btw, beside your other detailed answers in the other issue thread before also your last comment was brilliant and led me onto new trails (this one here one of them *grins*), especially concerning generic matters. And one of your given links led me to much better "typing" (type check/ intellisense namespace), especially concerning custom_properties (but I'm still dealing with the problem, that also bpy.props.* have to be defined as __annotations__.

I even found a method to avoid the "register" mess (concerning complex dependencies) by introducing a singleton "Registry" … just need a "from XXX_MODULE import XXX_CLASS only for each top-level UI class (normally the top-level panels) and a "from OP_MODULE import OP" in the modules, which use them.
If there is a "from <level*.>Registry import *; Registry([classes to register],[op_classes_to_register],[ui_classes_to_register])" in each file, where classes have to be registered, everything works fine … the dependencies are solved automatically in the right order.
And of course in the main module: "Registry().register()"/"Registry().unregister()" to perform the whole registration of the collected at once.

Thanks again for dealing your knowledge so detailed, understanding, interested, engaged and understandable.

from blender_vscode.

that also bpy.props.* have to be defined as annotations

yup. That was a change that was made a long time ago. Used to be normal class variable. I really dont know why they would use annotations for this...

Remember that many blender python typing corner cases were already worked on/solved by https://github.com/nutti/fake-bpy-module. And if you are feeling adventurous and want to take a tour of python typing: https://devtalk.blender.org/t/proposal-generate-stub-files-for-blender/15819/2

If you have an idea how to solve the problem above (i.e. how to get the main being automatically imported for the debug window, best also after each update), please tell me.

I do not understand. What do you mean for the debug window? There is a python trick for TYPE_CHECKING https://github.com/JacquesLucke/blender_vscode/blob/master/pythonFiles/launch.py#L12 but not sure where you are going with this.

I even found a method to avoid the "register" mess

Yup, sounds familiar. Usually registering is some combination of

1. Gather your classes in one place (usually a tuple of classes to register)
   2a. register (and do not mess up the order)
   2b. Make your registering super exotic and unique. Be Proud of your achievement. Fix it because you found a corner cases (like #118). Be proud again.

Be amazed by this exitic piece of code:

# scripts/addons_core/rigify/operators/__init__.py
def register():
    # Lazily load modules to make reloading easier. Loading this way
    # hides the submodules and their dependencies from initial_load_order.
    loaded_submodules[:] = [
        importlib.import_module(__name__ + '.' + name) for name in submodules
    ]

    for mod in loaded_submodules:
        mod.register()

You are lucky because I just was looking for distraction from my usuall DevOps-y work and I for a long time wanted to change some things in this repo. I just finished my (yet another) studies and got some time to look at random issues. :)

from blender_vscode.