<div dir="ltr"><div><div><div><div><div>I think that it's a great idea--but the devil's in the details. I think you need to have a good guiding vision to help you make the decisions about the implementation--a top-down design<br>
<br></div>On the client side, you have to have information about what packages are installed, where they're installed, what flavor of pd they are installed for, version information, more?<br></div>Dependencies: within Pd, you could be distributing patches that require some externals--I think it's best for a Pd package system to only reference dependencies that include other abstractions or externals, not system libraries.<br>
</div>Maintenance: a system like this needs to be *easy* to maintain---only a few binary targets can be supported. The rest will need to compile from source.<br><br></div>I would start out like this.... make a list and argue point-by-point until you have a clear plan. <br>
</div>Not that I'm much one to *complete* my projects... but I have a lot of insight on failing :)<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 4, 2013 at 3:10 AM, colet.patrice <span dir="ltr"><<a href="mailto:colet.patrice@free.fr" target="_blank">colet.patrice@free.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>Hello, that's a quite interesting subject I've been thinking about for pdx since a time, thank you for the contribution... like you said it might be complicated to resolve all dependences required by an external, so I think that adding other dependences like php sql or json would make it even more complicated... Why not just using the native client interpreted langage, TCL-TK? With the help of a command line like wget included with the tcl script and a bunch of pkg files that should be enough, wouldn't it?</div>
<div><br></div><div><br></div><div><br></div><div><br></div> <br><br><br>-------- Message d'origine --------<br>De : <a href="mailto:fls@rendera.com.br" target="_blank">fls@rendera.com.br</a> <br>Date : 03/02/2013 20:22 (GMT+00:00) <br>
A : <a href="mailto:pd-list@iem.at" target="_blank">pd-list@iem.at</a> <br>Objet : [PD] Plugin auto install feature to Pure data <br><div><div class="h5"> <br><br>Hi list<br><br>I would like to write before but unfortunately I couldn't. Some weeks ago<br>
people started to talk about the development of some auto install<br>mechanism to Pure Data, like the apt-get. It is an amazing idea. I<br>researched and developed some thing like it to my master degree and I<br>would like to contrib with my 3 cents.<br>
<br>I studied the plugin structure of Netbeans, Eclipse, Fire Fox, deb and rpm<br>and my contribution is about it. Sorry if I am a little bit prolix.<br><br>The first thing is to create a plugin package. A a single file to group a<br>
lot of files. It can be a zip package, tar, gzip or anything that already<br>has some C open source API to pack / unpack. This way we can upload /<br>download a single file and extract it localy. I will call it the package.<br>
<br>Inside the package is necessary to have a package descriptor. It can be a<br>XML file, CSV, txt, JSON or any kind of structured file to describe the<br>content of the package. This file should have the information about the<br>
plugin like the author, version, website, license, OS, dependencies,<br>compatibility with PD "flavors" (vanilla, extended, Lork ....),<br>pre-installation script, post-installation script, uninstall script, key<br>
words, ...<br><br>Pre and post installation script are used to create SQL tables, files or<br>other things. Maybe it is not useful in PD. Uninstall script should clean<br>the mess if you want to remove a plugin. Dependencies is a complex problem<br>
because it should care about libraries and circular dependencies. Maybe it<br>is the hardest problem to solve.<br><br>These two things will define the PD plugin: The package file and the<br>plugin descriptor inside the package. The package structure should be<br>
defined as a standard. So we should agree, for example, about the name of<br>the descriptor, the folder where the plugin will be and the name of the<br>package file. Probably a package file can be the name of the<br>external.version.something.pd_pkg.<br>
<br>In PD we should have a list of installed plugins. It can be a directory<br>with all the plugin descriptors. The user might be able to install new<br>plugins manually. It means a local file in my machine that I choose. PD<br>
will open the package, copy the content to the correct folders and copy<br>the descriptor the the correct folder. The uninstall option will do the<br>oposite, delete the plugin descriptor and delete the plugin files.<br><br>
To update from the web, a plugin repository need to be defined. The client<br>should have a list of repositories address. (It is good because different<br>flavors can have their own plugin repositories and the users can choose<br>
which one they want to use.)<br><br>The plugin server can be implemented with a HTTP server. It will publish<br>the list of available plugins on the server. This list can be the list of<br>package descriptors in a tar / zip file. Locally, PD will keep these<br>
lists, one for each server, and it will be used to look for new plugins.<br>Add a new server means add the server to the repositories list and<br>download the plugin list of the new server.<br><br>Since PD has a list of local installed plugins, if you want to check for<br>
updates PD compares the servers plugin lists with your local list. Easy<br>task. Different versions should can be shown and the user would be able to<br>choose what to update. These descriptors can be useful also to search for<br>
plugins by author, version, key words, versions, ...<br><br>Update a plugin means to create a list of update, download the packages to<br>a temp directory and install them locally.<br><br>Just to step foward, the server can have a web interface with some PHP<br>
programming, for instance, that automatically update a package, extract<br>the descriptor, put it in the correct folder and put the plugins in the<br>correct folder. Just to be easier to maintenance.<br><br>Another tool can help developers to pack. Since I did a new plugin I can<br>
select the folder, fill a form with the meta-data and the tool will create<br>the package automatically.<br><br>That's it. Sorry if I wrote too much.<br><br>cheers<br><br>f schiavoni<br><br><br>_______________________________________________<br>
<a href="mailto:Pd-list@iem.at" target="_blank">Pd-list@iem.at</a> mailing list<br>UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
</div></div></div><br>_______________________________________________<br>
<a href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
<br></blockquote></div><br></div>