Sverchok imports refactoring #4823
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…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.
…unctions, refactoring
removing collecting sverchok node classes, it can be done by calling bpy.types.Node.bl_rna_get_subclass_py(bl_idname) instead, move UI code from utils to the ui folder, utils now are only registered when are imported from another core module or node.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Addressed problem description
Modules in the utils folder are not imported unless their imported from other modules (from core, ui, nodes). It also means that their register and unregister functions won't be called unless their are not imported. So it's possible to put operators into utils folder and register them there but in this case they should be explicitly imported to a module where they are used. This is done for performance of add-on startup though on this stage it might be barely measurable.
Also it fix import settings module. It was imported under add-on folder name. For example if the folder was
sverchok-masterthe modules was imported withsverchok-master.settingspath. Also modules imported in the settings modules could have the same root in path. In the same time all other modules are imported withsverchokroot, independent to add-on folder name. This caused problems like that #4281.Also it includes some small optimization, removes some code duplications and unused code.
Next step is to consider to use normal import statements. Now we use
importlib.import_modulefunction to import modules dynamically. This probably was implemented in this way to get import modules explicitly and call their register functions. But we also can easily get modules from sys.modules dictionary to call their registration functions. This is actually how it's done for imported utils modules now. Also current import approach is not friendly to use such tool as pydeps. On other hand using dynamic imports in a function is more convenient for startup profiling.🚀 Startup performance is about 10% faster #4752