I think what it boils down to is that the paths in st_staticpath (Pd) are used recursively and the paths in sys_searchpath (user) are not. This means if we have an deken externals download dir, we still have to add *each* external's subdirectories to sys_searchpath since it's not recursive, whereas throwing stuff in ../extra "just works". This would be why adding something like ~/Documents/Pd to st_staticpath is so attractive because it negates needing to add each lib to the user search paths.
Maybe we need an option to add recursive search paths?
On Jul 30, 2017, at 10:00 PM, pd-list-request@lists.iem.at wrote:
From: Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> Subject: Re: [PD] New users and external path struggles Date: July 30, 2017 at 8:56:30 PM GMT+2 To: Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> Cc: pd-list <pd-list@iem.at mailto:pd-list@iem.at>
Except perhaps in this thread I can try to explain... I always meant "standard path" to refer to "stuff distributed with Pd", and "Path" to be adjustible to point to libraries that are not part of the Pd distribution. I think part of the confusion comes from different possible interpretations of "standard path" (which, as I now realize, is badly named). But I think the way forward is to somehow get the "path" mechanism to do what people are asking for.
cheers Miller
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
whereas throwing stuff in ../extra "just works".
what do you mean by that? when I throw 'mylib' folder (containing foo.pd) into ../extra, I either have to add ../extra/mylib to the user paths OR do [declare -stdpath mylib] or always do [mylib/foo]. so ../extra (and other standard paths) are apparently *not* searched recursively when trying to load an object and behave the same as user paths. it's just with [declare] where the difference comes into play.
I'm on Windows 7. Is this different on other systems!?
Gesendet: Sonntag, 30. Juli 2017 um 22:21 Uhr Von: "Dan Wilcox" danomatika@gmail.com An: "Miller Puckette" msp@ucsd.edu Cc: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] New users and external path struggles
I think what it boils down to is that the paths in st_staticpath (Pd) are used recursively and the paths in sys_searchpath (user) are not. This means if we have an deken externals download dir, we still have to add *each* external's subdirectories to sys_searchpath since it's not recursive, whereas throwing stuff in ../extra "just works". This would be why adding something like ~/Documents/Pd to st_staticpath is so attractive because it negates needing to add each lib to the user search paths. Maybe we need an option to add recursive search paths?
On Jul 30, 2017, at 10:00 PM, pd-list-request@lists.iem.at[mailto:pd-list-request@lists.iem.at] wrote:
From: Miller Puckette <msp@ucsd.edu[mailto:msp@ucsd.edu]> Subject: Re: [PD] New users and external path struggles Date: July 30, 2017 at 8:56:30 PM GMT+2 To: Alexandre Torres Porres <porres@gmail.com[mailto:porres@gmail.com]> Cc: pd-list <pd-list@iem.at[mailto:pd-list@iem.at]>
Except perhaps in this thread I can try to explain... I always meant "standard path" to refer to "stuff distributed with Pd", and "Path" to be adjustible to point to libraries that are not part of the Pd distribution. I think part of the confusion comes from different possible interpretations of "standard path" (which, as I now realize, is badly named). But I think the way forward is to somehow get the "path" mechanism to do what people are asking for.
cheers Miller
Dan Wilcox @danomatika[http://twitter.com/danomatika] danomatika.com[http://danomatika.com] robotcowboy.com[http://robotcowboy.com] _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
I guess I mean nothing by than and am completely wrong. I'm thinking of the old extended behavior with libdir finding things automatically. I use *very few* externals at this point, so I shouldn't say anything more I suppose.
On Jul 30, 2017, at 10:38 PM, Christof Ressi christof.ressi@gmx.at wrote:
whereas throwing stuff in ../extra "just works".
what do you mean by that? when I throw 'mylib' folder (containing foo.pd) into ../extra, I either have to add ../extra/mylib to the user paths OR do [declare -stdpath mylib] or always do [mylib/foo]. so ../extra (and other standard paths) are apparently *not* searched recursively when trying to load an object and behave the same as user paths. it's just with [declare] where the difference comes into play.
I'm on Windows 7. Is this different on other systems!?
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
yeah, this worked because of libdir.
Gesendet: Sonntag, 30. Juli 2017 um 22:40 Uhr Von: "Dan Wilcox" danomatika@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Miller Puckette" msp@ucsd.edu, Pd-List pd-list@lists.iem.at Betreff: Re: [PD] New users and external path struggles
I guess I mean nothing by than and am completely wrong. I'm thinking of the old extended behavior with libdir finding things automatically. I use *very few* externals at this point, so I shouldn't say anything more I suppose.
On Jul 30, 2017, at 10:38 PM, Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]> wrote:
whereas throwing stuff in ../extra "just works". what do you mean by that? when I throw 'mylib' folder (containing foo.pd) into ../extra, I either have to add ../extra/mylib to the user paths OR do [declare -stdpath mylib] or always do [mylib/foo]. so ../extra (and other standard paths) are apparently *not* searched recursively when trying to load an object and behave the same as user paths. it's just with [declare] where the difference comes into play.
I'm on Windows 7. Is this different on other systems!?
Dan Wilcox @danomatika[http://twitter.com/danomatika] danomatika.com[http://danomatika.com] robotcowboy.com[http://robotcowboy.com]
yeah, this worked because of libdir.
A few details:
- The Pd extended libdir loader searches for a $LIBNAME-meta.pd file. If
it finds it it adds the directory containing it to the global search path.* namespace prefixes (probably better referred to as directory prefixes) will add the prefixed name to Pd's object creator methodspace. So if you do this:[foo/image][bar/image][/home/foo/decade_old_version/build/bin/image] None will clash with the others. (Of course if you have /home/foo AND /home/bar/foo in your search path then you are right back to depending on path search order...) -Jonathan
None will clash with the others.
that's also true for Pd vanilla!
Gesendet: Sonntag, 30. Juli 2017 um 23:58 Uhr Von: "Jonathan Wilkes" jancsika@yahoo.com An: "Christof Ressi" christof.ressi@gmx.at, "Dan Wilcox" danomatika@gmail.com Cc: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] New users and external path struggles
yeah, this worked because of libdir.
A few details:
- The Pd extended libdir loader searches for a $LIBNAME-meta.pd file. If
it finds it it adds the directory containing it to the global search path.
- namespace prefixes (probably better referred to as directory prefixes) will
add the prefixed name to Pd's object creator methodspace. So if you do this: [foo/image] [bar/image] [/home/foo/decade_old_version/build/bin/image] None will clash with the others. (Of course if you have /home/foo AND /home/bar/foo in your search path then you are right back to depending on path search order...) -Jonathan
2017-07-30 17:38 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
whereas throwing stuff in ../extra "just works".
what do you mean by that? when I throw 'mylib' folder (containing foo.pd) into ../extra, I either have to add ../extra/mylib to the user paths OR do [declare -stdpath mylib] or always do [mylib/foo]. so ../extra (and other standard paths) are apparently *not* searched recursively when trying to load an object and behave the same as user paths. it's just with [declare] where the difference comes into play.
Yeah... We also need to add *each* external's subdirectories in such case, if I get what you mean... Like, if I download "cyclone" to extra and I try [cycle~], it fails. The options are: *A)* put cyclone's subdirectory in the path, or *B)* use [cyclone/cycle~]; *C) *use [declare -stdpath cyclone]. So it doesn't "just works", you gotta do one of these...
This would be why adding something like ~/Documents/Pd to st_staticpath is so attractive because it negates needing to add each lib to the user search paths.
If ~/Documents/Pd was added to st_staticpath, you'd gain the options B) and C), but you'd still have to put ~/Documents/Pd/cyclone in the path, if that's how you roll (and you don't care for B/C). So that's not what changes.
ps. I have that new thread :)
-
Alexandre Torres Porres -
Christof Ressi -
Dan Wilcox -
Jonathan Wilkes