[PD] package system for Pd WAS: Plugin auto install feature to Pure data

[Hans-Christoph Steiner]

The entire thing could easily be implemented in Tcl.  Indeed I think Tcl is a
good language for it since it is really easy to work with network
communication and strings in Tcl.  For a precedent, MacPorts is a large
package management system written in Tcl.  And currently, Pd always comes with
Tcl, so we know its available on all platforms Pd runs on (except for mayvery
obscure ones like iPodLinux for the first iPods).

A Debian apt repo does not use any dynamic content in it (i.e. web pages
generated by php, python, etc).  The repo files are generated using tools, but
then are completely static and can be served up by any web server.  This is
definitely the better approach for the server.  I can't see anything gained by
making the server dynamic, and it does add complexity and possible security
issues.

As for sharing packages across multiple servers, as long as there is a way to
verify the authenticity and correctness of a package, they can be easily
copied around.  In Debian, this is done with by using sha256/sha1/md5 hashes
for the packages and gpg signatures on the list of hashes.

The real question remains: who is going to work on implementing this?  I can
contribute, but I don't have time to lead this effort.

.hc

On 02/05/2013 05:04 AM, colet.patrice wrote:
> Wget and tar could be replaced with TCL http and tar module at client side, and for server side I'd use PHP and mySQL, or maybe python instead of PHP... One thing I'm wondering is how to share packages between several servers, would all http servers need a build farm?
> 
> -------- Message d'origine --------
> De : fls at rendera.com.br 
> Date : 04/02/2013  17:57  (GMT+00:00) 
> A : pd-list at iem.at,"colet.patrice" <colet.patrice at free.fr> 
> Objet : Re: RE : [PD] Plugin auto install feature to Pure data 
>  
> 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 : fls at rendera.com.br
>> Date : 03/02/2013  20:22  (GMT+00:00)
>> A : pd-list at iem.at
>> 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
>>
>>
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
> 
> 
> 
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>