Code Monkey home page Code Monkey logo

blender-addon-updater's People

Contributors

blanchg avatar calinou avatar darkblader24 avatar dragorn421 avatar ekaj2 avatar federicob avatar josuemtzmo avatar kant avatar keshismith avatar kromar avatar ndee85 avatar neomonkeus avatar nutti avatar ombre5733 avatar schroef avatar theduckcow avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

blender-addon-updater's Issues

Account for different GitHub structures

Right now, the updater assumes a flat structure of an addon - that is, the root of the github repository is also the addon's root. I have added this to the tutorial to point this out:

on should have the init.py file and relative code structure at the root of the repository, not in a sub folder. The updater will try to install updates by directly installing the repository’s zip file.

The enhancement would be to more intelligently search for the relative addon's root within the zip file, perhaps just searchign by default one level deep or providing an option to the developer to specify which subfolder of the repository to treat as the addon itself.

Though this is more like an enhancement, I'm treating it like an issue as it could bar some developers from making use of the repository natively.

Account for fatal error in updated add-on

Do we have any way to account for the scenario in which a developer releases a buggy update, which gets installed, and then fatals out?

Per Greg Zaal:

Greg Zaal [4:50 PM]
@jonathan @johnroper100 if there is some fatal error in my add-on that prevents it from registering, will the auto update still work? e.g. i accidentally release a broken update, which gets downloaded for all users - once i release a fixed version will the users have to manually update then?

Thoughts @TheDuckCow?

Trouble registering the updater

I'm no a coder so I might be missing or doing something stupid. Right now My addon is basically a collection on different scripts I collect and so I can load them all together every time I need. Sometime ago I found an init example which could register all scipts inside an addon folder by just adding the name of the script into a list, this init file is as follows:

 `bl_info = {
    "name" : "Lynchon Tools 2.80",
    "author" : "Lynchon",
    "description" : "",
    "version" : (1,0), 
    "blender" : (2, 80, 0),
    "location" : "",
    "warning" : "",
    "category" : "Generic"
}

import bpy
from . import addon_updater_ops

modulesNames = ['UI','y_up','xml_parse_particles', 'xml_parse_conformHeight', 'metal_compiler','edit_pivot','uv_tube_unwrap','Hidesato Offset Edges','fillet_280','addon_updater','addon_updater_ops',]

import sys
import importlib
 
modulesFullNames = {}
for currentModuleName in modulesNames:
    modulesFullNames[currentModuleName] = ('{}.{}'.format(__name__, currentModuleName))
 
for currentModuleFullName in modulesFullNames.values():
    if currentModuleFullName in sys.modules:
        importlib.reload(sys.modules[currentModuleFullName])
    else:
        globals()[currentModuleFullName] = importlib.import_module(currentModuleFullName)
        setattr(globals()[currentModuleFullName], 'modulesNames', modulesFullNames)
 
def register():
    
    for currentModuleName in modulesFullNames.values():
        if currentModuleName in sys.modules:
            if hasattr(sys.modules[currentModuleName], 'register'):
                sys.modules[currentModuleName].register()
 
def unregister():
    for currentModuleName in modulesFullNames.values():
        if currentModuleName in sys.modules:
            if hasattr(sys.modules[currentModuleName], 'unregister'):
                sys.modules[currentModuleName].unregister()`

As I try to include the updater (so my coworkers can get any update I do) into the addon problems arrive. My problem comes when I try to register the "addon_updater_ops" bl_info, seems that adding it into my register function in my init doesn't work, it keeps telling me it misses a positional argument even if I already have my bl_info inside the init ( I've also tried importing it from the addon_updater_ops as the tutorial explained).

How should I approach this issue, please ask me if you need any additional info or files.

Thanks in advance

[REQ] Add interval days in the hover info auto updater

Sweet new release! One thing i noticed is when we use the compact view, we have the auto-updater checkbox below that. When a user hovers over it states "auto check for updates using interval". But it doesnt state how long that interval is.

Perhaps this should be added so user know what interval is used?

screen shot 2018-04-04 at 8 02 36 pm

I did had an idea to get the data using;

 updater.set_check_interval(enable=auto_check_update,
					months=updater_intrval_months,
					days=updater_intrval_days,
					hours=updater_intrval_hours,
					minutes=updater_intrval_minutes
					)

But i got an error about tuple first. Then tried a different approach importing the updater from addon_updater.py (Singleton_updater) above the prefrerence panel. That way i could reach the _check_interval_days

from .addon_updater import Updater as updater

It grabs the standard days and shows this in the hover info.
screen shot 2018-04-04 at 8 40 45 pm

other option is to add in between after the boolean checkbox perhaps. Then the user will see the update interval directly. This also works, same method as i used above.
screen shot 2018-04-04 at 8 47 28 pm

It grabs the standard days set in the addon_updater.py file, it looks like this
screen shot 2018-04-04 at 8 42 01 pm

Update for Gaffer gives URL error

Hitting "Check for update" on Gaffer giver the error "URL error, check internet connection"
gaff

Gaffer 3.03
4-06-2017 BlenderBot build
Mac OSX 10.12.4

Error with 'include_master' option on

Hi,
I've integrated this updater with the Renderman for Blender addon. The versioning update works great but I've been seeing some odd behavior when the 'include_master' option is on.

If it is on and the auto update interval has passed, I am prompted to update to the latest master branch. However when I do that the updater does not install the latest version of master. Instead it pulls an older version (at least a commit or two prior), thus erasing new features and bugfixes.

However, if I ignore that prompt and manually select 'Master' from the 'install version/old version' dropdown then it will correctly install the latest master.

I haven't made any modifications to the two export modules other than changing the GitHub info and turning 'include_master' on.

Thanks for your help!

Ignore operator adds wrong context

v1.0.4

When the Auto-check is in on we see a popup, which is actually already double notification, and then we see the panel with the options. At the bottom it says "X ignore", to my understanding of meaning of ignore. Ignore should ignore the update warning, yet it doesnt. I do see the warning error and that i should check the addon pref. But the menu doesnt go away.

I went on and checked the code. #1284 > addon_updater should be as this:

def ignore_update(self):
	self._json["ignore"] = True
	self.save_updater_json()

When i change this to True, the update panel warning will go away. A tleast i think this how it should have been working. See below screengrab, with example how it is standard and after i edit the code quickly.

autoupdate_warning

update shows wrong version

i added your updater to an addon and noticed that it shows the update to the already installed version.
i was wondering if i possibly did some mistake configuring the update conditions or if this is a issue with the updater.

image

i also had a user report a version downgrade as update
image

Removing Old Modules

The Add-on updater doesn't appear to remove old modules that have been deleted. From what I can see the zip file is just unpacked into the add-on directory. Are there any plans to clean up any files that have been removed?

Support for Bitbucket

Goal: to support Bitbucket hosted code with minimal to no configuration change outside the python module.

Steps to take

  • Initial API exploration nd tests
  • Functional version and code grabbing for public repos
  • Functional with private repos using necessary keys etc

Question for generalized updater

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?

No module named 'blender-addon-updater-1'

This what I have when trying turn on the add-on after install.
blender\2.93\scripts\modules\addon_utils.py", line 351, in enable mod = __import__(module_name) ModuleNotFoundError: No module named 'blender-addon-updater-1'

Blender Version
Broken: version: 2.93.0, branch: master, commit date: 2021-06-02 11:21, hash: rB84da05a8b806

Cancel background check for update

A previous proposal from @carter2422 from before was to see if we could add a "cancel button" for while the background thread is running/checking for an update. This way, if the request tis taking too long the user can cancel it.

Ignore update popup persistence

From previous feedback, if a user presses the "dismiss" button for an update, it should remove the entire panel on the view so they must move to the preferences to check or run updates.

Also, if the user presses ignore, verify whether it persists after future updates complete or if the ignore popup remains silent. My thought is that pressing ignore would set a property in the preference for silent background checks if auto-check is enabled. This value is then loaded/set based on the persistent json saved date so that whenever it is toggled, the state is saved regardless if the user presses save preferences or not.

[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:720)

Hi,
I am trying to implement the addon updater into my addon. I have setup all basic steps. I left the repo and user name at defaults by now. Just to see if it gets a connection.

At work we use a proxy to connect to the internet. Could it be related to that?

Unfortunately I get the error message above. And within the blender console I get these errors:

Getting tags from server Exception in thread Thread-3: Traceback (most recent call last): File "C:\Program Files\Blender Foundation\Blender\2.79\python\lib\threading.py ", line 914, in _bootstrap_inner self.run() File "C:\Program Files\Blender Foundation\Blender\2.79\python\lib\threading.py ", line 862, in run self._target(*self._args, **self._kwargs) File "C:\Users\g041481\AppData\Roaming\Blender Foundation\Blender\2.79\scripts \addons\coa_tools\addon_updater.py", line 1309, in async_check_update self.check_for_update(now=now) File "C:\Users\g041481\AppData\Roaming\Blender Foundation\Blender\2.79\scripts \addons\coa_tools\addon_updater.py", line 1035, in check_for_update self.get_tags() # sets self._tags and self._tag_latest File "C:\Users\g041481\AppData\Roaming\Blender Foundation\Blender\2.79\scripts \addons\coa_tools\addon_updater.py", line 523, in get_tags self._prefiltered_tag_count = len(all_tags) TypeError: object of type 'NoneType' has no len()

Later I will check this from home and see if it works. I will report back. Still would be great if this works with a proxy so my colleagues could update the addon without hassle in the future.

Error due to creating folders without permission

As referenced in this issue on CrowdMaster, it seems sometimes windows users run into an issue if they don't have the right permissions and if the updater path doesn't already exist.

Recommendation: Developers should always pre-include/pre-create the updater folder or perhaps look into a different method to create folders that doesn't do absolute paths.
johnroper100/CrowdMaster#57 (comment)

Failures to delete directories

Context

Some users and myself have been having issues, all linked to filesystem operations, on Windows, with different Blender 2.7x/2.8x versions.

Relevant Addon using blender-addon-updater / Latest revision at time of writing

This isn't a permissions issue as the addon can create the *_updater folder

Issue 1

A user encountered this when trying to update

Click to expand

error in ui

delete folder errors in console

Deleting the folder manually allowed the updater to function properly then.

Issue 2

I also had weird issues originating from shutil (I don't have the logs anymore sorry) which may have been due to paths being too long

The real issue being that those paths became too long because the addon was backuping its backups, after failing to delete previous backups. shutil failed midway through traversing the directory tree.

Fix

?

I think it would be better to not catch-all and ignore exceptions like here, because it clearly prevents us here to actually understand what's going on.

Certificate verify failed (_ssl.c:645)

I've got SSL certificate verify failed, when pressed the button, any hints fo this

below the error log

Traceback (most recent call last):
  File "/usr/local/blender/2.78/python/lib/python3.5/threading.py", line 914, in _bootstrap_inner
    self.run()
  File "/usr/local/blender/2.78/python/lib/python3.5/threading.py", line 862, in run
    self._target(*self._args, **self._kwargs)
  File "/home/aditia/.config/blender/2.78/scripts/addons/PSTools/addon_updater.py", line 1033, in async_check_update
    self.check_for_update(now=now)
  File "/home/aditia/.config/blender/2.78/scripts/addons/PSTools/addon_updater.py", line 783, in check_for_update
    self.get_tags() # sets self._tags and self._tag_latest
  File "/home/aditia/.config/blender/2.78/scripts/addons/PSTools/addon_updater.py", line 412, in get_tags
    self._prefiltered_tag_count = len(all_tags)
TypeError: object of type 'NoneType' has no len()

Update to latest master

Could a function be added to update to the latest master version of the code? This would be for users who would like to try out different new features before the next release.

Licensing

Let's get this thing licensed before going much further.

@TheDuckCow unless you feel strongly towards a different license, I vote we just for GPL3, same as RetopoFlow.

Version restriction

Previously there was a request to create or allow the developer to add a function which restricts the versions to be installed by the updater. This could, as one example, prevent the user from downgrading too far. Ultimately, we could also put checks in for blender versions but would be up to the developer how restrictive this is.

This feature is currently already implemented in the code via a function that the developer passes into the register function, assigning it to an updater class object which is used as a callable whenever checking the versions from the server.

GitHub API shouldn't be trusted for tags order

Context

I'm using this updater for an addon (irrelevant I think but here it is https://github.com/CrookedPoe/io_export_objex )

Configuration part of addon_updater_ops.py : https://github.com/CrookedPoe/io_export_objex/blob/master/io_export_objex2/addon_updater_ops.py#L1354

Issue

At the moment there are two tags 2.79_only and 2.0.0, created in that order. The updater thinks 2.79_only is more recent though.

2.0.0 is indeed more recent as per the releases page https://github.com/CrookedPoe/io_export_objex/releases (screenshot below)

screenshot of releases on the 11th of august

What the GitHub API says

The API indeed puts 2.79_only first

https://api.github.com/repos/CrookedPoe/io_export_objex/tags

[
  {
    "name": "2.79_only",
    "zipball_url": "https://api.github.com/repos/CrookedPoe/io_export_objex/zipball/2.79_only",
    "tarball_url": "https://api.github.com/repos/CrookedPoe/io_export_objex/tarball/2.79_only",
    "commit": {
      "sha": "1af434a1c02f8c36f8930f64b192fba59fa68d93",
      "url": "https://api.github.com/repos/CrookedPoe/io_export_objex/commits/1af434a1c02f8c36f8930f64b192fba59fa68d93"
    },
    "node_id": "MDM6UmVmMTQ2MjMyOTAyOnJlZnMvdGFncy8yLjc5X29ubHk="
  },
  {
    "name": "2.0.0",
    "zipball_url": "https://api.github.com/repos/CrookedPoe/io_export_objex/zipball/2.0.0",
    "tarball_url": "https://api.github.com/repos/CrookedPoe/io_export_objex/tarball/2.0.0",
    "commit": {
      "sha": "7c5cf5879f92da930fec7f1b9df47ed346935e12",
      "url": "https://api.github.com/repos/CrookedPoe/io_export_objex/commits/7c5cf5879f92da930fec7f1b9df47ed346935e12"
    },
    "node_id": "MDM6UmVmMTQ2MjMyOTAyOnJlZnMvdGFncy8yLjAuMA=="
  }
]

As per the blender/blender tags more recent should indeed be first though: https://api.github.com/repos/blender/blender/tags

Cause

I pushed (git push --tags) the two tags in the same git push so that may be why this happens

Fix

I think the addon should somehow sort tags correctly, based on latest commit or somehow getting the tag time like on the releases page, since the GitHub API doesn't seem to sort tags as is thought

It may be best as an option since I guess it would take more requests over the internet

I am not familiar with the GitHub api, not sure what exactly can be done

In the mean time, is there an option to set in addon_updater_ops.py that could make 2.0.0 the chosen tag instead of 2.79_only?

Updating the updater module

Currently, when changes are made to addon_updater.py and or addon_updater_ops.py, the developer of each addon that it is used in has to manually updates the files. Is there a way that the updater could update it's own files? There may be some problems if a developer wants to customize the code though...

Blender 2.93a - ValueError: Enable must be a boolean value

Hi, thanks for this addon. It's a great addition to my addon.
It seems like there is an Error when running the updater on Blender 2.93a from the Blender build.

\blender-addon-updater-master\addon_updater.py", line 535, in set_check_interval
raise ValueError("Enable must be a boolean value")
ValueError: Enable must be a boolean value

I'm assuming there was some API change for property assignment. Does anyone knows something about it?

Setup for single-file addons

Currently, the addon updater only supports addons with a .zip configuration. While this is cleanest and most recommended for addons to include additional modules such as this one, it is feasible from a technical standpoint to integrate the updater all into a single file.

The goal here would be to make an additional python demo/source file which has all of the UI and updater module class squashed into one file. The steps to integrate into existing addons would be similar, except instead of including addition files, the developer could just copy-paste all the updater code to the end of their existing single-file addon.

This is just a thought and proposal. Maybe we shouldn't actively try to support this design since it entangles updater code with addon dev code.

Show update logs if available

If there are update logs available, display the text of the log.

This would potentially entail parsing and finding a way to better display or show markdown in blender. Some thoughts/related considerations

  • Logs are only available with tags that are also "releases", but may still be blank
  • Currently the updater works based on tags and not releases (the setting "use_releases" still needs to be implemented to alternatively use releases over tags)
  • Be able to display the change log in a UI list
    • Here, we should strip down the markdown code in some meaningful way.
    • Should auto determine the "word wrapping" to generate multiple lines in a scrolling list view
    • If feeling super fancy, could even place inline buttons for web urls; certain icons could be used for things like bullets etc.
  • Remove or just provide direct links to things like images/video
  • There should also be easily available buttons to view the log in the text editor (generate a new text block with full markdown code) as well as to view the release logs online.
  • The first version of showing logs doesn't need the bells and whistles of parsing the markdown, but at minimum needs the word wrapping capabilities.
  • Save current version logs in the json file; upon running check, can even also grab the current version log if not already local (perhaps launch as a secondary background check so that getting the current status is quicker).

Current concept:

log_concept

reload_addon in 2.8x

The issue

reload_addon() is failing in Blender 2.82:

  File "...\Blender\2.82\scripts\addons\...\addon_updater_ops.py", line 377, in execute
    clean=self.clean_install)
  File "...\Blender\2.82\scripts\addons\...\addon_updater.py", line 1349, in run_update
    res = self.unpack_staged_zip(clean)
  File "...\Blender\2.82\scripts\addons\...\addon_updater.py", line 933, in unpack_staged_zip
    self.reload_addon()
  File "...\Blender\2.82\scripts\addons\...\addon_updater.py", line 1054, in reload_addon
    bpy.ops.wm.addon_disable(module=self._addon_package)
  File "C:\Program Files\Blender Foundation\Blender 2.82\2.82\scripts\modules\bpy\ops.py", line 201, in __call__
    ret = op_call(self.idname_py(), None, kw)
AttributeError: Calling operator "bpy.ops.wm.addon_disable" error, could not be found

The reason

reload_addon in addon_updater.py

		bpy.ops.wm.addon_disable(module=self._addon_package)
		bpy.ops.wm.addon_refresh()
		bpy.ops.wm.addon_enable(module=self._addon_package)

Apparently at some point those operators moved from bpy.ops.wm. to bpy.ops.preferences.

A fix

Replacing the previous code excerpt with this allowed the module to reload in Blender 2.82:

		try:
			# < 2.80
			bpy.ops.wm.addon_disable(module=self._addon_package)
			bpy.ops.wm.addon_refresh()
			bpy.ops.wm.addon_enable(module=self._addon_package)
		except AttributeError: # 2.80+
			bpy.ops.preferences.addon_disable(module=self._addon_package)
			bpy.ops.preferences.addon_refresh()
			bpy.ops.preferences.addon_enable(module=self._addon_package)

Not sure except AttributeError is the best check. hasattr doesn't seem to be a possibility under bpy.ops for reasons I don't know/understand

Version 1.2.0 doesn't work in Blender 2.82

Addon installs perfect. But doesn't let itself activate. After that the old one doesn't work anymore. Can't find what causes this. But not happy with this.

Error message in old version (1.1.0):
Error: Traceback (most recent call last):
File "C:\Users\gerar\AppData\Roaming\Blender Foundation\Blender\2.82\scripts\addons\chocofur_model_manager\controller.py", line 226, in execute
process_object(obj)
File "C:\Users\gerar\AppData\Roaming\Blender Foundation\Blender\2.82\scripts\addons\chocofur_model_manager\controller.py", line 221, in process_object
scn.update()
AttributeError: 'Scene' object has no attribute 'update'

Error message in new one I cannot reproduce anymore, because after first de-installation of the addon and adding it again, the error message changed. It now says the script doesn't exist.
But this is a different message then the first one.

All addon updaters will not work on blender 2.79a and earlier (OSX only, SSL issue)

IMPORTANT UPDATE (via @TheDuckCow)

Due to a recent change in GitHub's allowed SSL standards, Blender 2.79a and earlier users on Mac OSX will not be able to use the updater, and will see the below screenshot. This only applies to users of Mac OSX blender versions 2.7X and GitHub hosted repositories. There are no issues for GitLab or Bitbucket hosted repositories, and Github-hosted addons continue to work fine on linux & windows. No fix is currently available for OSX blender <2.8 users.

Update February 2019: GitLab is now affected in the exact similar way. Note that Bitbucket-hosted repositories will still function in 2.79 and earlier; all work appropriately in 2.8.

ssl_error_updater
What OSX users would see prior to the v1.0.5 release

Update - release of v1.0.5

The latest release of the updater code does not fix this issue (since it is a server side/blender compiling lack of compatibility), but it does at least more directly acknowledge the error and provide the user with a manual-download solution if affected. Those not affected with continue to see the updater working as normal. Behavior for those affected is as follows:

ALT

ORIGINAL ISSUE POST

(Original issue title: After network downage is get a tlsv1 error)

rv 1.0.4
bl 2.78c
OSX

After my internet went down i see this error
ssl tlsv1_alert_protocol_version

Weird thing is internet works just fine and before that the updater worked just fine. I also see this in the console
Exception in thread Thread-3: Traceback (most recent call last): File "/Applications/blender-2.78c/blender.app/Contents/Resources/2.78/python/lib/python3.5/threading.py", line 914, in _bootstrap_inner self.run() File "/Applications/blender-2.78c/blender.app/Contents/Resources/2.78/python/lib/python3.5/threading.py", line 862, in run self._target(*self._args, **self._kwargs) File "/Users/PromotieSpullen/Library/Application Support/Blender/2.78/scripts/addons/addon_updater/addon_updater.py", line 1309, in async_check_update self.check_for_update(now=now) File "/Users/PromotieSpullen/Library/Application Support/Blender/2.78/scripts/addons/addon_updater/addon_updater.py", line 1035, in check_for_update self.get_tags() # sets self._tags and self._tag_latest File "/Users/PromotieSpullen/Library/Application Support/Blender/2.78/scripts/addons/addon_updater/addon_updater.py", line 523, in get_tags self._prefiltered_tag_count = len(all_tags) TypeError: object of type 'NoneType' has no len()

Can't install Addon

Im developing in vs code and connecting it to blender via Jacques Luckes extention.
Everything works nicely and no errors but when I push to git, download the release and try to install it from scratch I get this error if I try to enable the addon :

image

It seems that a -0 is added somewhere to the module name but I don't get where .

The repo is here : https://github.com/LorenzWieseke/GLBTextureTools/releases

Thanks in advance !

Add option to install from local folder

Primarily useful for developers, create a configuration that allows reloading the addon from a local folder instead of from online. It may be useful to click inside the addon in blender directly to update code changes. This could be accomplished in a few ways, but an appropriate design may be:

  • If enabled, user pastes in a folderpath
    • This path is to the folder of the init file of where the code sits as it's being developed; need not be a git repo, but pretty much always would be I'd expect
  • Then from the install other/target option, you can select from the dropdown "Local" and press okay
    • Would be nice to even reduce those three clicks (button, dropdown, confirm) into just one without making to make weird UI choices
  • The addon then gets the list of python and resource files available in the blender addons folder, and does a comparison to the files in the target folder: if a file in /blender/addons/updater exists also in /devpath/updater/ then it will copy it over; this prevents the issue of copying .git folders or other files that perhaps you don't need in the target space
  • User would then still be advised to close/reopen blender, but they may also be able to get away with the "refresh" setting enabled.

Personally, I think this will be very useful! I hear there are some developers who already simply use the dev branch for reloading changes to test via committing to dev branch and reloading in blender, this would then be more direct meaning you don't have to push potentially broken code just to easily load into blender.

I'm sure there are also gists or snippets of python code out there for conveniently reloading addons, so perhaps something there could also be leveraged.

Reverting to prior version should clear out the "up to date" flag

If you revert to an older version, such as from 1.1.3 to 1.1.1 then the update status still reads as Add-on is up to date, which is now incorrect.

Upon reversion we need to be sure to clear out the updated status so that it properly shows that an update is available.

Support for custom branch(s)

Having the ability to give the option to update from the master branch is awesome, but in some situations master may not be the actual development branch. It would be nice to be able to specify (in addition to master) other branches to add to the list of versions to update from.

Great feature, couple thoughts.

So we're integrating this to the RenderMan for Blender addon. Really think this is the missing piece for addons in Blender. Very clear code and instruction thanks!

Really my only question is the default of 7 days for the update. I'd claim that 1 day is fine! That's what we set.

GPL license.

So, kinda a high priority issue here. I just realized that the addon updater code is done under the GPL license. This makes it impossible to use under MIT license addons. (Without the addons being switched to GPL). Many people hate this, and it will become unviable very quickly. We are probably going to have to remove this from RenderMan for Blender actually sadly.

Have you thought about dual licensing MIT and GPL? Pretty common, jquery does it for instance.

Updating for multiple OSs

Now that we are moving CrowdMaster over to python, we need to make separate released for macOS, Windows, and Linux. Currently, the addon updater does not know the difference between OSes. Would it be possible to have a system that reads in three different release repositories and downloads the correct version for the user's OS?

GitLab authentication errors

Recently, some change with communicating to the GitLab api is making all requests fail. The solution is to include a user-agent to the requests for the download archive api endpoint. This applies to both public and private repositories.

Need to test that this does not affect any of the other updates negatively, but providing a user agent generally is best practice and anyways should be done.

404 error when trying to reach gitlab update

Hi !

Don't know if its an error on my side or a gitlab api change but I get an http error when trying to access release or master.

Console log :

Checking for update function
pipe_sync Updater: Read in JSON settings from file
Getting tags from server
HTTP error 404
master branch found, no releases {'name': 'Master', 'zipball_url': 'https://gitlab.com/api/v4/projects/pipe_sync/repository/archive.zip?sha=master'}
pipe_sync: Wrote out updater JSON settings to file, with the contents:
{'last_check': '2020-07-10 10:31:45.006835', 'backup_date': '', 'update_ready': False, 'ignore': False, 'just_restored': False, 'just_updated': False, 'version_text': {}}
pipe_sync BG thread: Finished checking for update, doing callback

here is my repo : https://gitlab.com/pullusb/pipe_sync

I specified this settings in updater_ops:

updater.engine = "GitLab"
updater.user = "pullusb"
updater.repo = "pipe_sync"
updater.website = "https://gitlab.com/pullusb/pipe_sync"

and up above :

# Must declare this before classes are loaded
# otherwise the bl_idname's will not match and have errors.
# Must be all lowercase and no spaces
updater.addon = "pipe_sync"

Can you tell me if I missed a step in the setup ?
I used the updater on another addon on github that works without issues...

version_max_update default

Currently it's 9.9.9... I'd claim it should be higher, i.e if my version is 10.0.0 it won't pass the test.

or do something like set max to -1 or none for no max.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.