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
- [email protected] - 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
-->From fee5072fb8dc45fb7ca511016efcd7d4d76e12c3 Mon Sep 17 00:00:00 2001
From: ritsch <[email protected]>
Date: Sat, 7 May 2016 23:59:00 +0200
Subject: [PATCH] added ~/.local/pd/extra to linux default search path
---
src/s_path.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/s_path.c b/src/s_path.c
index 0127fac..a74a84c 100644
--- a/src/s_path.c
+++ b/src/s_path.c
@@ -243,8 +243,9 @@ void sys_setextrapath(const char *p)
namelist_free(sys_staticpath);
/* add standard place for users to install stuff first */
#ifdef __gnu_linux__
- sys_expandpath("~/pd-externals", pathbuf, MAXPDSTRING);
+ sys_expandpath("~/.local/lib/pd/extra", pathbuf, MAXPDSTRING);
sys_staticpath = namelist_append(0, pathbuf, 0);
+ sys_staticpath = namelist_append(sys_staticpath, "~/pd-externals", 0);
sys_staticpath = namelist_append(sys_staticpath, "/usr/local/lib/pd-externals", 0);
#endif
--
2.8.1
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
