Auto updater fails to reload assets - reinstall MCprep fresh from website

[TheDuckCow]

Known issue: Blender updater causes failure to reload assets

This is a widespread issue with a simple workaround: update MCprep by manually installing it from http://bit.ly/MCprep fresh.

I need to explore why this issue has occurred and how to prevent it in the future, but is related to the newly added folders for effects spawning. Results in errors like:

961, in execute
 update_effects_list(context)
 File "<addon_path>/effects.py", line 752, in update_effects_list
 load_area_particle_effects(context)
 File "<addon_path>/effects.py", line 839, in load_area_particle_effects
 os.path.join(path, blend) for blend in os.listdir(path)
 FileNotFoundError: [WinError 3] The system cannot find the path specified: 'C:/Users/user/AppData/Roaming/Blender Foundation/Blender/3.2/scripts/addons/MCprep_addon/MCprep_resources/effects/particle'

[TheDuckCow]

Severity as measured by self-reported errors: Extreme, most sever bug MCprep has faced. Will find a resolution in the next 24h else I'll roll back the release (delete the tag).

[StandingPadAnimations]

Holy smokes, that's a really bad

[TheDuckCow]

It was actually bad enough it broke my cloud reporting so I couldn't refresh reports, but I was able to resolve that this morning.

Finally getting to work on uncovering the root cause. Here's my journey:

1) Did a clean install of MCprep 3.3.1 with Blender 3.2

Nothing special to report.

2) Pressed auto install update

Indeed after a restart the new update appeared. Pressed the button to auto-install. So far seemed smooth, but I notice in the console this output:

Traceback (most recent call last):
  File "/Users/***/Library/Application Support/Blender/3.2/scripts/addons/MCprep_addon/addon_updater.py", line 888, in unpack_staged_zip
    shutil.rmtree(outdir)
  File "/Applications/Blender 3.2/blender.app/Contents/Resources/3.2/python/lib/python3.10/shutil.py", line 708, in rmtree
    onerror(os.lstat, path, sys.exc_info())
  File "/Applications/Blender 3.2/blender.app/Contents/Resources/3.2/python/lib/python3.10/shutil.py", line 706, in rmtree
    orig_st = os.lstat(path)
FileNotFoundError: [Errno 2] No such file or directory: '/Users/***/Library/Application Support/Blender/3.2/scripts/addons/MCprep_addon/mcprep_addon_updater/source'
Restart blender to reload addon and complete update
Saved session recovery to '/var/folders/n1/c3slyy8x14l28nk2s_pc9j3w0000gn/T/quit.blend'

This may be what starts it all, but let's continue. Closing blender..

3) Inspecting files before opening

When looking into the MCprep resources unpacked, I notice that under effects ONLY the geonodes folder exists. So, unzupping definitely didn't do it's job. But let's continue..

4) Opening blender after the botched install

No errors on startup or anything, everything working fine until trying to reload assets.

Indeed, that's where it fails. It leads me to realize that there likely were no os.path.isfile checks for the hard coded effects files for particle areas and others.

Summarizing next steps

Most immediately, need to implement an isfile check and tbh pushing that out on it's own would be a big step forward; users would be missing the failed-to-unzip effects, but it wouldn't break all other resources (geo nodes would still be there... that's something I guess).

Thereafter, need to see what is tripping up the unzipping. Will report back.

[TheDuckCow]

Ok with that resolved, now need to see if we can fix the unzipping done by the addon updater.

[TheDuckCow]

Continuing on. What's weirder still is that the call to unstage zip fails, but it manages to continue with install instructions.

Concerningly I see the line:

mcprep addon: Extract - mkdir: /Users/***/Library/Application Support/Blender/3.2/scripts/addons/MCprep_addon/mcprep_addon_updater/source/test_files/test_resource_pack/textures/

Which means somehow it's picking up and trying to install source code..... this points to the root issue actually being that the updater is somehow not picking up the attached zip, but rather the source code of the release.

This let me to investigate further the raw updater outputs:

mcprep addon: {
'last_check': '2022-08-10 21:49:20.816204',
'backup_date': 'August-10-2022', 'update_ready': True,
'ignore': False, 'just_restored': False, 'just_updated': False,
'version_text': {'link': 'https://api.github.com/repos/TheDuckCow/MCprep/zipball/3.4.0',
'version': (3, 4, 0)}}

It is indeed clearly picking up the zipball instead of the release attached file. Need to investigate what changed to cause that.

[TheDuckCow]

I found the culprit:

While running an update of the source code for the updater, I did not realize I overwrote the code for the select link function. Bad design to have that embedded in the code that needs updating (and that's on me, me being the one who designed the Addon Updater in the first place).

596d331#diff-ea1d502548c4de6d96e67960ee8d53200520d803c5092f07b2d29c395d6a331eL1307

-       if "assets" in tag and "browser_download_url" in tag["assets"][0]:
-		link = tag["assets"][0]["browser_download_url"]
+	# if "assets" in tag and "browser_download_url" in tag["assets"][0]:
+	# 	link = tag["assets"][0]["browser_download_url"]

Clear answer is to revert the change in select_link_function. The unfortunate thing though is that users would need to use the auto updater twice in order to get back to the right version, since the updater code always runs based on the current installed version. My goal is to have two nearish term updates to help tighten the amount of time to get people to the right version.

[TheDuckCow]

Release going out shortly, crossing fingers this goes smoothly (but tbh, can't get much worse)