Hi all,
Just to add a little more noise to the ongoing debate...
What's the canonical/most-favoured approach here for Debian (Linux in general I suppose).
I want my externals in usr/lib/pd/extra but installing via Deken I don't have permission to install there - tbh so far, I've just installed via apt-get (thank you IOhannes, the repo's are so blindingly good and the path is sorted) but I'm sure this situation will come up for others (and for me imminently).
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?
Big props to all the devs and contributors for Deken btw, this is so much better than it's ever been before.
Regards,
Julian
On 04/06/2017 10:12 PM, Julian Brooks wrote:
What's the canonical/most-favoured approach here for Debian (Linux in general I suppose).
# apt-get install pd-deken-apt
this will add apt powers to deken (but of course you need supercow powers to use them)
gfasdmr IOhannes
On Thu, Apr 06, 2017 at 11:57:25PM +0200, zmoelnig@iem.at wrote:
(but of course you need supercow powers to use them)
gfasdmr IOhannes
Brighten up a common annoying typo by adding this to your .bashrc
apt-vache() { apt-cache $@ | cowsay; }
$ apt-vache search xclock
/ rxvt - VT102 terminal emulator for the
| X Window System x11-apps - X |
\ applications xarclock - reversed xclock /
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
a.
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
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@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/ listinfo/pd-list
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 jbeezez@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 reduzent@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
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@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@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
Apologies IOhannes, I was a little hasty with my celebrations.
After installing the pd-deken packages I still get this from Pd when attempting to install a lib: "No writeable directory found in: - /home/julian/.local/lib/pd/extra/ - /home/julian/pd-externals - /usr/local/lib/pd-externals - /usr/lib/puredata/extra - /usr/lib/pd/extra Cannot download/install libraries!"
Pd-0.47.1 ("") compiled for Debian (0.47.1-3) Debian Sid (up to date)
Hi Alexandre, well for me the folders already created (/usr/lib/pd/extra) by the Debian Pd install, it's getting the libs in there that's the current issue. But yes, which folder that should definitively be is still also up for debate I guess.
Julian
On 7 April 2017 at 17:13, Alexandre Torres Porres porres@gmail.com wrote:
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@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@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/li stinfo/pd-list
Just for clarification.
I made a /home/julian/.local/lib/pd/extra/ directory, clicked on a lib via deken, dl'd it, and all works lovely (apart from having libs scattered across my computer:)
Julian
On 7 April 2017 at 23:45, Julian Brooks jbeezez@gmail.com wrote:
Apologies IOhannes, I was a little hasty with my celebrations.
After installing the pd-deken packages I still get this from Pd when attempting to install a lib: "No writeable directory found in: - /home/julian/.local/lib/pd/extra/ - /home/julian/pd-externals - /usr/local/lib/pd-externals - /usr/lib/puredata/extra - /usr/lib/pd/extra Cannot download/install libraries!"
Pd-0.47.1 ("") compiled for Debian (0.47.1-3) Debian Sid (up to date)
Hi Alexandre, well for me the folders already created (/usr/lib/pd/extra) by the Debian Pd install, it's getting the libs in there that's the current issue. But yes, which folder that should definitively be is still also up for debate I guess.
Julian
On 7 April 2017 at 17:13, Alexandre Torres Porres porres@gmail.com wrote:
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@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@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/li stinfo/pd-list
On 04/08/2017 12:45 AM, Julian Brooks wrote:
Apologies IOhannes
?
I was a little hasty with my celebrations.
i'm pretty sure you did use the latest and greatest deken as downloadable from [1] rather than the one bundled with Pd, did you?
gfmards IOhannes
'?' I was whooping too quickly previously.
'I'm pretty sure you did use the latest and greatest deken as downloadable from [1] rather than the one bundled with Pd, did you?'
Erm, yes (cough) no.
Ok, will report back
On 10 April 2017 at 22:41, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 04/08/2017 12:45 AM, Julian Brooks wrote:
Apologies IOhannes
?
I was a little hasty with my celebrations.
i'm pretty sure you did use the latest and greatest deken as downloadable from [1] rather than the one bundled with Pd, did you?
gfmards IOhannes
[1] https://github.com/pure-data/deken
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
-
Alexandre Torres Porres -
Andy Farnell -
IOhannes m zmölnig -
Julian Brooks -
Roman Haefeli -
zmoelnig＠iem.at