[PD] Preferred/best practice for loading external objects

Chris McCormick 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
 >> ~/pd/extra.
 >> 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 
to "~/pd-externals").

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)
  * /path/to/currently/selected/patch/directory

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 
about that!




More information about the Pd-list mailing list