[PD-dev] svn:externals, pd-extended, SVN and the goal of it all

[mescalinum at gmail.com]

Hans-Christoph Steiner wrote:
> On Jun 21, 2008, at 1:26 PM, Frank Barknecht wrote:
>
>   
>> Hallo,
>> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
>>
>>     
>>> I think then there could be a simple distro system like Eclipse has
>>> for managing plugins. (Basically, there is a simple format for
>>> posting a library to a website.  The user then adds the repo URL to
>>> the program, which then has a browser for all available installation
>>> options and updates).
>>>       
>> Recently another metaphor came to my mind - and of course it has to be
>> taken with a grain of salt like all metaphors: Mozilla vs.
>> Firefox/Thunderbird/Sundbird, ...
>>
>> pd-extended to me very much feels like Mozilla in that it tries to
>> provide as much "apps" as possible crammed into a single-click
>> installable suite. Compare that to Firefox, which is only a very basic
>> browser with functionality stripped down so much, that the first thing
>> everyone does is install some extenstions. Nevertheless Firefox took
>> off in a big way and Mozilla is more or less dead.
>>
>> I think, this had two reasons. First reason: People who liked the
>> browser in Mozilla didn't care about the mail component at that time.
>> They used Mutt, Outlook, or whatever.  (Funnily now that it's a
>> separate app, Thunderbird became popular as well.) The second reason
>> is the extensions and theme system of Firefox which made it very easy
>> to install only the updates, that a user is interested in, without all
>> the bloat of Mozilla.
>>
>> I don't know if something can be learned from that history, though.
>>     
>
> I think it is a good example.  Mozilla needed to happen in order to  
> make Firefox, Thunderbird, etc. happen.  But it then worked better to  
> split them up.  I think Pd-extended is a similar kind of thing.   
> Gathering all known code at the time into one place need to happen to  
> get the community to the next step.  Now we are outgrowing that  
> model, so I think it is time to split things up so that externals are  
> as well supported as internals.
>
> Then there is much less need for a 'gatekeeper', who has control over  
> what is included (e.g. like Miller for vanilla, or me, mostly, for Pd- 
> extended).  If we make it easy to find, download, and manage  
> externals, then we don't need a big central package.  Something like  
> CPAN is a great example, or the Eclipse plugins.
>   
is this a proposal for a "package system"?

well, it would be a step forward just if only all extern will work 
./configure && make && make install out-of-the box.

what I see lacking in the external repository is some kind of standard.
most externals build with just a makefile, some others use automake, 
autoconf, others use the flext build system.

another problem is the install location: since the addition of 
namespaces/declare/import, things are changed.
also, the standards are very low (I again advice to read the GNU coding 
standards book)

also, the install location of docs, it is a flat (bloated) directory (?)

also, externals/packages, lack versioning (I think).
do we have the possibility to put metadata?


I'm not proposing a valuable solution, just spotting one problem.

I hardly see a user-friendly, plug-n-play system for extensions right 
now; tidying up things is required.

What if every external installs into his own prefix in ${ROOT}/usr/lib/pd ?
example:
/usr/lib/pd/zexy/lib/a2l.pd_linux
/usr/lib/pd/zexy/lib/abs~.pd_linux
...
/usr/lib/pd/zexy/doc/help-a2l.pd
/usr/lib/pd/zexy/doc/help-abs~.pd
...
/usr/lib/pd/zexy/package.xml ?metadata?


at this point the /pd/ is superfluous.
the Tcl package system works by putting directories directly into 
/usr/lib, example:

/usr/lib/tktray1.1/
/usr/lib/tktray1.1/pkgIndex.tcl
/usr/lib/tktray1.1/libtktray1.1.so

not bad, IMHO.

my 0.02€
-- 
Federico Ferri