I started to develop a VS Code extension for Blender Development (https://www.youtube.com/watch?v=WbHN8w7GbJ0). During development I noticed that I need two new command line arguments make things possible, that are not possible now. (afaik)
--no-addons: When this argument is given, no addon will be loaded. This can be useful when starting Blender with the -b option to run it in the background. Some addons like to crash Blender when it runs in the background. I know that this is a bug in the addons, but I’d like to not depend on other addons. This could also be combined with the --addons names argument to only enable certain addons, but disable all others.
--python-setup filepath: This will run the script at the given location as soon as Python is loaded but before Blender loads any of its own modules. That would allow me to startup a debug server (e.g. using ptvsd.enable_attach()) that can be used to debug Blenders Python scripts that run at startup. Obviously Python scripts started at this stage are not able to interact with Blender, but that is ok.
I can try to implement this myself, but I’d like to get some feedback on the topic first.
It would be great if you can also use some environmental variables to set arguments like --no-addons and some other arguments (not mentioned in your post) that can be set to True or False or some integer value (like number of threads)? This is gonna be very useful for those who compile Blender as Python module.
If --factory-startup works I think that is preferable. For --python-setup, I don’t know of a good reason not to add it. Maybe it could be named --python-debug-setup or something like that to indicate it has a quite specific purpose, and is not intended to be for typical Python scripts that need to setup something.
Yes I think --factory-startup should work. For addons that are enabled by default, one can expect that they will be fixed when they crash Blender when running in the background. That is not the case for every other addon.
Not sure if there is any other use to disable all addons.
I’m fine with that name too. However maybe debug should not be in the name because I’m sure someone can come up with another valid use for this at some point.
Somewhat related, I wouldn’t be opposed to shipping ptvsd with blender, previously i held back on this given it was a windows only thing, but now that it’s usable cross platform, it’s one less thing to install for users wanting to debug, last i checked it wasn’t a huge lib.
Activation is a different issue though, i’m proposing just the add the lib to the modules we ship, integrating it in the UI so it’s as easy as a checkbox in the user prefs is nice, but i doubt anyone has time for such a thing right now. however having it easily available would go along way for improving the python debugging experience.
Hm I don’t think this is really necessary. Similar arguments can be made for many packages. I think a better solution is to just make it easier to install any package from within Blender. I won’t depend on that anyway for my extension which will make make setting this stuff up effortless (I hope).
Actually, I’d like to give my 2 cents on this. When rendering in the background on remote rendering machines, I will also sometimes run into bugs where addons will crash blender when running in the background, yet running using --factory-startup likes to mess with other preferences like CUDA devices.
A --no-addons argument would be pretty helpful in this regard.
With --background arguments, --python script does run before any openGl init so it may be source of troubles with addons using gl. (many gpu.xx class instanciation result in segfault)
Not certain about --addons initialisation context with --background option but they likely missing gl too.
So main issue is more when addons are executed -with or without gl- than wich way to disable them all.
As side note: check for bpy.app.background and prevent any gpu.xxx access does fix gpu module issue.
Suppose someone like me compiles Blender as Python module. In that case, you cannot pass any arguments when importing bpy in your Python environment. All you can do is doing import bpy and that’s it! For instance, how can one stop the bpy package from loading the addons, assuming that you have added the --no-addon argument? All you can do is to do import bpy and then use the functions/classes within bpy to do everything else, which is pretty late for many things.
However, there could use a simple trick to take care of this issue and that trick is to set a bunch of environmental variables before doing import bpy and read them during bpy startup. This is similar to what many other Python packages do (e.g. this example for Numpy).
Another use case: recently I had this issue and there was no way to resolve this except recompiling everything to get a new bpy module with setting -DWITH_CYCLES_DEVICE_CUDA=OFF (of course a more fundamental solution is to do a lazy CUDA initialization as in PyTorch). This issue might have been resolved by setting an environmental variable like export CYCLES_DEVICE_CUDA=OFF. So, after doing import bpy, the bpy module would look for many environmental variables (CYCLES_DEVICE_CUDA in this case) and determines whether Cycles should use/initialize CUDA or not. In another scenario I wanted to define the path for a blender preference file but it looks like I couldn’t do it through the Python API or after the bpy module has been loaded. Maybe having an environmental variable for things like this could be useful as well. This saves a lot of time and energy and makes things much simpler. This same logic can be applied for things like --threads, -noaudio,–factory-startup,–no-addonsetc. Of course, in most cases people will not set these environmental variables and thebpy` module get loaded with the default settings.
Edit: I just noticed that there are a couple of environmental variables that Blender reads them while loading but I think this list should be expanded:
$BLENDER_USER_CONFIG Directory for user configuration files.
$BLENDER_USER_SCRIPTS Directory for user scripts.
$BLENDER_SYSTEM_SCRIPTS Directory for system wide scripts.
$BLENDER_USER_DATAFILES Directory for user data files (icons, translations, ..).
$BLENDER_SYSTEM_DATAFILES Directory for system wide data files.
$BLENDER_SYSTEM_PYTHON Directory for system Python libraries.
$TMP or $TMPDIR Store temporary files here.
$SDL_AUDIODRIVER LibSDL audio driver - alsa, esd, dma.
I am really surprised! Blender as Python module is one of the greatest thing Blender developers prepared for researchers like us! It’s amazing and I compile it very easily (I can send you an script to do it easily if you want)
A general comment: I think Blender developers should change their perspective a bit. The world is moving towards AI, and AI researchers like us need these tools to be able to do their research. It is understandable that Blender has been made for artists community but there is a beautiful world behind this wall that I guess most Blender developers have not seen, otherwise they would try to make this amazing tool more usable for researchers as well
Actually, it would be interesting to see how Blender is used as a standalone Python module. I mean, what kind of things do you do with it?
Personally I’d prefer to have a Python module that communicates with Blender in some way. Blender would be running in a separate process then. But again, I don’t really know what this is used for. Can you actually only use the bpy module, or all the other modules Blender provides as well?
However this is a bit off topic. I’d prefer to talk about this in another thread or privately.
This is exactly the problem I have when I need to use some scripts where arguments like --enable-autoexec or --factory-startup are needed to work properly (create drivers for instance). So for the moment, I just send subprocesses of blender --args --python … but this is not as convenient as just import bpy and do the thing.