I'm not used with TCL Tk but my guess it that it should be enough. In linux wget + tar + shell script can solve it. I don't know how portable is a solution like this.
The PHP + SQL was just a suggestion of a tool to update the repository. Nothing about PD. About the dependencies, if the external uses only the ANSI C API, it will not be a problem. It is more confuse if it uses some special lib that should be installed with the external. As I would not like to install automatically a new library in my machine, I think the plugin descriptor can has a field called instruction where the author can specify how to install the dependencies. And that's it. cheers f schiavoni > 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? > > > > > > > -------- Message d'origine -------- > De : [email protected] > Date : 03/02/2013 20:22 (GMT+00:00) > A : [email protected] > Objet : [PD] Plugin auto install feature to Pure data > > Hi list > > I would like to write before but unfortunately I couldn't. Some weeks ago > people started to talk about the development of some auto install > mechanism to Pure Data, like the apt-get. It is an amazing idea. I > researched and developed some thing like it to my master degree and I > would like to contrib with my 3 cents. > > I studied the plugin structure of Netbeans, Eclipse, Fire Fox, deb and rpm > and my contribution is about it. Sorry if I am a little bit prolix. > > The first thing is to create a plugin package. A a single file to group a > lot of files. It can be a zip package, tar, gzip or anything that already > has some C open source API to pack / unpack. This way we can upload / > download a single file and extract it localy. I will call it the package. > > Inside the package is necessary to have a package descriptor. It can be a > XML file, CSV, txt, JSON or any kind of structured file to describe the > content of the package. This file should have the information about the > plugin like the author, version, website, license, OS, dependencies, > compatibility with PD "flavors" (vanilla, extended, Lork ....), > pre-installation script, post-installation script, uninstall script, key > words, ... > > Pre and post installation script are used to create SQL tables, files or > other things. Maybe it is not useful in PD. Uninstall script should clean > the mess if you want to remove a plugin. Dependencies is a complex problem > because it should care about libraries and circular dependencies. Maybe it > is the hardest problem to solve. > > These two things will define the PD plugin: The package file and the > plugin descriptor inside the package. The package structure should be > defined as a standard. So we should agree, for example, about the name of > the descriptor, the folder where the plugin will be and the name of the > package file. Probably a package file can be the name of the > external.version.something.pd_pkg. > > In PD we should have a list of installed plugins. It can be a directory > with all the plugin descriptors. The user might be able to install new > plugins manually. It means a local file in my machine that I choose. PD > will open the package, copy the content to the correct folders and copy > the descriptor the the correct folder. The uninstall option will do the > oposite, delete the plugin descriptor and delete the plugin files. > > To update from the web, a plugin repository need to be defined. The client > should have a list of repositories address. (It is good because different > flavors can have their own plugin repositories and the users can choose > which one they want to use.) > > The plugin server can be implemented with a HTTP server. It will publish > the list of available plugins on the server. This list can be the list of > package descriptors in a tar / zip file. Locally, PD will keep these > lists, one for each server, and it will be used to look for new plugins. > Add a new server means add the server to the repositories list and > download the plugin list of the new server. > > Since PD has a list of local installed plugins, if you want to check for > updates PD compares the servers plugin lists with your local list. Easy > task. Different versions should can be shown and the user would be able to > choose what to update. These descriptors can be useful also to search for > plugins by author, version, key words, versions, ... > > Update a plugin means to create a list of update, download the packages to > a temp directory and install them locally. > > Just to step foward, the server can have a web interface with some PHP > programming, for instance, that automatically update a package, extract > the descriptor, put it in the correct folder and put the plugins in the > correct folder. Just to be easier to maintenance. > > Another tool can help developers to pack. Since I did a new plugin I can > select the folder, fill a form with the meta-data and the tool will create > the package automatically. > > That's it. Sorry if I wrote too much. > > cheers > > f schiavoni > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
