Backend: Implementation of addon deployment logic

[kalisp]

trafficstars

Brief description

Should handle updating addon zips provided by v4 server.

Very WIP.

Description

Goal is for OP client to learn which addons (and their version) are activated on the server, download and unzip client side code.

Additional info

Implements basic logic to process returned json with information about addons (actual get from v4 server is not included yet). Establishes json for addon information:

{
           "name": "openpype_slack",
           "version": "1.0.0",
           "addon_url": "c:/projects/openpype_slack_1.0.0.zip",
           "type": UrlType.OS,
           "hash": "4be25eb6215e91e5894d3c5475aeb1e379d081d3f5b43b4ee15b0891cf5f5658",
           "description": "Lorem Ipsum ...",
           "license": "Apache-2.0",
           "authors": "Petr Kalis <petr.kalis.orbi.tools>"
}

Description, license, authors could be used in the future for some Addon store or pulling info to some customer internal CRM, where same server endpoint could be reused. For current deployment logic it is not used.

Two types of source urls are implemented:

• OS - mapped drive to machine
• HTTP - downloading from HTTP server, handles GDrive sharable links too

Compares provided md5 hashes with downloaded .zip file. Unzips addon zip file into destination folder (zip file is expected without "inner" addon folder, just bare code) and removes zip.

It is missing another important part of preparation of dependencies for addons. That might be a separate PR.

[ynbot]

Task linked: OP-3682 Addons distribution

[antirotor]

you have there md5 implemented instead of sha256 but I guess that's just placeholder. I was wondering about the metadata that is coming from it. Actually if there is a reason to extend it with more information, to create for example browsable repository, display more information about the addon or so. What about sending along something like stuff defined in PEP-621 - then these could be read from pyproject.toml by server for example... name, version, description, license, authors. And for example post-install-script that could be run after the addon is unzipped to handle some checks, cleanups? This could be ofc done by properly designed hook api...

[kalisp]

Implemented basic http get to mock server returning testing get_addons_info payload.

[kalisp]

Added some unit tests.

[iLLiCiTiT]

Now it's question if we're able to make server send us these information :)

I would add some readme to the folder that it is v4 related code.

Few notes related to client folder structure. They don't have to be handled in this PR.

1. I think there should be some parent for distribution. import distribution can be dangerous in python world. With combination that we will probably need more common code in future. I would suggest to put distribution into folder named like openpype_common (or else) so we would do imports like from openpype_common import distribution.

• Good / Bad ???

2. I'm nost sure about this because v4 client is not yet fully defined but we may need even one more additional parent folder so the "imported folder" is not in the root of build. That is because we may want add the path explicitly to sys.path on start which we may not be able to do if it will be in root.

# Structure (combined with 1.)
├ <build root>
│  ├ igniter
│  │ └ ...
│  ├ common (this is path which will be added to sys.path)
│  │  └ openpype_common
│  │    ├ distribution
│  │    └ ...
│  ├ start.py
│  └ ...
└ ...

• Good / Bad ???

[kalisp]

Added readme.

[kalisp]

Introduced deeper folder structure

[kalisp]

Merging it as working prototype.

Next steps will be done after OP client will be prepared, to hook this up, polish it up and test.