Save multiple Blender backup files to a different location than the opened .blend, with an easily accessible recall. Enhances cloud storage experience.
Initial version.
This extension requests the following permissions:
Saves .blend backups, store logs
Update functionality for older Blender versions
Automatic update functionality should be removed. Versions prior to 4.2 are not supported by extensions, and updates are handled by platform itself.
Also, 'Scene" and "User Interface" are unrelated tags for the add-on. Correct ones would be "System" and "Pipeline"
This extension is manipulating sys.path to install modules into the global namespace. Which violates extension name-spacing isolation (albeit temporarily).
Further there seems to be a lot of code which doesn't seem at all related to the extensions functionality.
Example files which don't seem related to this extensions functionality.
blend1/python_deps/polib/module_install_utils_bpy.py
blend1/python_deps/polib/snap_to_ground_bpy.py
blend1/python_deps/polib/telemetry_module_bpy.py
Thanks for the feedback, I will update the tags. The following applies to other our addons too.
I kept the updater here, so we don't have to create two code variants of the add-on for different Blender versions, but if you insist on removing it, we can remove it.
What ends up in the python_deps
are the Python libraries that we share between all the add-ons we develop. It would be quite tedious to ship only what's actually in use.
The solution (temporarily adding into sys.path
, and then importing in add-on's scope) arises from the fact above - we want to use those modules as libraries. Still, at the same time we respect the addon's scope. We return the sys.path
to its previous state after our importing is done. Is this a violation?
The updater can be removed from the extension using: paths_exclude_pattern
see: https://docs.blender.org/manual/nb/dev/advanced/extensions/getting_started.html
Then it can be removed when building the extension.
This can also be used for modules or sub-modules you don't use.
We return the sys.path to its previous state after our importing is done. Is this a violation?
Yes, because you're loading modules into the global module namespace.
Your modules would break any extension that bundle:
... and even if you picked more unique names, using the global namespace means there is always the possibility of colliding.
It should be possible to update your utility modules to be imported as sub-modules to avoid these problems.
Sign in to comment.
Ready for review