OK... so what I hope I just did is to make Pd search in this order:
~/.local/lib/pd/extra/ ~/pd-externals /usr/local/lib/pd-externals
... in that order. We can consider ~/pd-externals to be obsolete.
cheers Miller
On Mon, May 09, 2016 at 03:01:33PM +0200, Winfried Ritsch wrote:
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
--
- ao.Univ.Prof. DI Winfried Ritsch
- ritsch@iem.at - http://iem.at/ritsch
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171
--
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list