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