[PD] Preferred/best practice for loading external objects
chris at mccormick.cx
Mon May 9 03:25:59 CEST 2016
> On Thu, May 05, 2016 at 08:32:46PM +0200, IOhannes m zmölnig wrote:
>> On 05/04/2016 11:53 PM, Miller Puckette wrote:
>>> I believe it should be just the one. But I'm a scope conservative
>>> (despite the contradictory evidence that Pd has, in fact, no scoping
>>> mechanism :)
>> hmm, so:
>> for your people at UCSD you would like to have externals installed into
>> ~/pd/extra and ~/pd-0.46-4/extra and ~/pd-0.22/extra depending on which
>> version of Pd you are running.
>> for yourself, you would like to have externals NOT be installed into
>> since these two behaviours are contradictory and cannot be resolved
>> automatically, the only option is to ask the user every single time they
>> are going to install a library via deken, at the potential cost ofthem
>> shouting "but i told you this directory already three times this
>> morning" at their computers.
On 08/05/16 11:12, Miller Puckette wrote:
> Well, another way migth be to have Pd only query the first time in a Pd
> session and then proceed automatically.
Speaking as a fellow "scope conservative" I know that it is possible to
cater for all of the above cases where a user might want a different
install and loading paths for externals, because it has already been
solved by other scripting languages such as Python.
Consider the following selection of different install-path use cases:
1. User has root and wants to install an external to some location,
available to all instances of Pd on the system (system administrator).
2. User does not have (or want to use) root, uses [one of several]
pre-built binaries of Pd in their homedir and they want to install
different externals for the exclusive use of each one.
3. User does not have (or want to use) root, uses system Pd or other Pds
and wants to install externals available to all.
4. User wants to install an external for use by a single patch only so
they can zip up that patch with all it's dependencies and send it to a
gallery for deployment on an identical architecture machine. They don't
want the external polluting all copies of Pd.
In Python for example, you would use a virtualenv (or nodeenv in node)
for the local case (4) and different flags to pip/easy_install for cases
In Pd, I don't think it's hard to come up with a UI that satisfies all
of these possibilities, with a sensible default setting (such as saving
Imagine the current deken interface, but with one extra pull-down with
the label "install to:" and the following selection:
* ~/pd-externals/ (default)
* /path/to/current/pd/extras (if root is required some message is shown)
The second and third options would obviously be dynamic.
It would probably also make sense for the pull-down to default to the
last selected value when changed.
I should have submitted a pull-request instead of this email, sorry
More information about the Pd-list