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

Reply via email to