[PD] Deken install path & permissions on Debian

[Alexandre Torres Porres]

> Brilliant that deken can sort all this very soon

maybe for linux? how is it? you cant write externals in the application
specific folder so it'll offer that one and write it?

since you can write externals in the application specific folder in mac, it
won't offer it, and maybe that could happen in some linux distribution/set
up?

things would really be sorted if the folders were just created once and for
all...

cheers

2017-04-07 7:08 GMT-03:00 Julian Brooks <jbeezez at gmail.com>:

> 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 <reduzent at 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 at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>> stinfo/pd-list
>>
>>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170407/d8a6c47b/attachment-0001.html>