Addon fails to init with local armsdk

[tong]

The addon fails to initialize when using armsdk locally. @MoritzBrueckner Seems this error got introduced with changes to the addon reload process.

Read prefs: /home/tong/.config/blender/2.93/config/userpref.blend
Traceback (most recent call last):
  File "/home/tong/.config/blender/2.93/scripts/addons/armory.py", line 631, in on_load_post
    restart_armory(bpy.context)  # context is None, use bpy.context instead
  File "/home/tong/.config/blender/2.93/scripts/addons/armory.py", line 626, in restart_armory
    start_armory(sdk_path)
  File "/home/tong/.config/blender/2.93/scripts/addons/armory.py", line 591, in start_armory
    start.register(local_sdk=use_local_sdk)
  File "/home/tong/dev/armory/armsdk/armory/blender/start.py", line 66, in register
    arm.props.register()
  File "/home/tong/dev/armory/armsdk/armory/blender/arm/props.py", line 531, in register
    arm.utils.fetch_bundled_script_names()
  File "/home/tong/dev/armory/armsdk/armory/blender/arm/utils.py", line 321, in fetch_bundled_script_names
    with WorkingDir(get_sdk_path() + '/armory/Sources/armory/trait'):
  File "/home/tong/dev/armory/armsdk/armory/blender/arm/utils.py", line 47, in __enter__
    os.chdir(self.cwd)
FileNotFoundError: [Errno 2] No such file or directory: '/armsdk/armory/Sources/armory/trait'
Read blend: /home/tong/dev/armory/armory_gh_actions2/test/empty.blend
Traceback (most recent call last):
  File "/home/tong/.config/blender/2.93/scripts/addons/armory.py", line 631, in on_load_post
    restart_armory(bpy.context)  # context is None, use bpy.context instead
  File "/home/tong/.config/blender/2.93/scripts/addons/armory.py", line 626, in restart_armory
    start_armory(sdk_path)
  File "/home/tong/.config/blender/2.93/scripts/addons/armory.py", line 591, in start_armory
    start.register(local_sdk=use_local_sdk)
  File "/home/tong/dev/armory/armsdk/armory/blender/start.py", line 58, in register
    arm.props_traits_props.register()
  File "/home/tong/dev/armory/armsdk/armory/blender/arm/props_traits_props.py", line 152, in register
    bpy.utils.register_class(ArmTraitPropWarning)
ValueError: register_class(...): already registered as a subclass 'ArmTraitPropWarning'

[MoritzBrueckner]

I guess the error happens when you load the project that has the local SDK? Does /armsdk/armory/Sources/armory/trait exist relative to your project's directory? Maybe it's an issue with relative paths and possibly a wrong cwd.

Haven't yet tried it myself but I will do that tomorrow :)

[tong]

Yes, when using armsdk locally like project/armsdk/ Yes, source code exists in relative path.

[MoritzBrueckner]

I wasn't able to reproduce this so far, it works for me and the console says Running Armory SDK from [...]/project/armsdk. Which operating system do you use?

Can you please check whether the call to get_sdk_path() in utils.py line 321 returns an absolute path? For me it does, but in your case it doesn't seem so. If you go into the implementation of get_sdk_path(), does get_fp() return an absolute path? Do you have a project root set in your test file?

[tong]

I am running arch-linux, blender 2.93.4.

The same error happens everytime the local sdk get picked up, regardless the project, like here: https://github.com/tong/armory_gh_actions/runs/3505067991?check_suite_focus=true#step:3:83

Odd thing here is that as soon as the local sdk is used bpy.data.filepath is always '' so the path returned from get_fp is invalid.

Here would be fix for this but i am not sure if this hasn't side effects. Also it would be good to know why this happens in the first place.

[MoritzBrueckner]

Odd thing here is that as soon as the local sdk is used bpy.data.filepath is always '' so the path returned from get_fp is invalid.

Oh, this doesn't happen to me on Windows... This could be either a Linux thing or it happens when you run Blender in background, like in the Github action. Does the same happen if you open Blender yourself or did the error only occur in the GH action so far?

Maybe Blender does treat .blend files passed as parameter like a startup file? Then this would be the case: https://developer.blender.org/T54312. If this is the reason, a better fix could be to check whether Blender is run in background and then use the cwd like you did. If not, your fix looks good to me :)

[tong]

I thought this would fix local armsdk usage in background mode, but it doesn't work in gh-actions. See: https://github.com/tong/armory_gh_actions/runs/3677484412?check_suite_focus=true

Furthermore, if a project picks up the local sdk once and then gets removed, it fucks up the armory installation:

[MoritzBrueckner]

As for the background mode I have no idea why this happens. I might try it tomorrow on my Windows machine (my time is a bit limited this week) but it could be a Linux thing after all.

The second thing is probably caused by the fact that armory.py is now symlinked and if the target is removed the link is obviously invalid. Maybe it would be better to simply copy the file, then we wouldn't have all these troubles.

Unfortunately Blender doesn't reload armory.py itself without a restart or reloading all addons, so it always is one reload late. We should try to reduce the entire armory.py to the very bare minimum and move even the preferences over to the Armory repository. Then updates to armory.py would be less important and frequent.

[tong]

Sounds good.

I think that introducing an environment variable for the armsdk path could also help for such things (and in general). This would allow to use a custom armsdk path without chaning the symlink. Like: export ARMSDK=/somewhere/armsdk && blender project.blend Where ARMSDK is used if set, the regular installation if not.

And, when installing the addon, this var could be used to set the armsdk path automatically.

[MoritzBrueckner]

That's a good idea! We should probably still get rid of the symlink though and simply copy armory.py to prevent invalid installations when the SDK is removed. I can try to implement that tomorrow :)

And, when installing the addon, this var could be used to set the armsdk path automatically.

Isn't that already happening just without an env var? The SDK path should be parsed via regex from the Blender info panel after Armory is installed.

[tong]

Isn't that already happening just without an env var? The SDK path should be parsed via regex from the Blender info panel after Armory is installed.

True, wasn't aware of that.

[MoritzBrueckner]

Should the environment variable also be set by Armory or is it only to be set by the user?

[tong]

Without much thought i would say it should only be set by the user.

[MoritzBrueckner]

When working on #36 yesterday, I noticed that the implementation of get_fp() differs between armory.py and utils.py. In armory.py, only the actual filepath is used whereas in utils.py the project root is taken into account (plus some other differences). Maybe that's causing this issue somehow?

[tong]

I can now only reproduce this in gh-actions which isn't that much of a problem when using the armory_gh_actions package since it controls where armsdk resides (not the user/project), though the error still might show up when not using the package.

Anyhow i think it's ok to close this for now. @MoritzBrueckner thanks 1000!