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.