[PD] Preferred/best practice for loading external objects

[Winfried Ritsch]

To sumarize the discussion about deken path:

I mostly agree IOhannes and Miller: 
- no writing without asking, avoid hidden operations to the file system 
- pd should be sensible to standard system and user paths
- deken uses Pd conventions without adding something

Since modern linux desktops respect the "Standard Linux 
system path" recommendations [1],
( like it or not it is the way to go if we want Pd to be accepted in standard 
linux desktops and not patched by packagers for the distributions )

we should add the default user path to Pd: "~/.local/lib/pd/extra"
(see patch attached) and leave for backward compatibility the "~/pd-
externals" path. Since new path is preferred we place it before the old one.
(simple patch attached.)


Argumentation
-----------------------

Preassumption: I want to control and know the behaviour, versions and places 
where Pd stuff is stored, know which objects is part of a what library.
I  also prefer (for education) that users know what they are doing on their 
systems and don't have to make a forensic research what happened after a 
automatic install.

Analyzing my use cases, I look at external libraries in two different ways:

 (1) externals which I trust and always use as a base (here at IEM the 
iemlibs, zexy, acre, ...)

 (2) externals I need for a special kind of problem like communication, 
sensors, ...  (eg. iemambi, iem_bin_ambi, comport, ...)

and decide two main use cases when working with Pd:

 (A) prototype with pd and explore something...

 (B) make an project which should work until eternity and is easily error-free 
reproducible on different systems for concerts, installations and 
distributions.

So starting Pd I want my trusted libraries (1) in my standard path and
I do not want any other libraries loaded or found without [declare]s.

The extra libraries (2) I want to add 

use case (A) to a temporary project folder somewhere 

use case (B)  to a directory in my project folder. I moslty use "libs/" with a 
script in libs for (down)loading externals from somewhere, so these will not 
be content of  my project repository)


To accomplish this with "deken", I only load the 1) libraries to my home 
standard path, where pd find it without extra "declare -path" or install them 
as system package. (in debian).

All other externals I load with deken plugin to my project (being asked where 
to store it) and adding an "declare -path libs/" or so in my main patch.

Since there are two naming conventions for external container:  ".../pd-
externals/" and ".../pd/extra/" it would prefer the second for relative path 
since maybe there will be added some other stuff like in pd/doc ... and then 
there is only one "pd" directory in the path.

The next story would be where to store the config/setting files od deken and Pd, 
but this is another thread.

mfg
 winfried ritsch

PS:
ad a) A deken-download script outside Pd would be great to automate filling the 
libs from deken-sources without using deken dialog.

[1] https://specifications.freedesktop.org/basedir-spec/latest/Standard



Am Mittwoch, 4. Mai 2016, 23:01:58 schrieb IOhannes m zmölnig:
> On 05/04/2016 03:27 PM, Winfried Ritsch wrote:
> > a) Deken should not take just pathes from pd but try preferred ones and
> > add
> > pathes to pd on startup
> 
> i strongly oppose.
> it's Pd's job to use sensible default search paths, and deken should
> follow the lead.
> put otherwise: there should only be a single central place where the
> default search paths are defined, and this ought to be within Pd-core
> (since deken is just a GUI addon, that won't unfold it's power if there
> was no gui)
> 
> > b) Pd suggest as first writeable pathes among others non user-writeable:
> >   /var/lib/pd        (group puredata set)
> >   /usr/local/share/pd,  (group puredata set)
> 
> i don't think that either of those places is the correct place.
> - /var is for "variable files—files whose content is expected to
> continually change during normal operation of the system—such as logs,
> spool files, and temporary e-mail files." - this is definitely *not*
> addon libraries.
> 
> - /usr/local/share or /usr/share is for "architecture-independent
> (shared) data." and most Pd-libraries (installed via deken or otherwise)
> are architecture dependent binaries.
> 
> >   $(HOME)/.local/lib/pd
> >   $(HOME)/pd-external
> > 
> > and deken decides: if the parent dir is writeable it create it and uses
> > it.
> 
> deken did this in the past. it ended up creating ${HOME}/pd-externals
> (which we all hate), because ${HOME} is the only place of all your
> proposals that is (almost always) guaranteed to exist *and* writable by
> the user.
> 
> so now deken does something similar:
> if the directory itself exists and is writeable, it uses it. else it
> asks the user.
> 
> > so if no ./local it would not take it, but the next suggestion and if in
> > the puredata group which can write to /var/lib/pd take this or
> 
> well, you can already do this:
> - create a group "puredata"
> - add yourself to the "puredata" group
> - create "/usr/local/lib/pd-externals/"
> - make "/usr/local/lib/pd-externals/" writable by the "puredata" group
> - use deken
> 
> apart from the last bit, nothing is related to Pd; i therefore think
> that it is *not* Pd's task to do anything of it (*maybe* this can be
> added to a puredata.deb or .rpm)
> 
> > c) deken at least ask where to write it
> 
> which is what it does.
> 
> 
> gasmr
> IOhannes

-- 
--
- ao.Univ.Prof. DI Winfried Ritsch 
- ritsch at iem.at - http://iem.at/ritsch
- Institut of Elektronic Music and Acoustics
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171 
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-added-.local-pd-extra-to-linux-default-search-path.patch
Type: text/x-patch
Size: 940 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160508/25205561/attachment.bin>