[PD-dev] CPAN-like distribution concepts.. (was deb packages discussion)

dmotd inaudible at simplesuperlativ.es
Wed Sep 23 11:20:17 CEST 2009


IOhannes m zmoelnig wrote:
> Hans-Christoph Steiner wrote:
>
>>> i agree (and honestly i don't think a CPAN-like system will happen  
>>> anytime soon).
>>
>>
>> It will happen as soon as someone does it.  :D  I don't think anyone  
>> objects to the idea, right?
>
> well, like always - i do :-)
>
> i agree with dmotd, that such a thing has to be thought through _very_  
> carefully. it's easy to hack together something dirty.
> e.g. cygwins package management system is just something i would never  
> ever like to encounter again.
>
> but honestly: personally as a debian user (being nurtured with apt) i am  
> not a great friend of all these concurrent packaging systems; e.g.  
> python-eggs/buildouts do cause me a lot of headache, because they don't  
> integrate into apt (or any other concurrent package-manager, i guess) at  
> all. i don't want to get Pd into the same hell....

ya, there's no doubt in my mind that most of these 
CPAN style systems make existing packaging and 
general client maintenance an absolute nightmare, 
while at the server end help turn source 
repositories into dense catacombs, with deserted 
code being left under miles of unmaintained 
dependencies. and even if it is done well it risks 
becoming over-designed and difficult to manouvre, 
losing the flexibility that is supposed to be a 
gain.

but all this said there's something very 
attractive in the idea, which i think relates well 
to the pd environment. and there appears to be a 
growing demand for distribution of end-user 
targeted applications.

pd seems to have outgrown its initial reputation 
as a toy for artist/programmers tinkering and 
experimenting with sound and other media, and is 
getting more widespread use in rich and featureful 
applications - from dsp fx manipulators and vj 
applications to full fledged studio tools and 
artist installations (not to forget the rjdj 
project which obviously has distribution built 
into its concept). in many ways pure data forum~ 
superceded pd-announce list a while ago as a space 
for releasing pd based work.

as far as i know there is nothing publicly 
available that can quickly tell you the 
dependencies of a given pd patch, in terms of what 
libraries / objects / abstractions are missing (i 
do have a shell script that does something similar 
if anyone wants it). sure, simply loading the 
patch will shout a long list of errors, but it can 
be a little intimidating to anyone simply trying 
to get a pd-app to run without much background 
knowledge of the environment.

so perhaps its not too big a leap in the wrong 
direction to begin considering a distribution hub 
for pd based projects. it wouldn't have to build 
code initially, it could simply create a 
dependency tree, download any required 
abstractions and install them into its own jail 
and list any depencies that can't be met through 
the client/server alone. in this sense it wouldn't 
even need to be a shell script to begin with and 
could be contained in a web framework that 
assembles the elements into a tarball ready for 
convenient download. thus allowing the system to 
mature in a slow and contained way, rather than a 
quick and dirty shell based external mangler.

in a sense a project of this nature would be in 
some ways a natural meating point for existing 
projects like pdpedia, netpd and puredata forum~.

so i guess i'm cautiously welcome to the idea of 
adopting some distribution/packaging approaches, 
but there needs to be a lot more talk first.

---
dmotd




More information about the Pd-dev mailing list