@Moraes, agree we should really have something like this! Just to note that addons can be `installed` as zip files currently - so all a tool needs to do at a very basic level is to extract files into a dir.
(yes there is possible dependency hell and how to manage un-installing. but for now most addons are in 1 dir and don't depend on others so lets ignore those problems for the purpose of discussion). Regarding addons not always installing - its really the job of the author to make sure they do, its very simple (addon in a zipdir) - probably they put it in a sub-sub-dir and it gives problems I'm also wary of adding yet-another-layer over addons, but think this can work as an online installer/repo - simply saves us distributing every addon/theme/material with blender. Some options are. .. - Web front end which can interact with blender (as suggested before) - don't have anything to add to this, I don't know web programming. - Do something like the "Eclipse-IDE" - In-application extension installer. where you point it to a number of URL's which are sources for extensions - people could host own extensions repo if they really wanted, this can manage checking for updates and listing available extensions. - Use pythons own packaging system - "easy_install" or "pip", didnt investigate it but since py has a packaging system could be useful, suspect its overkill for our purpose though. Note that this is more of a backend - so could use any kind of web/gui frontend. However we get the issue of how to store this data, manage logins - trust who uploads files etc. As much as worrying about multiple addon-overlays I'm concerned with multiple (too many!) ways for devs to contribute (having to give devs access to multiple logins / repos). Personally I'd like whatever system we use to be a front-end to source control (so devs commit our extension repo and magically get listed) - but my impression is many scripters just want to upload a zip over a web interface - or something as simple. However I really don't like to loose the benefits of source control. Though we could just assume devs have their own source-control and these online extensions are working snapshots of that - like how many packaging systems work. It would be good to avoid having to write our own linux-distro style packaging system, if we can keep it simple+workable we give ourselves a lot less problems. - Campbell On Tue, Jan 10, 2012 at 7:47 AM, mindrones <mindro...@gmail.com> wrote: > Hi. > > RE: wiki > ------------------- > > It always amuses|depresses me when I hear talking like that about the wiki. > > Not that I'm a mediawiki fanboy (and I mean it) but let's face it: > millions of people use Wikipedia to _communicate_, and I don't hear > them lament as much as I hear in the blender circles. > > The wiki syntax is very simple and you hardly need to use deep/nerdy > stuff to express your idea or knowledge. > > See http://www.mediawiki.org/wiki/Help:Contents#Editing to get going > (avoid the advanced section, you don't really need it to write simple > text). > > Even if it was a bit more complex (and as you can see it's not) from > people that use Blender I'd expect it's a snap. > > IMHO it has more to do with some people in these circles being (or > feeling :P) "artists" and hence having a natural sense of rejection > towards hierarchies/organization/structure and (oh my!) rules. > I can understand that, and writing documentation is boring and not > fun, but it's the act of documenting being boring, not the tool > per-se. > > Long story short, IMHO it's just a pre-concept (or in many cases, > lazyness) stopping you from using the wiki. > > > RE: addons > ------------------- > > There has been discussion and a proposal for a similar project, see > > http://wiki.blender.org/index.php/User:Mindrones/Bf-extensions/External_addons > > but for a lack of time it just didn't happened yet. Not perfect but > still I provide the link as a reference in case it can be useful. > > Here again, I'm pretty much amused (but again also quite depressed) > when I hear people lamenting the current situation of bf-extensions > repository. Try to do a leap back to 3 years ago and you'll understand > what I mean. > Even if you were lucky enough to find the script you wanted in google, > you had to report bugs to the developer in mail or via forum, and the > fix was uploaded to some personal website or worst, on some sharing > site (which is the reason why we deleted all the external links from > scripts when we started): most of them were just broken. > > So, again, IMHO it's just a pre-concept that things are so awful in > bf-extensions. > > I don't like the idea of having separate repositories from the one in > BF svn, and pretending that they become "official" (distributed in or > through blender), for the simple reason that if you can put work into > those projects you could instead put effort in the BF repository > project, and help improve stuff, review scripts, provide patches, > gather people, explain some basic rules, spread the word, etc: it > would grow a lot faster and healthier. > > Bf-extensions is not perfect, and yeah there are some rules, but they > have been decided based on common sense and they work well if, as said > in a previous mails, you want to share with the public. > > > Regards, > Luca -- - Campbell _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers