Dev:2.8/Source/PackageManager

Package Manager Design Doc

Some design overview of how addons auto-update should work (or how it should not work)

Basic Requirements

Add-on update should:

• Be unblocking, meaning interface should be responsive during all update procedure
• Non-intrusive, meaning it should not do things silently, without artists asking to actually update addon or all add-ons.
• Gracefully handle any exceptions, rollback to a previously installed addon if any update error happens
• Perform functionality to update to any version (including older ones)
  for the cases when some regression happens in addon and stops production
• Any failure with installation/connections/partially successful downloads… etc
  must be cleanly recovered from.
• Hanging processes must be handled elegantly. (using time-out for eg).
• Be flexible in design to support both public addons update and addons which are distributed via cloud, blender market and so on
• Never store any credential details
• Not require any separate tool (git / svn / hg) to be installed separately from Blender
  (Plain Python + Requests should easily be enough in this case).
• Support multiple repositories
  (not be locked into a single repository).
• Possibilities to be used for non-addons (Not essential, however as add-ons are simply a package of data we’re not concerned with exact details of their contents, there is no reason to hard-code in add-ons… other kinds of extensions may be useful)

Open Topics

• Support mirrors?
• Package signing?
• Binary packages? (please no!)
• Package format? (we can postpone this one)
• How to handle version compatibility?
  (when updating Blender breaks a package or the other way around).
• Support for multiple Blender versions.
  (The possibility for a package provider to host a single package for multiple versions - but maybe eventually useful to support!).
• Authentication?
  (which auth model to use, do we support multiple ones etc)
• Find a good real-world addon(s) which can be used for demonstrating the system in real action
  (without all this “works with my localhost!” rubbish)

Big Picture

• Q: Why do this at all?
  A: As add-on development has increased, developers are choosing not to use Blender’s repositories for their own projects and instead using 3rd party source hosting.
  Having to manually install and update add-ons isn’t so convenient.
  Its also nice for developers to be able to send updates to users more easily.

• Q: Who is this for?
  A: This is for users, developers who want their users to be able to access their latest work.
  Also for companies who develop add-ons, however this will remain vendor agnostic.