Dev:2.8/Source/PackageManager

提供: wiki
移動先: 案内検索

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.