https://wiki.blender.jp/index.php?action=history&feed=atom&title=Dev%3A2.8%2FSource%2FPackageManagerDev:2.8/Source/PackageManager - 版の履歴2026-07-05T20:54:29Zこのウィキのこのページに関する変更履歴MediaWiki 1.31.0https://wiki.blender.jp/index.php?title=Dev:2.8/Source/PackageManager&diff=150955&oldid=prevYamyam: 1版 をインポートしました2018-06-28T21:16:11Z<p>1版 をインポートしました</p>
<table class="diff diff-contentalign-left" data-mw="interface">
<tr class="diff-title" lang="ja">
<td colspan="1" style="background-color: #fff; color: #222; text-align: center;">← 古い版</td>
<td colspan="1" style="background-color: #fff; color: #222; text-align: center;">2018年6月28日 (木) 21:16時点における版</td>
</tr><tr><td colspan="2" class="diff-notice" lang="ja"><div class="mw-diff-empty">(相違点なし)</div>
</td></tr></table>Yamyamhttps://wiki.blender.jp/index.php?title=Dev:2.8/Source/PackageManager&diff=150954&oldid=prevwiki>Lijenstina: /* Big Picture */2017-01-30T01:17:06Z<p><span dir="auto"><span class="autocomment">Big Picture</span></span></p>
<p><b>新規ページ</b></p><div>= Package Manager Design Doc =<br />
<br />
Some design overview of how addons auto-update should work (or how it should not work)<br />
<br />
== Basic Requirements ==<br />
<br />
Add-on update should:<br />
<br />
* Be unblocking, meaning interface should be responsive during all update procedure<br />
* Non-intrusive, meaning it should not do things silently, without artists asking to actually update addon or all add-ons.<br />
* Gracefully handle any exceptions, rollback to a previously installed addon if any update error happens<br />
* Perform functionality to update to any version (including older ones)<br>for the cases when some regression happens in addon and stops production<br />
* Any failure with installation/connections/partially successful downloads… etc<br>must be cleanly recovered from.<br />
* Hanging processes must be handled elegantly. (using time-out for eg).<br />
* Be flexible in design to support both public addons update and addons which are distributed via cloud, blender market and so on<br />
* Never store any credential details<br />
* Not require any separate tool (git / svn / hg) to be installed separately from Blender<br>(Plain Python + Requests should easily be enough in this case).<br />
* Support multiple repositories<br>(not be locked into a single repository).<br />
* 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)<br />
<br />
== Open Topics ==<br />
* Support mirrors?<br />
* Package signing?<br />
* Binary packages? (please no!)<br />
* Package format? (we can postpone this one)<br />
* How to handle version compatibility?<br>(when updating Blender breaks a package or the other way around).<br />
* Support for multiple Blender versions.<br>(The possibility for a package provider to host a single package for multiple versions - but maybe eventually useful to support!).<br />
* Authentication?<br>(which auth model to use, do we support multiple ones etc)<br />
* Find a good real-world addon(s) which can be used for demonstrating the system in real action<br>(without all this “works with my localhost!” rubbish)<br />
<br />
== Big Picture ==<br />
* Q: Why do this at all?<br>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.<br>Having to manually install and update add-ons isn’t so convenient.<br>Its also nice for developers to be able to send updates to users more easily.<br />
<br />
* Q: Who is this for?<br>A: This is for users, developers who want their users to be able to access their latest work.<br>Also for companies who develop add-ons, however this will remain vendor agnostic.</div>wiki>Lijenstina