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

Thu Feb 7 05:13:04 CET 2013

Try writing something in a language you are familiar with.  Anything working
is better than nothing :)

Tcl is a bit odd, but its pretty easy for almost all of what this project
would require.

.hc

On 02/05/2013 11:08 PM, Billy Stiltner wrote:
> sounds right up my alley but i have not a clue about how to write a
> line of code in tcl , python nor lua.
> i was trying to convert the big bunch of wafscript to just a simpl
> makefile  for compiling pugl today and by the time i could get
> to the end of the spaghetti i realized i don't even remember how to
> write a make file haha. but i'm still chuggin  away at it.
> 
> 
> 
> 
> On Tue, Feb 5, 2013 at 1:33 PM, Hans-Christoph Steiner <hans at at.or.at> wrote:
>>
>> I think really the key is to find someone who is going to start working on
>> this, then help them figure out the issues as they request it.  I think its
>> counterproductive if we set up too many conditions of starting if none of us
>> are going to work on it :-)  Then they can decide Tcl or something else,
>> client or server first, or whatever else.
>>
>> Who wants to try the first sketch?  We have a package format to start with,
>> its something, but it'll surely need to be changed to support all the ideas:
>> http://puredata.info/docs/developer/LibraryTemplate
>>
>>
>> .hc
>>
>> On 02/05/2013 12:48 PM, colet.patrice wrote:
>>> I dont think the client is the first thing to head on, because I guess it will depend on server architecture. Anyway tcl seems to most suited for that, there would no need to add some more junk into pd bin folder...
>>>
>>>
>>>
>>>
>>> Envoyé depuis mon appareil mobile Samsung
>>>
>>> -------- Message d'origine --------
>>> De : Hans-Christoph Steiner <hans at at.or.at>
>>> Date : 05/02/2013  16:20  (GMT+00:00)
>>> A : pd-list at iem.at
>>> Objet : [PD] package system for Pd WAS: Plugin auto install feature to Pure
>>>       data
>>>
>>>
>>> While I agree with all this, we don't need a full design spec to start coding.
>>> I think the next step is for someone to put together a rough prototype to
>>> start with, rather than get bogged down in the details of something that has
>>> been talked about for years, but never implemented :-)
>>>
>>> Then it can be implemented bit by bit as people have time and interest.  So
>>> the first question to ask before starting it:  which language?  Is Tcl
>>> workable for people?
>>>
>>> .hc
>>>
>>> On 02/05/2013 10:36 AM, Charles Z Henry wrote:
>>>> 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
>>>>
>>>> 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?
>>>> 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.
>>>> 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.
>>>>
>>>> I would start out like this.... make a list and argue point-by-point until
>>>> you have a clear plan.
>>>> Not that I'm much one to *complete* my projects... but I have a lot of
>>>> insight on failing :)
>>>>
>>>>
>>>> On Mon, Feb 4, 2013 at 3:10 AM, colet.patrice <colet.patrice at free.fr> wrote:
>>>>
>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list