[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