I also propose using for linux systems the standard $(HOME)/.local directory.
the only minor questions for me would be (in preferred order):
(a) ~/.local/lib/pd/extra/ (b) ~/.local/lib/pd-external/ (c) ~/.local/lib/pd/<version>/extra/
The idea of the standard path "~/.local" is, that it will be as common and well known as /usr/local is now for system-wide non distribution software. So everyone dealing with linux desktop should find it. Anyhow, path will be shown/hinted during deken install process.
(a) +: one can copy all of .local/pd stuff to another user account if needed and don't need to install all stuff again (until I get an error) because the pd version was altered.
(b) was used like IOhannes explained on /usr/local/ to distinguish between /usr/local/bin/pd and some other instance of pd like /usr/bin/pd.
But in my opinion if had to use different versions of pd parallel, I do it out my project directory, (if there is really a need for this) and not using /usr/local or any other common place to distinguish them.
(c) like explained in a do not want to install it again when pd version alters. so I dislike this path since externals versions are mostly not in sync with PD-versions.
Summarizing:
So we have for pd externals, libraries and addons:
~/.local/lib/pd/extra - for user wide pd stuff ~/pd-external - deprecated old user wide pd stuff
/usr/local/lib/pd-externals - for manual systemwide installs of pd externals
/usr/local/lib/pd/extra/ - for manual systemwide installs only
exclusive for /usr/local/bin/pd installation
/usr/lib/pd/extra/ - for packaged "third party" = not vanilla pd stuff
(/usr/lib/puredata/extra - for pd vanilla pd packaged stuff)
Anyhow for backwards compatibility we should leave old paths, just don't enforce them and order the preferred first.
Personally vote for (a)
mfG Winfried
PS:For config file i start an own discussion ( now it is ~/.pdsettings and should move to .config/pd/settings.conf)
Am Montag, 9. Mai 2016, 10:27:32 schrieb IOhannes m zmoelnig:
On 2016-05-09 03:32, Chris McCormick wrote:
Hi,
On 08/05/16 11:12, Miller Puckette wrote:
Me, when I shout a thte computer, it's more likely to be "where the *&$^%& did you put the file I just downloaded?" or "why the $%*& did you just do that" as opposed to "why did you just ask me to confirm this operation that will put files on my disk". But I know my own tastes aren't shared by all users...
While we are shouting, it seems people (including you) are annoyed about "~/pd-externals" all up in their home directory. I wonder if it would make sense to deprecate that in favour of standard config paths on all platforms?
Blender does this well already and follows existing desktop standards. I think it would be a good model to copy:
Linux = $HOME/.config/blender/2.77/
Mac OSX = /Users/$USER/Library/Application Support/Blender/2.77/
MS-Windows = C:\Documents and Settings$USERNAME\AppData\Roaming\Blender Foundation\Blender\2.77\
i was always under the impression that the W32 and OSX search paths were pretty OK, so i'm not sure whether action is needed on that side (but of course i am on linux mostly)
i guess this impression mainly comes from the question of how easy it is to hide/ignore that folder, even if I did install something to it. e.g. on w32, the "%AppData%" path is there already in most cases, and it is in a place that i (as the user) don't usually open, so it doesn't get in my way.
so the main problem is on linux, where "pd-externals" show up in my *home* directory, a place that everybody finds themselves looking at all the time.
so i'm all for moving to ~/.local/lib/pd/extra/ (and/or ~/.local/lib/pd/0.47-3/extra/ if somebody thinks this is useful)
the relevant specs can be found at [1]
gfdmasr IOhannes
PS: i don't think that ~/.config/ is the right place to put externals to, regardless of what blender does (again, see [1])
[1] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html