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

Hans-Christoph Steiner hans at eds.org
Sun Jun 22 14:28:58 CEST 2008


On Jun 21, 2008, at 7:44 PM, mescalinum at gmail.com wrote:

> 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


The idea is to use a common library (or 'package') format that  
includes binaries, abstractions, help files, examples, manuals, etc.  
in one folder.  This is the basic idea of 'libdirs'.  http:// 
puredata.info/docs/developer/Libdir

How people build them depends on their project.

.hc



------------------------------------------------------------------------ 
----

                             kill your television






More information about the Pd-dev mailing list