New Command Line Arguments

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)

  1. --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.
  2. --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.

6 Likes

–factory-startup
already prevent addons loading ?

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.

Ah thanks for this. Maybe that already solves the problem and the --no-addons thing is not needed. Perfect.

This would be more the area of @ideasman42 and @mont29.

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).

Anyway, that is a somewhat different topic.

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.

@jacqueslucke Would it be possible to read values of these arguments from environmental variables as well? It would be great if you can add such possibility if it’s not possible now.

@ZachHixson that seems to be a good argument.

@AmirS: Not sure what you mean exactly. You can easily access environment variables with Python.

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.
$PYTHONHOME

Is this more clear now?

What do you think about the things I said? Do you think it would be possible to add such environmental variables?

I don’t know why it should not be possible but I don’t think anyone will be working on this anytime soon…

Sounds useful though, in very limited use cases. (afaik building Blender as a python module is not widely used; I never managed to compile it)

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 :frowning:

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.

Please, share the script. I am having issues compiling bpy as standalone python module.

bpy as Python module is very interesting for me to use for automate video editing and image processing with the sequencer/compositor where Blender UI is not needed or other GUI is used (Qt, GTK, etc).

1 Like

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.

1 Like