Python 3.10 fails to handle VERSION_FILE_FILENAME not existing at update_url

[WeekendWarrior1]

happens on pyupdater 4.0 or 3.1.0

  File "/home/weekendwarrior/git/weekendwarrior1/LedFx/310/bin/ledfx", line 33, in <module>
    sys.exit(load_entry_point('ledfx', 'console_scripts', 'ledfx')())
  File "/home/weekendwarrior/git/weekendwarrior1/LedFx/ledfx/__main__.py", line 367, in main
    update_ledfx()
  File "/home/weekendwarrior/git/weekendwarrior1/LedFx/ledfx/__main__.py", line 266, in update_ledfx
    client = Client(ClientConfig(), refresh=True)
  File "/home/weekendwarrior/git/weekendwarrior1/LedFx/310/lib/python3.10/site-packages/pyupdater/client/__init__.py", line 215, in __init__
    self.refresh()
  File "/home/weekendwarrior/git/weekendwarrior1/LedFx/310/lib/python3.10/site-packages/pyupdater/client/__init__.py", line 220, in refresh
    self._get_update_manifest()
  File "/home/weekendwarrior/git/weekendwarrior1/LedFx/310/lib/python3.10/site-packages/pyupdater/client/__init__.py", line 563, in _get_update_manifest
    self._verify_sig(self.json_data)
  File "/home/weekendwarrior/git/weekendwarrior1/LedFx/310/lib/python3.10/site-packages/pyupdater/client/__init__.py", line 574, in _verify_sig
    if "signature" in data.keys():
AttributeError: 'NoneType' object has no attribute 'keys'

Is the final error, have traced it back to https://github.com/Digital-Sapphire/PyUpdater/blob/main/pyupdater/client/__init__.py#L448 failing silently, returning None, and then not raising an exception.

[shauneccles]

The application update lifecycle works fine when using python 3.9, so this appears to be a python related change.

I've also tested this using the latest git commit and it has the same behaviour as using the 4.0 @ pypi.

[Mezo1234-beep]

The application update lifecycle works fine when using python 3.9, so this appears to be a python related change.

I've also tested this using the latest git commit and it has the same behaviour as using the 4.0 @ pypi.

@shauneccles I have the same problem I guess 307 So what is the solution?

[WeekendWarrior1]

The application update lifecycle works fine when using python 3.9, so this appears to be a python related change.
I've also tested this using the latest git commit and it has the same behaviour as using the 4.0 @ pypi.

@shauneccles I have the same problem I guess 307 So what is the solution?

Copy your versions.gz multiple times and rename so you have one of each of these files: (need to sit on your download server alongside versions.gz)
versions-win.gz
versions-mac-arm.gz
versions-mac.gz
versions-arm.gz
versions-arm64.gz
versions-nix.gz
versions-nix64.gz

[dennisvang]

I'm seeing something similar on Python 3.9.7 with pyupdater 4.0.

The problem starts in FileDownloader._create_response(), which returns data=None for anything other than HTTP status 200 (in this case 404 Not Found).

The data=None causes all the trouble further down the line:

1. FileDownloader._download_to_storage returns None
2. there is no file_binary_data, so FileDownloader.download_verify_return() also returns None
3. the None gets "decompressed" to b'' in Client._get_manifest_from_http()
4. the b'' slips through the cracks in Client._get_update_manifest(), where it leads to a JSONDecodeError (empty string is not valid JSON), so that json_data remains None
5. finally Client._verify_sig() throws the AttributeError because it tries to do None.keys().

At first sight, a quick fix could be to replace line 551 in client/init.py by:

...
if isinstance(data, dict) and "signature" in data.keys():
...

However, that would mean we still end up with a log message "Version file download successful" and other problems down the line.

In fact the problem is that decompressing None makes no sense.
Explicitly raising an IOError when that happens in Client._get_manifest_from_http() does seem to work:

...
data = fd.download_verify_return()
try:
    if data is None:
        raise IOError('decompressing None makes no sense')  # <<<<<<<<<<< added this
    decompressed_data = _gzip_decompress(data)
except IOError:
    ...

@JMSwag Maybe an IOError should be raised in dsdev_utils.helpers.gzip_decompress()? Or would that have too many side effects?

[dennisvang]

A similar issue arises in Client._get_key_data(), again due to _gzip_decompress(None). This can be fixed the same way (or both would be fixed if dsdev_utils.helpers.gzip_decompress() would raise an IOError).

BTW: Shouldn't this say "Key file download failed"?