[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