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 _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
