I was wondering today about how feasible something like this is: A system that allows you to download and install an addon with the click of a button, as well as tell you if an update is available to something you already have installed and update that with one click as well.
It would theoretically use the SVN/Git collection of trunk and contrib* addons and periodically check if an update to those already in Blender is available. Additionally, it would fetch an external database of Addons that are not a part of trunk or contrib and show an entry for each of these just like any other addon, only instead of an ‘Enable’ check-box, you’d have a ‘Download and Install’ button.
This would fetch the addon from the server, downloading it to a temporary place, and install it for you. Simple yeah?
That much is easy, in fact it’s literally 3 lines of code. The problem with this idea is maintainability and flexibility. The whole point of it is to show a repository of addons from external sources, since trunk addons are already there and updated every release, and contrib ones come with most graphicall and build bot builds – however we still have to somehow control what addons are in this repository, allowing anyone and everyone to add to it would be messy and a serious security risk (imagine you enable a cool looking addon that promises a one-click character rig, only to find its a piece of malware with a keylogger).
Someone has to maintain this repository personally, which leaves the question of how best to do this with minimal regular effort? You could update it only once a week perhaps, but you still need a way to automatically go through the database of scripts and find out which has a newer version available. This means that for each addon you’ll need some custom method of checking for new versions, some developers will update the same file on a server, while others might increment a number and leave the old file in place (auto_tile_size_release_03.py for example)
(mockup)
I’m not the first to have this idea. Campbell wrote a primitive one a while ago, and Gaia Clary apparently as well. They encountered the same problems. The script itself is trivial, the maintainability is not.
I don’t often like to publicize these mad ideas of mine, they don’t normally lead to much, but this time I’d like to ask if you have any suggestions for me – how can I do this simply and only have maybe 20 minutes work per week on maintaining a database of addons? Should I store the addons on my own server, or rely on the original source? Perhaps only include those in the external column of the wiki page? What about asking developers to contribute to this repository and update it each time they release a new version? If so, how best would we combat low quality addons and potential security issues?
The UI mockup at the top of this post is a quick one – I’d still need to handle categories and such, and I might as well edit the existing UI instead of creating my own.
* The Trunk set of addons are those included in Blender by default, stuff like importers and the very useful ones such as Looptools and Node Efficiency Tools. The Contrib set is a collection of addons not included in the official release of Blender, but still officially approved by Blender devs and can be trusted that they’re pretty darn good.
I think this could be very very useful feature. So +1 for this one!
And maybe blender foundation could provide space for this kind library?
Eventually perhaps, but for now I’d rather it’s unofficial – this means I don’t have to make it perfect ;) if/when it’s used more and has been through lots of testing in corner cases perhaps we can think about including it in trunk, or even replacing the existing system [?]
I am glad you have put this idea forth. I think its a great idea.
I know that for vim (the text editor) there are projects which support downloading plugins and extensions from git repos. Look at for examplehttps://github.com/carlhuda/janus — this is a preconfigured set of vim settings / and plugins. Developers can customize it, by specifying additional git repos. I think sublime text 2 packages can be configured to work the same way.
As for your security and maintainability concerns, they are probably warranted. But using SCM as a means for delivering add-ons means that the source is readily available for review. Currently I think many users read about an add-on in a forum and then just unzip and run.
#1) The simplest thing is probably to maintain the add-on manager and its “database” (list) off ‘official’ or ‘vetted’ is maintained as a config file in that project. People could submit pull requests specifying new add ons, which could then be reviewed by folks following the project.
#2) Slightly more work would be setting up a simple server where the list of official add-ons is managed. The advantage being that meta-data could be added, and you could possibly out-source some of the add-on vetting to community consensus. In addition to a git/svn repo / url for the add-on, there could be ratings, reviews, text descriptions, documentation, and screen-captures. Another important piece of meta-data is the blender-version dependency information. (This plugin is known to work with version xx of blender. For version xx of Blender see vesion xx of this addon… *shudders* )
I would do the simplest thing that works, however… If you decide to go for the second route, I could *possibly* offer to help with the server part of #2, though I worry about saying that, because I don’t have much free time these days.
Thanks for the ideas, I think I’m leaning towards #2, I might poke you later for some help ;)
Each addon could have its own Github (or some other Git server) and be mantained there. The addon manager could be an index of these reps. To filter bad code you could let users upvote addons, that way you’d have 2 channels: “edge” and “stable”. Addons within a certain threshold of votes would be in stable, everything else in edge (or greenlight, or something like that).
The Package Control system from Sublime could serve as inspiration: https://sublime.wbond.net/docs/developers
Each having it’s own Git server would be a bit unnecessary, but a perfect solution if the dev is already working on a Git server and I just steal the link from there. There are some repositories of addons already, such as the one maintained by Italic and Meta-Androcto (https://github.com/meta-androcto/blenderpython/tree/master/scripts/addons_extern) – when I next see them on IRC I’ll talk to them about using this instead of my own server – they seem to maintain it quite nicely..
I suggest requiring that documentation be available. its usually a good tell of quality of product if the documentation is good. even if its just a youtube vid.
Require that the code be reviewed by at least one other scripter, share the burden of responsibility.
Use the Bodega API, its documented, Libre Server and Client, maintained by KDE, Simple API REST
http://apidocs.makeplaylive.com/bodega
+1 from me too for this concept!
It is the best! All blender wiki addons catalog can be configured to RSS or something, that user can download directly to blender config window and choose as in ubuntu software center ))
Great idea. It is better use your (better blender foundation space) for addons hosting. When you add some statistics (number of downloads and rating by stars) it will also great for addon quality. And some sorts function. Sort by rating … etc. So it can be great global place for all plugins.
Yes, global place for all plugins is very welcome. There is so many hidden “jewels” (addons) for blender. And this addon could make them more visible to all.
Take a look at https://npmjs.org that is a package manager for node.js (Server-Side Javascript) it has a simple policy: everyone can contribute modules and users/developers have to pick if themselves they are ok or not. Inserting a controling organisation that filters out dangerous addons is basically against the open-source idea.
As the source of addons must be open dangerous addons can be spotted pretty fast and would be flamed in no time.
The community mostly controls itself and open-source tends to produce non-malware (mostly).
I would not host any addon code on the server, just the meta-data for an addon and the places where it can be downloaded.
In npm there is a package.json in each module which holds the metadata. This is the only requirement a module needs to become a module.
Rating systems, comments and such are nice, but not necessary. They could be delivered later, when a basic repository/package manager like that is established and well used. If it has a public API (what I really recommend) then others can create such platforms to integrate rating/commenting.
I think at it’s best is for you to create a way for each developer to easily integrate this into their own addon, let’s call it a standarized way for them to keep them up to date, so you’d input a folder in your server that actually checks for the latest version, and when you open the addons panel each addon taht you have activated will refresh on that folder of each server. make sense?
This is a clever idea, Greg, and would add to Blender’s usability feature, nonetheless.
As far as suggestions on systems implementation goes though, I don’t have any at the moment.
What I do have is a moral support for you in this effort and if you’d like someone to test this out, I’ll be a Guinea pig.
Keep us posted how this goes.
-Reyn
Just to hop on the train, I want to +1 this.