[PD] Preferred/best practice for loading external objects
Winfried Ritsch
ritsch at iem.at
Sun May 8 11:00:08 CEST 2016
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>
More information about the Pd-list
mailing list