Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modules duplication #4281

Closed
Durman opened this issue Aug 13, 2021 · 0 comments
Closed

Modules duplication #4281

Durman opened this issue Aug 13, 2021 · 0 comments
Labels
core Architectural problems

Comments

@Durman
Copy link
Collaborator

Durman commented Aug 13, 2021

Problem statement

Because of this code

print('sv: import settings')
import_settings(imported_modules, sv_name)
print('sv: import all modules')
import_all_modules(imported_modules, mods_bases)

sverchok/__init__.py

Lines 64 to 66 in a5d0742

# make sverchok the root module name, (if sverchok dir not named exactly "sverchok")
if __name__ != "sverchok":
sys.modules["sverchok"] = sys.modules[__name__]

the same modules can be imported several times. This is bad because some modules can share information between eachother via third modules and if each of them has its own instance of a module then there is no information interchange. In general I think all modules should have only one instance.

Looks like that sverchok name was added to sys.modules so that import path could be started from sverchok name. But it's not clear why relative import paths could not be used instead.

Adding main module reachable by sverchok name makes importing modules peculiar. For example:

__name__ == "svercok-master"  # True
from sverchok.data_structure import DEBUG_MODE
assert('sverchok.data_structure' in sys.modules)  # True
__name__ == "svercok-master"  # True
from sverchok import data_structure
assert('sverchok-master.data_structure' in sys.modules)  # True

I'm not sure yet how this can be handled. Probably adding __name__ = "sverchok" would solve the problem.

Useful links:
https://b3d.interplanety.org/en/creating-multifile-add-on-for-blender/
https://devtalk.blender.org/t/plugin-hot-reload-by-cleaning-sys-modules/20040

@Durman Durman added the core Architectural problems label May 5, 2022
Durman added a commit that referenced this issue Dec 16, 2022
…4281

Settings were purposely imported via addon_folder_name.settings instead of sverchok.settings. I assume this was done to be able to write this: class SvPreferences: bl_idname = __package__. Because it seems that bl_idname of add-on settings should always be equal to name of add-on folder.
@Durman Durman closed this as completed in 8192dcd Dec 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Architectural problems
Projects
None yet
Development

No branches or pull requests

1 participant