Oups sorry: "I'm not familiar enough with other linux flavours to know this but certainly on debian I have no other ~/.folders on my system, even though the non-hidden path already exists via the apt install (and there's a ton of other programs' 'stuff' in /usr/lib/)." is obviously incorrect, I was thinking it takes me to my /home folder not /home/julian where yes there are lots of hidden folders.
Apologies (lost in my little rant). Otherwise the rest stands... On 7 April 2017 at 11:08, Julian Brooks <jbee...@gmail.com> wrote: > Hi Roman, > > Yeah, I'd spotted the > ~/.local/lib/pd/extra > as being canonical from an earlier thread but as 1. I didn't already have > that folder 2. historically (dangerous I know) the non-hidden path had > always been 'the place' for externals, so I just blithely carried on > regardless - ouch(blush). > > All below meant with the utmost respect for the work currently being > done... > > Doesn't this just cause more issues? While I can conceptualise the > reasoning for differing usr/lib/puredata (vanilla install) and usr/lib/pd > folders - it is another added layer of confusion for newbs (not meant as a > pejorative). > Obfuscating externals in hidden folders seems unnecessary (and yes, I'm > aware I brought 'canonical' into it /.worms/can of/argh). > > I'm not familiar enough with other linux flavours to know this but > certainly on debian I have no other ~/.folders on my system, even though > the non-hidden path already exists via the apt install (and there's a ton > of other programs' 'stuff' in /usr/lib/). > So for me I'd vote for consistency, not one folder with externals via apt > and another via deken (as well as the vanilla 'extra') - it's too confusing. > > Of course I'm not necessarily saying that there should only be a 'one > approach fits all' for all linux flavours (that's not how we roll) but then > again it might save lots of people lots of headaches if it was simple, > doable and clear across the board (I'm not including Win and Mac here > obviously - they've got their own issues). Well, actually having reread > that line _-_ ok, I guess that is what I'm saying then - "one method to > rule them all". > Certainly for writing documentation this would make things so much easier. > > Brilliant that deken can sort all this very soon but for those of us stuck > in an eternal 'now' we could do with a solution, or at least a consistent > conceptual approach:) > > Andy - mooooooove along please (and yes, I've just added it to my .bashrc:D > > Regards, > > Julian > > On 7 April 2017 at 10:03, Roman Haefeli <reduz...@gmail.com> wrote: > >> On Don, 2017-04-06 at 21:12 +0100, Julian Brooks wrote: >> > >> > >> > Now of course I can just dl whatever lib via deken, save it somewhere >> > within where I do have permissions and cp it to the right place but >> > I'm lazy at heart - plus for 'how-to's this is a more complex >> > description - how are others doing it? >> >> On Linux, the "correct" path (a.k.a the user specific search path) is >> ~/.local/lib/pd/extra. Just use Deken to download there directly. If >> the folder already exists, Deken will suggest it as the first option. >> There is no need to copy things around. >> >> NOTE: You still have to create that directory manually. However, >> upcoming versions of Pd will include a Deken that automatically creates >> that folder if you chose so. >> >> Roman >> _______________________________________________ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li >> stinfo/pd-list >> >> >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
