Re: [PD] Plugin auto install feature to Pure data
This stuff is already pretty well defined in the library template and the *-meta.pd file. I think the meta file would be the place to add things like dependencies also. http://puredata.info/docs/developer/Libdir http://puredata.info/docs/developer/LibraryTemplate .hc On 02/05/2013 04:11 PM, f...@rendera.com.br wrote: I agree that depencencies should not install libs. Since it seems to be the biggest problem, maybe it should be postponed. Yes, the repository maintenance can be solved latter too. Let's first have a repository and then think about the best way to keep it on date. :-) I don't have skills with TCL but I agree that it is a good choice. Is there how to open zip/tar/something files in TCL? If it can open the package, it's perfect. IMO, the first step is to install locally. Define a package structure, a package header and the install script. Probably it can be used by the remote install. I suggest the following package structure: /content.txt /bin/files -to compiled files (architecture dependent) /help/files -to help files (architecture independent) /tcl/files -to gui files (architecture independent) This structure should be compacted / grouped in a file with some name convention like package_name.version.pd_pkg. The content.txt can be as follow: name: author: version: key-words: web-site: license: flavor: dependencies: instructions: The install script should select a package, open it, copy the external to the external dir, copy the help and tcl files to the correct folder, rename the content.txt to the package name + version and copy it to an folder designed for this kind of file. Cheers f schiavoni ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Plugin auto install feature to Pure data
Thanks Hans! Just one doubt: How does it work for different architectures? Should we pack windows, linux and Mac in different packages? Or can we include them in one package and the installer copies just the right one? cheers f schiavoni This stuff is already pretty well defined in the library template and the *-meta.pd file. I think the meta file would be the place to add things like dependencies also. http://puredata.info/docs/developer/Libdir http://puredata.info/docs/developer/LibraryTemplate .hc On 02/05/2013 04:11 PM, f...@rendera.com.br wrote: I agree that depencencies should not install libs. Since it seems to be the biggest problem, maybe it should be postponed. Yes, the repository maintenance can be solved latter too. Let's first have a repository and then think about the best way to keep it on date. :-) I don't have skills with TCL but I agree that it is a good choice. Is there how to open zip/tar/something files in TCL? If it can open the package, it's perfect. IMO, the first step is to install locally. Define a package structure, a package header and the install script. Probably it can be used by the remote install. I suggest the following package structure: /content.txt /bin/files -to compiled files (architecture dependent) /help/files -to help files (architecture independent) /tcl/files -to gui files (architecture independent) This structure should be compacted / grouped in a file with some name convention like package_name.version.pd_pkg. The content.txt can be as follow: name: author: version: key-words: web-site: license: flavor: dependencies: instructions: The install script should select a package, open it, copy the external to the external dir, copy the help and tcl files to the correct folder, rename the content.txt to the package name + version and copy it to an folder designed for this kind of file. Cheers f schiavoni ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Plugin auto install feature to Pure data
I agree that depencencies should not install libs. Since it seems to be the biggest problem, maybe it should be postponed. Yes, the repository maintenance can be solved latter too. Let's first have a repository and then think about the best way to keep it on date. :-) I don't have skills with TCL but I agree that it is a good choice. Is there how to open zip/tar/something files in TCL? If it can open the package, it's perfect. IMO, the first step is to install locally. Define a package structure, a package header and the install script. Probably it can be used by the remote install. I suggest the following package structure: /content.txt /bin/files -to compiled files (architecture dependent) /help/files -to help files (architecture independent) /tcl/files -to gui files (architecture independent) This structure should be compacted / grouped in a file with some name convention like package_name.version.pd_pkg. The content.txt can be as follow: name: author: version: key-words: web-site: license: flavor: dependencies: instructions: The install script should select a package, open it, copy the external to the external dir, copy the help and tcl files to the correct folder, rename the content.txt to the package name + version and copy it to an folder designed for this kind of file. Cheers f schiavoni ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Plugin auto install feature to Pure data
Here is the tcl module for untar http://tcllib.sourceforge.net/doc/tar.html Message d'origine De : f...@rendera.com.br Date : 05/02/2013 21:11 (GMT+00:00) A : pd-list@iem.at Objet : Re: [PD] Plugin auto install feature to Pure data I agree that depencencies should not install libs. Since it seems to be the biggest problem, maybe it should be postponed. Yes, the repository maintenance can be solved latter too. Let's first have a repository and then think about the best way to keep it on date. :-) I don't have skills with TCL but I agree that it is a good choice. Is there how to open zip/tar/something files in TCL? If it can open the package, it's perfect. IMO, the first step is to install locally. Define a package structure, a package header and the install script. Probably it can be used by the remote install. I suggest the following package structure: /content.txt /bin/files -to compiled files (architecture dependent) /help/files -to help files (architecture independent) /tcl/files -to gui files (architecture independent) This structure should be compacted / grouped in a file with some name convention like package_name.version.pd_pkg. The content.txt can be as follow: name: author: version: key-words: web-site: license: flavor: dependencies: instructions: The install script should select a package, open it, copy the external to the external dir, copy the help and tcl files to the correct folder, rename the content.txt to the package name + version and copy it to an folder designed for this kind of file. Cheers f schiavoni ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Plugin auto install feature to Pure data
The tclVFS zip option sounds very nice: http://wiki.tcl.tk/12832 It basically makes a .zip file a virtual file system. .hc On 02/05/2013 06:37 PM, colet.patrice wrote: Here is the tcl module for untar http://tcllib.sourceforge.net/doc/tar.html Message d'origine De : f...@rendera.com.br Date : 05/02/2013 21:11 (GMT+00:00) A : pd-list@iem.at Objet : Re: [PD] Plugin auto install feature to Pure data I agree that depencencies should not install libs. Since it seems to be the biggest problem, maybe it should be postponed. Yes, the repository maintenance can be solved latter too. Let's first have a repository and then think about the best way to keep it on date. :-) I don't have skills with TCL but I agree that it is a good choice. Is there how to open zip/tar/something files in TCL? If it can open the package, it's perfect. IMO, the first step is to install locally. Define a package structure, a package header and the install script. Probably it can be used by the remote install. I suggest the following package structure: /content.txt /bin/files -to compiled files (architecture dependent) /help/files -to help files (architecture independent) /tcl/files -to gui files (architecture independent) This structure should be compacted / grouped in a file with some name convention like package_name.version.pd_pkg. The content.txt can be as follow: name: author: version: key-words: web-site: license: flavor: dependencies: instructions: The install script should select a package, open it, copy the external to the external dir, copy the help and tcl files to the correct folder, rename the content.txt to the package name + version and copy it to an folder designed for this kind of file. Cheers f schiavoni ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
