Question for generalized updater

[kromar]

This is not a requst or a bug but a thought i had about the updating of addons in general. This addon is very useful but not many developers include it in their addons and i thought it might be possible to make a addon where the user is able to specify the addons he wants to update by providing a list of github links. Do you think it would be possibe to do something like this and would this updater be able to be extended into a addon updater lime that? From my experience the tagging and repository hirarchy different developers use might be a problem. What do you think about this idea?

[TheDuckCow]

Hi there, thanks for sharing the idea! And indeed, you are correct that with little modification this could be used for a nice, essentially decentralized, general purpose updater. I've actually already done the work for a specific studio (which uses a mix of internal repo's and public ones, managing updates/installs for their artists; per addon configs stored in json). So, technical feasibility is not bad at all, but there are some other considerations to be had:

• Rightfully, should be forked into its own initiative (not that this is a heavy task)
• Consider also reviewing the latest Foundation plans around resource and asset management; maybe there isn't that much of an overlap, but some care should be given to not dilute other initiatives planned (and one has existed before around creating updating systems like this - I need to brush up on what was once aimed to be part of GSOC.
• Security, we should acknowledge that there is a difference between an individual addon owner implementing an updating system & users trusting it (ie what this current repo offers), vs enabling loads of addons to be installed via this push mechanism without the authors necessarily being aware of it.
• As for the the issue you mention around inconsistent addon tagging/repo structure: not really a show-stopper, since the addon updater is designed to account for varying scenarios. At worst, each addon has a one-time crowd-sourced configuration, in addition to maybe some logic that detects against master branch updates (so if no releases, then just plainly check for latest push to master or whichever branch is indicated to track).
  • This being said, we would still need to consider the ramifications of enabling auto code downloading and installing where the code author isn't necessarily aware this is happening - or maybe for some reason doesn't even want it to.
• Perhaps middle group is to only include "self-registered" repositories who include some kind of meta file/json/yaml that a) give the OK for the manager to read the repo, and b) define the repo-specific settings. Assume the addon manager respects these files in the same way that a crawler hopefully respects robots.txt on a website.

For record purpose, also calling out this type of initiative has been started before (one example), though that was via a more centralized approach (ie the addon manager itself actively kept track of the repos and configuration, as opposed to letting users input the repo links they are interested in). Also just acknowledging this thread on right-click select. If there are any other initiatives or examples, would be good to note here.

[ldo]

Are you trying to reinvent package management for each platform? Maybe it would be better to hook into what the platform vendors are already providing, like Microsoft WinGet.

[neomonkeus]

Are you trying to reinvent package management for each platform? Maybe it would be better to hook into what the platform vendors are already providing, like Microsoft WinGet.

The package manager you mention is more application level, whereas these are internal addon to the application, which can come from a diverse range of sources, which for the most part the addon already supports.

That said there is definitely options to leverage existing tech, like pypi as a platform agnostic, but whether or not users would be willing to push to those platforms is probably the main driver for the repo option, where studios may have an inhouse git server or similiar.

[hannesdelbeke]

it might be possible to make a addon where the user is able to specify the addons he wants to update by providing a list of github links.

I've been working on an addon that does exactly this for the last half year. It seems to be almost exactly what you describe.

a central repo hosts links to external github repos. a blender UI collects them all, and let's the user search, and install, and update. with the click of just 1 button.

core library (python) https://github.com/plugget/plugget

blender addon https://github.com/plugget/plugget-blender-addon

qt widget https://github.com/plugget/plugget-qt

there are still many things left to do. e.g. cg cookie has a lot of features plugget doesnt yet have. 1 cool thing is that it also supports other apps like max maya ..., not just blender. and the reason we dont use winget, is because winget installs apps. plugget installs plugins or addons for apps.