Now that Pd vanilla + deken is the preferred way to have a Pd-Extended-like experience I was just wondering if there are any best practices or preferred way for loading objects from externals.
Should we reference the external i.e. [mrpeach/binfile] or just load it in our startup path and use [binfile]. The former has the advantage of giving a hint to what externals are needed but results in long objects.
Any suggestions?
On 2016-05-04 10:56, Antonio Roberts wrote:
Now that Pd vanilla + deken is the preferred way to have a Pd-Extended-like experience I was just wondering if there are any best practices or preferred way for loading objects from externals.
Should we reference the external i.e. [mrpeach/binfile] or just load it in our startup path and use [binfile]. The former has the advantage of giving a hint to what externals are needed but results in long objects.
Any suggestions?
*my* suggsetion is to use [declare]
fgamsdrt IOhannes
Hello,
sorry for that but it is not clear to me...
I'm using deken for installing externals but encountering issues with help browser when I enable those externals with preference window, it's actually in another thread.
If I understand, I shouldn't add those deken externals in path preferences, but add a [delare -path ~/pd-externals/my_deken_external] object to all the main patches that uses externals installed into ~/pd-externals, and then path preferences is about externals installed elsewhere.
By this way the console doesn't complain anymore about duplicates when I open help browser without hacking tcl code,
but I'm a bit lost lost now about how to proceed with all my old patches...
patco
Le 04/05/2016 à 13:30, IOhannes m zmoelnig a écrit :
On 2016-05-04 10:56, Antonio Roberts wrote:
Now that Pd vanilla + deken is the preferred way to have a Pd-Extended-like experience I was just wondering if there are any best practices or preferred way for loading objects from externals.
Should we reference the external i.e. [mrpeach/binfile] or just load it in our startup path and use [binfile]. The former has the advantage of giving a hint to what externals are needed but results in long objects.
Any suggestions?
*my* suggsetion is to use [declare]
fgamsdrt IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 05/04/2016 02:18 PM, patrice colet wrote:
If I understand, I shouldn't add those deken externals in path preferences, but add a [delare -path ~/pd-externals/my_deken_external] object to all the main patches that uses externals installed into ~/pd-externals, and then path preferences is about externals installed elsewhere.
you would do [declare -path my_external] and leave out the ~/pd-externals/ part
the fact that deken installed to ~/pd-externals/ is a) specific to your setup b) an implementation detail
also, the fact that the external was installed by deken is purely by coincidence (you could have done the same manually).
fgmadsr IOhannes
Hello,
Deken is really great, but spams my linux home, everytime I load an external.
I suggest since it is now official in vanilla, we should refine now were to store/load externals in linux/debian for future compatibility.
I know it is not deken, but Pd which delivers the paths, but on Standard Linux system which respects
https://specifications.freedesktop.org/basedir-spec/latest/
it should go under .local/share/puredata or .local/lib/pd/ or for old style .pd/ but not on $(Home)/pd-<something>.
So two solution:
a) Deken should not take just pathes from pd but try preferred ones and add pathes to pd on startup
b) Pd suggest as first writeable pathes among others non user-writeable: /var/lib/pd (group puredata set) /usr/local/share/pd, (group puredata set) $(HOME)/.local/lib/pd $(HOME)/pd-external
and deken decides: if the parent dir is writeable it create it and uses it.
so if no ./local it would not take it, but the next suggestion and if in the puredata group which can write to /var/lib/pd take this or
c) deken at least ask where to write it
mfG Winfried
Am Mittwoch, 4. Mai 2016, 13:30:56 schrieb IOhannes m zmoelnig:
On 2016-05-04 10:56, Antonio Roberts wrote:
Now that Pd vanilla + deken is the preferred way to have a Pd-Extended-like experience I was just wondering if there are any best practices or preferred way for loading objects from externals.
Should we reference the external i.e. [mrpeach/binfile] or just load it in our startup path and use [binfile]. The former has the advantage of giving a hint to what externals are needed but results in long objects.
Any suggestions?
*my* suggsetion is to use [declare]
fgamsdrt IOhannes
I agree this is a problem. On my machine, selecting (for instance) freeverb~ from the deken plug-in creates a directory ~/pd/extra/freeverb~ which would be a good place to put it except for the fact that that is my git repo (I then have to move it or else I'd end up publishing freeverb~ in vanilla!).
I think deken should always query the user whether it's OK to install
into the directory it's planning to install to. Indeed, in the function
::deken::clicked_link I see an appropriate line:
set ::deken::installpath [tk_chooseDirectory
(etc) but this never got called when I downloaded freeverb~. I can't
figure out why this isn't getting called. Can anyone suggest a way I
can get deken to always confirm where it will install?
thanks Miller
On Wed, May 04, 2016 at 03:27:27PM +0200, Winfried Ritsch wrote:
Hello,
Deken is really great, but spams my linux home, everytime I load an external.
I suggest since it is now official in vanilla, we should refine now were to store/load externals in linux/debian for future compatibility.
I know it is not deken, but Pd which delivers the paths, but on Standard Linux system which respects
https://specifications.freedesktop.org/basedir-spec/latest/
it should go under .local/share/puredata or .local/lib/pd/ or for old style .pd/ but not on $(Home)/pd-<something>.
So two solution:
a) Deken should not take just pathes from pd but try preferred ones and add pathes to pd on startup
b) Pd suggest as first writeable pathes among others non user-writeable: /var/lib/pd (group puredata set) /usr/local/share/pd, (group puredata set) $(HOME)/.local/lib/pd $(HOME)/pd-external
and deken decides: if the parent dir is writeable it create it and uses it.
so if no ./local it would not take it, but the next suggestion and if in the puredata group which can write to /var/lib/pd take this or
c) deken at least ask where to write it
mfG Winfried
Am Mittwoch, 4. Mai 2016, 13:30:56 schrieb IOhannes m zmoelnig:
On 2016-05-04 10:56, Antonio Roberts wrote:
Now that Pd vanilla + deken is the preferred way to have a Pd-Extended-like experience I was just wondering if there are any best practices or preferred way for loading objects from externals.
Should we reference the external i.e. [mrpeach/binfile] or just load it in our startup path and use [binfile]. The former has the advantage of giving a hint to what externals are needed but results in long objects.
Any suggestions?
*my* suggsetion is to use [declare]
fgamsdrt IOhannes
--
Ritsch, Winfried, Ao.Univ.Prof. Dipl.-Ing. Institut 17 Elektronische Musik und Akustik 8010 Graz, Inffeldgasse 10/III E-Mail ritsch@iem.at Homepage http://iem.at/ritsch Mobil ++436642439369
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Oops, I was looking at the wrong of pd_deken ... I still would like to fix it to always confirm - will now try to code that.
cheers M On Wed, May 04, 2016 at 09:46:04AM -0700, Miller Puckette wrote:
I agree this is a problem. On my machine, selecting (for instance) freeverb~ from the deken plug-in creates a directory ~/pd/extra/freeverb~ which would be a good place to put it except for the fact that that is my git repo (I then have to move it or else I'd end up publishing freeverb~ in vanilla!).
I think deken should always query the user whether it's OK to install into the directory it's planning to install to. Indeed, in the function ::deken::clicked_link I see an appropriate line: set ::deken::installpath [tk_chooseDirectory
(etc) but this never got called when I downloaded freeverb~. I can't figure out why this isn't getting called. Can anyone suggest a way I can get deken to always confirm where it will install?thanks Miller
On Wed, May 04, 2016 at 03:27:27PM +0200, Winfried Ritsch wrote:
Hello,
Deken is really great, but spams my linux home, everytime I load an external.
I suggest since it is now official in vanilla, we should refine now were to store/load externals in linux/debian for future compatibility.
I know it is not deken, but Pd which delivers the paths, but on Standard Linux system which respects
https://specifications.freedesktop.org/basedir-spec/latest/
it should go under .local/share/puredata or .local/lib/pd/ or for old style .pd/ but not on $(Home)/pd-<something>.
So two solution:
a) Deken should not take just pathes from pd but try preferred ones and add pathes to pd on startup
b) Pd suggest as first writeable pathes among others non user-writeable: /var/lib/pd (group puredata set) /usr/local/share/pd, (group puredata set) $(HOME)/.local/lib/pd $(HOME)/pd-external
and deken decides: if the parent dir is writeable it create it and uses it.
so if no ./local it would not take it, but the next suggestion and if in the puredata group which can write to /var/lib/pd take this or
c) deken at least ask where to write it
mfG Winfried
Am Mittwoch, 4. Mai 2016, 13:30:56 schrieb IOhannes m zmoelnig:
On 2016-05-04 10:56, Antonio Roberts wrote:
Now that Pd vanilla + deken is the preferred way to have a Pd-Extended-like experience I was just wondering if there are any best practices or preferred way for loading objects from externals.
Should we reference the external i.e. [mrpeach/binfile] or just load it in our startup path and use [binfile]. The former has the advantage of giving a hint to what externals are needed but results in long objects.
Any suggestions?
*my* suggsetion is to use [declare]
fgamsdrt IOhannes
--
Ritsch, Winfried, Ao.Univ.Prof. Dipl.-Ing. Institut 17 Elektronische Musik und Akustik 8010 Graz, Inffeldgasse 10/III E-Mail ritsch@iem.at Homepage http://iem.at/ritsch Mobil ++436642439369
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
OK... committing a new version of deken... can deken experts please check to make sure I haven't broken something (or let me know if there's any reason this should be done differently :)
thanks Miller
On Wed, May 04, 2016 at 09:52:49AM -0700, Miller Puckette wrote:
Oops, I was looking at the wrong of pd_deken ... I still would like to fix it to always confirm - will now try to code that.
cheers M On Wed, May 04, 2016 at 09:46:04AM -0700, Miller Puckette wrote:
I agree this is a problem. On my machine, selecting (for instance) freeverb~ from the deken plug-in creates a directory ~/pd/extra/freeverb~ which would be a good place to put it except for the fact that that is my git repo (I then have to move it or else I'd end up publishing freeverb~ in vanilla!).
I think deken should always query the user whether it's OK to install into the directory it's planning to install to. Indeed, in the function ::deken::clicked_link I see an appropriate line: set ::deken::installpath [tk_chooseDirectory
(etc) but this never got called when I downloaded freeverb~. I can't figure out why this isn't getting called. Can anyone suggest a way I can get deken to always confirm where it will install?thanks Miller
On Wed, May 04, 2016 at 03:27:27PM +0200, Winfried Ritsch wrote:
Hello,
Deken is really great, but spams my linux home, everytime I load an external.
I suggest since it is now official in vanilla, we should refine now were to store/load externals in linux/debian for future compatibility.
I know it is not deken, but Pd which delivers the paths, but on Standard Linux system which respects
https://specifications.freedesktop.org/basedir-spec/latest/
it should go under .local/share/puredata or .local/lib/pd/ or for old style .pd/ but not on $(Home)/pd-<something>.
So two solution:
a) Deken should not take just pathes from pd but try preferred ones and add pathes to pd on startup
b) Pd suggest as first writeable pathes among others non user-writeable: /var/lib/pd (group puredata set) /usr/local/share/pd, (group puredata set) $(HOME)/.local/lib/pd $(HOME)/pd-external
and deken decides: if the parent dir is writeable it create it and uses it.
so if no ./local it would not take it, but the next suggestion and if in the puredata group which can write to /var/lib/pd take this or
c) deken at least ask where to write it
mfG Winfried
Am Mittwoch, 4. Mai 2016, 13:30:56 schrieb IOhannes m zmoelnig:
On 2016-05-04 10:56, Antonio Roberts wrote:
Now that Pd vanilla + deken is the preferred way to have a Pd-Extended-like experience I was just wondering if there are any best practices or preferred way for loading objects from externals.
Should we reference the external i.e. [mrpeach/binfile] or just load it in our startup path and use [binfile]. The former has the advantage of giving a hint to what externals are needed but results in long objects.
Any suggestions?
*my* suggsetion is to use [declare]
fgamsdrt IOhannes
--
Ritsch, Winfried, Ao.Univ.Prof. Dipl.-Ing. Institut 17 Elektronische Musik und Akustik 8010 Graz, Inffeldgasse 10/III E-Mail ritsch@iem.at Homepage http://iem.at/ritsch Mobil ++436642439369
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 05/04/2016 06:46 PM, Miller Puckette wrote:
I agree this is a problem. On my machine, selecting (for instance) freeverb~ from the deken plug-in creates a directory ~/pd/extra/freeverb~
the actual Pd binary you are running is ~/pd/bin/pd, right?
which would be a good place to put it except for the fact that that is my git repo (I then have to move it or else I'd end up publishing freeverb~ in vanilla!).
I think deken should always query the user whether it's OK to install
hmm, i'm not so fond about *always query*, this is why i turned this off... i don't even think it is a great user experience if Pd asks the user once in each session (though that's way better than asking *every* time).
that's not to say that i don't agree that deken should not pollute your ~/pd/extra/ folder. but i wonder whether there is not a more elegant way to solve this issue.
the first question is, whether this is really a general problem or just a very specific problem to *your* workflow (that is, most people happen to do their everyday work on the canoncial upstream source of Pd and therefore won't ever run the risk of publishing a new shiny release of Pd with an illegitimate library in extra/). if this is the case, then we could probably just add some simple blacklisting mechanism in the deken-config that excludes ~/pd/extra/ on miller puckettes eeePC.
otoh, the extra/ folder of the running Pd instance is probably not a good place to install stuff too in *most* circumstances (the only reason i can think of is that someone is assembling their own Pd-bundled-with-externals). since this path is usually the very last in the list of default search paths, we could easily remove this element instead.
oh, and for completeness sake: the "current" (before miller's changes today) behaviour was, that deken has a [select dir] button, where the user can change the install directory before they download/install any library (or change the directory after installing freeverb and before installing moocow). however, this is an opt-in feature.
mfgards IOhannes
On Wed, May 04, 2016 at 11:17:32PM +0200, IOhannes m zmölnig wrote:
On 05/04/2016 06:46 PM, Miller Puckette wrote:
I agree this is a problem. On my machine, selecting (for instance) freeverb~ from the deken plug-in creates a directory ~/pd/extra/freeverb~
the actual Pd binary you are running is ~/pd/bin/pd, right?
Yes.
which would be a good place to put it except for the fact that that is my git repo (I then have to move it or else I'd end up publishing freeverb~ in vanilla!).
I think deken should always query the user whether it's OK to install
hmm, i'm not so fond about *always query*, this is why i turned this off... i don't even think it is a great user experience if Pd asks the user once in each session (though that's way better than asking *every* time).
that's not to say that i don't agree that deken should not pollute your ~/pd/extra/ folder. but i wonder whether there is not a more elegant way to solve this issue.
the first question is, whether this is really a general problem or just a very specific problem to *your* workflow (that is, most people happen to do their everyday work on the canoncial upstream source of Pd and therefore won't ever run the risk of publishing a new shiny release of Pd with an illegitimate library in extra/). if this is the case, then we could probably just add some simple blacklisting mechanism in the deken-config that excludes ~/pd/extra/ on miller puckettes eeePC.
otoh, the extra/ folder of the running Pd instance is probably not a good place to install stuff too in *most* circumstances (the only reason i can think of is that someone is assembling their own Pd-bundled-with-externals). since this path is usually the very last in the list of default search paths, we could easily remove this element instead.
I probably have a very twisted vision of how people use Pd... around UCSD people often have 2 or 3 different versions of Pd on their machines and as far as I know the only way to disambiguate which extern goes with which version is to use pd/extra.
OTOH, if it's just me, I don't see anything wrong with just hoping I can remember to hit the "choose directory" button before ever downloading anything. I imagine this is shooting more people than just me in our feet but I'd be happy to learn that I was wrong :)
And/or, just have it check if the username is "msp" and special-case me :) M
oh, and for completeness sake: the "current" (before miller's changes today) behaviour was, that deken has a [select dir] button, where the user can change the install directory before they download/install any library (or change the directory after installing freeverb and before installing moocow). however, this is an opt-in feature.
mfgards IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 05/04/2016 11:36 PM, Miller Puckette wrote:
I probably have a very twisted vision of how people use Pd... around UCSD people often have 2 or 3 different versions of Pd on their machines and as far as I know the only way to disambiguate which extern goes with which version is to use pd/extra.
so what would the expected outcome be for those people? if they install a library via deken, should that be available in all versions of Pd, or just in the one they are currently using?
gfmdsar IOhannes
I believe it should be just the one. But I'm a scope conservative (despite the contradictory evidence that Pd has, in fact, no scoping mechanism :)
On Wed, May 04, 2016 at 11:49:41PM +0200, IOhannes m zmölnig wrote:
On 05/04/2016 11:36 PM, Miller Puckette wrote:
I probably have a very twisted vision of how people use Pd... around UCSD people often have 2 or 3 different versions of Pd on their machines and as far as I know the only way to disambiguate which extern goes with which version is to use pd/extra.
so what would the expected outcome be for those people? if they install a library via deken, should that be available in all versions of Pd, or just in the one they are currently using?
gfmdsar IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 05/04/2016 11:53 PM, Miller Puckette wrote:
I believe it should be just the one. But I'm a scope conservative (despite the contradictory evidence that Pd has, in fact, no scoping mechanism :)
hmm, so: for your people at UCSD you would like to have externals installed into ~/pd/extra and ~/pd-0.46-4/extra and ~/pd-0.22/extra depending on which version of Pd you are running. for yourself, you would like to have externals NOT be installed into ~/pd/extra.
since these two behaviours are contradictory and cannot be resolved automatically, the only option is to ask the user every single time they are going to install a library via deken, at the potential cost ofthem shouting "but i told you this directory already three times this morning" at their computers.
fdmsar IOhannes
well there is also the often used/famous "don't ask me next time" checkbox. of course it has to come with a "reset defaults" in the preferences as well…
(sorry this one got to you only iohannes)
On 05 May 2016, at 20:32, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 05/04/2016 11:53 PM, Miller Puckette wrote:
I believe it should be just the one. But I'm a scope conservative (despite the contradictory evidence that Pd has, in fact, no scoping mechanism :)
hmm, so: for your people at UCSD you would like to have externals installed into ~/pd/extra and ~/pd-0.46-4/extra and ~/pd-0.22/extra depending on which version of Pd you are running. for yourself, you would like to have externals NOT be installed into ~/pd/extra.
since these two behaviours are contradictory and cannot be resolved automatically, the only option is to ask the user every single time they are going to install a library via deken, at the potential cost ofthem shouting "but i told you this directory already three times this morning" at their computers.
fdmsar IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Well, another way migth be to have Pd only query the first time in a Pd session and then proceed automatically. I'll try that out - but since I'll probably introduce a bug or two I'd just as soon wait till after the 0.27-0 release.
Me, when I shout a thte computer, it's more likely to be "where the *&$^%& did you put the file I just downloaded?" or "why the $%*& did you just do that" as opposed to "why did you just ask me to confirm this operation that will put files on my disk". But I know my own tastes aren't shared by all users...
cheers M
On Thu, May 05, 2016 at 08:32:46PM +0200, IOhannes m zmölnig wrote:
On 05/04/2016 11:53 PM, Miller Puckette wrote:
I believe it should be just the one. But I'm a scope conservative (despite the contradictory evidence that Pd has, in fact, no scoping mechanism :)
hmm, so: for your people at UCSD you would like to have externals installed into ~/pd/extra and ~/pd-0.46-4/extra and ~/pd-0.22/extra depending on which version of Pd you are running. for yourself, you would like to have externals NOT be installed into ~/pd/extra.
since these two behaviours are contradictory and cannot be resolved automatically, the only option is to ask the user every single time they are going to install a library via deken, at the potential cost ofthem shouting "but i told you this directory already three times this morning" at their computers.
fdmsar IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Thu, May 05, 2016 at 08:32:46PM +0200, IOhannes m zmölnig wrote:
On 05/04/2016 11:53 PM, Miller Puckette wrote:
I believe it should be just the one. But I'm a scope conservative (despite the contradictory evidence that Pd has, in fact, no scoping mechanism :)
hmm, so: for your people at UCSD you would like to have externals installed into ~/pd/extra and ~/pd-0.46-4/extra and ~/pd-0.22/extra depending on which version of Pd you are running. for yourself, you would like to have externals NOT be installed into ~/pd/extra.
since these two behaviours are contradictory and cannot be resolved automatically, the only option is to ask the user every single time they are going to install a library via deken, at the potential cost ofthem shouting "but i told you this directory already three times this morning" at their computers.
On 08/05/16 11:12, Miller Puckette wrote:
Well, another way migth be to have Pd only query the first time in a Pd session and then proceed automatically.
Speaking as a fellow "scope conservative" I know that it is possible to cater for all of the above cases where a user might want a different install and loading paths for externals, because it has already been solved by other scripting languages such as Python.
Consider the following selection of different install-path use cases:
- User has root and wants to install an external to some location,
available to all instances of Pd on the system (system administrator).
- User does not have (or want to use) root, uses [one of several]
pre-built binaries of Pd in their homedir and they want to install different externals for the exclusive use of each one.
- User does not have (or want to use) root, uses system Pd or other Pds
and wants to install externals available to all.
- User wants to install an external for use by a single patch only so
they can zip up that patch with all it's dependencies and send it to a gallery for deployment on an identical architecture machine. They don't want the external polluting all copies of Pd.
In Python for example, you would use a virtualenv (or nodeenv in node) for the local case (4) and different flags to pip/easy_install for cases 1-3.
In Pd, I don't think it's hard to come up with a UI that satisfies all of these possibilities, with a sensible default setting (such as saving to "~/pd-externals").
Imagine the current deken interface, but with one extra pull-down with the label "install to:" and the following selection:
- ~/pd-externals/ (default)
- /path/to/current/pd/extras (if root is required some message is shown)
- /path/to/currently/selected/patch/directory
The second and third options would obviously be dynamic.
It would probably also make sense for the pull-down to default to the last selected value when changed.
I should have submitted a pull-request instead of this email, sorry about that!
Cheers,
Chris
Hi,
On 08/05/16 11:12, Miller Puckette wrote:
Me, when I shout a thte computer, it's more likely to be "where the *&$^%& did you put the file I just downloaded?" or "why the $%*& did you just do that" as opposed to "why did you just ask me to confirm this operation that will put files on my disk". But I know my own tastes aren't shared by all users...
While we are shouting, it seems people (including you) are annoyed about "~/pd-externals" all up in their home directory. I wonder if it would make sense to deprecate that in favour of standard config paths on all platforms?
Blender does this well already and follows existing desktop standards. I think it would be a good model to copy:
Linux = $HOME/.config/blender/2.77/
Mac OSX = /Users/$USER/Library/Application Support/Blender/2.77/
MS-Windows = C:\Documents and Settings$USERNAME\AppData\Roaming\Blender Foundation\Blender\2.77\
https://www.blender.org/manual/getting_started/installing_blender/directoryl...
For Pd you probably wouldn't need the version number thing. Or maybe you would?
Once again I am sorry that this is an email and not a pull-request!
Cheers,
Chris.
On 2016-05-09 03:32, Chris McCormick wrote:
Hi,
On 08/05/16 11:12, Miller Puckette wrote:
Me, when I shout a thte computer, it's more likely to be "where the *&$^%& did you put the file I just downloaded?" or "why the $%*& did you just do that" as opposed to "why did you just ask me to confirm this operation that will put files on my disk". But I know my own tastes aren't shared by all users...
While we are shouting, it seems people (including you) are annoyed about "~/pd-externals" all up in their home directory. I wonder if it would make sense to deprecate that in favour of standard config paths on all platforms?
Blender does this well already and follows existing desktop standards. I think it would be a good model to copy:
Linux = $HOME/.config/blender/2.77/
Mac OSX = /Users/$USER/Library/Application Support/Blender/2.77/
MS-Windows = C:\Documents and Settings$USERNAME\AppData\Roaming\Blender Foundation\Blender\2.77\
i was always under the impression that the W32 and OSX search paths were pretty OK, so i'm not sure whether action is needed on that side (but of course i am on linux mostly)
i guess this impression mainly comes from the question of how easy it is to hide/ignore that folder, even if I did install something to it. e.g. on w32, the "%AppData%" path is there already in most cases, and it is in a place that i (as the user) don't usually open, so it doesn't get in my way.
so the main problem is on linux, where "pd-externals" show up in my *home* directory, a place that everybody finds themselves looking at all the time.
so i'm all for moving to ~/.local/lib/pd/extra/ (and/or ~/.local/lib/pd/0.47-3/extra/ if somebody thinks this is useful)
the relevant specs can be found at [1]
gfdmasr IOhannes
PS: i don't think that ~/.config/ is the right place to put externals to, regardless of what blender does (again, see [1])
[1] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
I also propose using for linux systems the standard $(HOME)/.local directory.
the only minor questions for me would be (in preferred order):
(a) ~/.local/lib/pd/extra/ (b) ~/.local/lib/pd-external/ (c) ~/.local/lib/pd/<version>/extra/
The idea of the standard path "~/.local" is, that it will be as common and well known as /usr/local is now for system-wide non distribution software. So everyone dealing with linux desktop should find it. Anyhow, path will be shown/hinted during deken install process.
(a) +: one can copy all of .local/pd stuff to another user account if needed and don't need to install all stuff again (until I get an error) because the pd version was altered.
(b) was used like IOhannes explained on /usr/local/ to distinguish between /usr/local/bin/pd and some other instance of pd like /usr/bin/pd.
But in my opinion if had to use different versions of pd parallel, I do it out my project directory, (if there is really a need for this) and not using /usr/local or any other common place to distinguish them.
(c) like explained in a do not want to install it again when pd version alters. so I dislike this path since externals versions are mostly not in sync with PD-versions.
Summarizing:
So we have for pd externals, libraries and addons:
~/.local/lib/pd/extra - for user wide pd stuff ~/pd-external - deprecated old user wide pd stuff
/usr/local/lib/pd-externals - for manual systemwide installs of pd externals
/usr/local/lib/pd/extra/ - for manual systemwide installs only
exclusive for /usr/local/bin/pd installation
/usr/lib/pd/extra/ - for packaged "third party" = not vanilla pd stuff
(/usr/lib/puredata/extra - for pd vanilla pd packaged stuff)
Anyhow for backwards compatibility we should leave old paths, just don't enforce them and order the preferred first.
Personally vote for (a)
mfG Winfried
PS:For config file i start an own discussion ( now it is ~/.pdsettings and should move to .config/pd/settings.conf)
Am Montag, 9. Mai 2016, 10:27:32 schrieb IOhannes m zmoelnig:
On 2016-05-09 03:32, Chris McCormick wrote:
Hi,
On 08/05/16 11:12, Miller Puckette wrote:
Me, when I shout a thte computer, it's more likely to be "where the *&$^%& did you put the file I just downloaded?" or "why the $%*& did you just do that" as opposed to "why did you just ask me to confirm this operation that will put files on my disk". But I know my own tastes aren't shared by all users...
While we are shouting, it seems people (including you) are annoyed about "~/pd-externals" all up in their home directory. I wonder if it would make sense to deprecate that in favour of standard config paths on all platforms?
Blender does this well already and follows existing desktop standards. I think it would be a good model to copy:
Linux = $HOME/.config/blender/2.77/
Mac OSX = /Users/$USER/Library/Application Support/Blender/2.77/
MS-Windows = C:\Documents and Settings$USERNAME\AppData\Roaming\Blender Foundation\Blender\2.77\
i was always under the impression that the W32 and OSX search paths were pretty OK, so i'm not sure whether action is needed on that side (but of course i am on linux mostly)
i guess this impression mainly comes from the question of how easy it is to hide/ignore that folder, even if I did install something to it. e.g. on w32, the "%AppData%" path is there already in most cases, and it is in a place that i (as the user) don't usually open, so it doesn't get in my way.
so the main problem is on linux, where "pd-externals" show up in my *home* directory, a place that everybody finds themselves looking at all the time.
so i'm all for moving to ~/.local/lib/pd/extra/ (and/or ~/.local/lib/pd/0.47-3/extra/ if somebody thinks this is useful)
the relevant specs can be found at [1]
gfdmasr IOhannes
PS: i don't think that ~/.config/ is the right place to put externals to, regardless of what blender does (again, see [1])
[1] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
OK... so what I hope I just did is to make Pd search in this order:
~/.local/lib/pd/extra/ ~/pd-externals /usr/local/lib/pd-externals
... in that order. We can consider ~/pd-externals to be obsolete.
cheers Miller
On Mon, May 09, 2016 at 03:01:33PM +0200, Winfried Ritsch wrote:
I also propose using for linux systems the standard $(HOME)/.local directory.
the only minor questions for me would be (in preferred order):
(a) ~/.local/lib/pd/extra/ (b) ~/.local/lib/pd-external/ (c) ~/.local/lib/pd/<version>/extra/
The idea of the standard path "~/.local" is, that it will be as common and well known as /usr/local is now for system-wide non distribution software. So everyone dealing with linux desktop should find it. Anyhow, path will be shown/hinted during deken install process.
(a) +: one can copy all of .local/pd stuff to another user account if needed and don't need to install all stuff again (until I get an error) because the pd version was altered.
(b) was used like IOhannes explained on /usr/local/ to distinguish between /usr/local/bin/pd and some other instance of pd like /usr/bin/pd.
But in my opinion if had to use different versions of pd parallel, I do it out my project directory, (if there is really a need for this) and not using /usr/local or any other common place to distinguish them.
(c) like explained in a do not want to install it again when pd version alters. so I dislike this path since externals versions are mostly not in sync with PD-versions.
Summarizing:
So we have for pd externals, libraries and addons:
~/.local/lib/pd/extra - for user wide pd stuff ~/pd-external - deprecated old user wide pd stuff
/usr/local/lib/pd-externals - for manual systemwide installs of pd externals /usr/local/lib/pd/extra/ - for manual systemwide installs only
exclusive for /usr/local/bin/pd installation /usr/lib/pd/extra/ - for packaged "third party" = not vanilla pd stuff
(/usr/lib/puredata/extra - for pd vanilla pd packaged stuff)Anyhow for backwards compatibility we should leave old paths, just don't enforce them and order the preferred first.
Personally vote for (a)
mfG Winfried
PS:For config file i start an own discussion ( now it is ~/.pdsettings and should move to .config/pd/settings.conf)
Am Montag, 9. Mai 2016, 10:27:32 schrieb IOhannes m zmoelnig:
On 2016-05-09 03:32, Chris McCormick wrote:
Hi,
On 08/05/16 11:12, Miller Puckette wrote:
Me, when I shout a thte computer, it's more likely to be "where the *&$^%& did you put the file I just downloaded?" or "why the $%*& did you just do that" as opposed to "why did you just ask me to confirm this operation that will put files on my disk". But I know my own tastes aren't shared by all users...
While we are shouting, it seems people (including you) are annoyed about "~/pd-externals" all up in their home directory. I wonder if it would make sense to deprecate that in favour of standard config paths on all platforms?
Blender does this well already and follows existing desktop standards. I think it would be a good model to copy:
Linux = $HOME/.config/blender/2.77/
Mac OSX = /Users/$USER/Library/Application Support/Blender/2.77/
MS-Windows = C:\Documents and Settings$USERNAME\AppData\Roaming\Blender Foundation\Blender\2.77\
i was always under the impression that the W32 and OSX search paths were pretty OK, so i'm not sure whether action is needed on that side (but of course i am on linux mostly)
i guess this impression mainly comes from the question of how easy it is to hide/ignore that folder, even if I did install something to it. e.g. on w32, the "%AppData%" path is there already in most cases, and it is in a place that i (as the user) don't usually open, so it doesn't get in my way.
so the main problem is on linux, where "pd-externals" show up in my *home* directory, a place that everybody finds themselves looking at all the time.
so i'm all for moving to ~/.local/lib/pd/extra/ (and/or ~/.local/lib/pd/0.47-3/extra/ if somebody thinks this is useful)
the relevant specs can be found at [1]
gfdmasr IOhannes
PS: i don't think that ~/.config/ is the right place to put externals to, regardless of what blender does (again, see [1])
[1] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
--
- ao.Univ.Prof. DI Winfried Ritsch
- ritsch@iem.at - http://iem.at/ritsch
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171
--
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi all,
On 17/05/2016 04:14, Miller Puckette wrote:
OK... so what I hope I just did is to make Pd search in this order:
~/.local/lib/pd/extra/ ~/pd-externals /usr/local/lib/pd-externals
... in that order. We can consider ~/pd-externals to be obsolete.
I know the discussion in mostly about externals, but personally I also have a bunch of home-made abstractions (and a couple of gui plugins) I always like to have in my Pd search path and ~/pd-externals/ is nice because: a) it's "portable" when I back-up my home directory b) it's (mostly) independent of Pd versions...
But, because this is a specific use case for my set-up/machine I think in principle it would make sense to: a) Add my local use-case path to my pd config b) That pd-config would live in somewhere like $HOME/.config/pd
Also, I know this is probably nit-picking, but shouldn't configuration and (local) externals be in two different paths?
Lorenzo.
On 2016-05-17 09:59, Lorenzo Sutton wrote:
~/.local/lib/pd/extra/ ~/pd-externals /usr/local/lib/pd-externals
... in that order. We can consider ~/pd-externals to be obsolete.
I know the discussion in mostly about externals, but personally I also have a bunch of home-made abstractions (and a couple of gui plugins) I always like to have in my Pd search path and ~/pd-externals/ is nice because: a) it's "portable" when I back-up my home directory b) it's (mostly) independent of Pd versions...
But, because this is a specific use case for my set-up/machine
hmm,
- how does your setup break with the new behavious?
and to answer you r specific questions:
a) ~/.local/lib/pd/extra is in your home directory as well, so how is it less *portable*? b) i don't see anything version specific in the new behaviour.
i can only see two possible issues: a) you only backup "visible" folders in your home-directory, so you would miss ~/.local/lib/pd/extra b) your olde versions of Pd would not know about ~/.local/lib/pd/extra and only search in ~/pd-externals; so putting externals into the new path would be "incompatible" with loading them from old Pd's.
a simple fix for (b) is to keep your externals in ~/.local/... and symlink ~/.local/lib/pd/extra to ~/pd-externals a simple for for (a) is to do the reverse (keep your externals in ~/pd-externals and make ~/.local/lib/pd/extra a symlink to this place); this would also fix (b), but for aesthetic reasons i dislike it a bit more :-)
the drawback with this is, that a Pd-version that looks for externals in both places, will find them multiple times (which will give ugly error messages on the console).
the easiest fix for this is to just remove ~/pd-externals entirely from the built-in search paths and add a BIG UPGRADING NOTE that mentions the symlinks (and/or "adding -path").
fgmasdr IOhannes
On 17/05/2016 10:46, IOhannes m zmoelnig wrote:
On 2016-05-17 09:59, Lorenzo Sutton wrote:
~/.local/lib/pd/extra/ ~/pd-externals /usr/local/lib/pd-externals
... in that order. We can consider ~/pd-externals to be obsolete.
I know the discussion in mostly about externals, but personally I also have a bunch of home-made abstractions (and a couple of gui plugins) I always like to have in my Pd search path and ~/pd-externals/ is nice because: a) it's "portable" when I back-up my home directory b) it's (mostly) independent of Pd versions...
But, because this is a specific use case for my set-up/machine
hmm,
- how does your setup break with the new behavious?
and to answer you r specific questions:
Actually they weren't questions... just considerations :)
a) ~/.local/lib/pd/extra is in your home directory as well, so how is it less *portable*? b) i don't see anything version specific in the new behaviour.
Yes that's perfectly fine-
i can only see two possible issues: a) you only backup "visible" folders in your home-directory, so you would miss ~/.local/lib/pd/extra
Not an issue for me. I use (g)rsync annd I do filter out a several 'dot-dirs' but not systematically (i.e. they are explicitly listed in a file which is used by rsync as an ignore list)
the easiest fix for this is to just remove ~/pd-externals entirely from the built-in search paths and add a BIG UPGRADING NOTE that mentions the symlinks (and/or "adding -path").
Yes, I mean eventually it's just a matter of knowing it. After all one can customise the Pd search path and have is serch in ~/pd-myminipony if it works for them :)
On 09/05/16 16:27, IOhannes m zmoelnig wrote:
so i'm all for moving to ~/.local/lib/pd/extra/ (and/or ~/.local/lib/pd/0.47-3/extra/ if somebody thinks this is useful) PS: i don't think that ~/.config/ is the right place to put externals https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
Agree, sounds good!
Cheers,
Chris.
Hello,
Just a suggestion : it is a good thing to move all externals in ~/.local/lib/pd/extra/ but it would be a good point if it is possible to remove them using deken (and maybe remove path ?). I don't know if it is easily doable/possible/advisable. ++
Jack
Le 10/05/2016 13:41, Chris McCormick a écrit :
On 09/05/16 16:27, IOhannes m zmoelnig wrote:
so i'm all for moving to ~/.local/lib/pd/extra/ (and/or ~/.local/lib/pd/0.47-3/extra/ if somebody thinks this is useful) PS: i don't think that ~/.config/ is the right place to put externals https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
Agree, sounds good!
Cheers,
Chris.
On 05/04/2016 03:27 PM, Winfried Ritsch wrote:
a) Deken should not take just pathes from pd but try preferred ones and add pathes to pd on startup
i strongly oppose. it's Pd's job to use sensible default search paths, and deken should follow the lead. put otherwise: there should only be a single central place where the default search paths are defined, and this ought to be within Pd-core (since deken is just a GUI addon, that won't unfold it's power if there was no gui)
b) Pd suggest as first writeable pathes among others non user-writeable: /var/lib/pd (group puredata set) /usr/local/share/pd, (group puredata set)
i don't think that either of those places is the correct place.
- /var is for "variable files—files whose content is expected to
continually change during normal operation of the system—such as logs, spool files, and temporary e-mail files." - this is definitely *not* addon libraries.
- /usr/local/share or /usr/share is for "architecture-independent
(shared) data." and most Pd-libraries (installed via deken or otherwise) are architecture dependent binaries.
$(HOME)/.local/lib/pd $(HOME)/pd-external
and deken decides: if the parent dir is writeable it create it and uses it.
deken did this in the past. it ended up creating ${HOME}/pd-externals (which we all hate), because ${HOME} is the only place of all your proposals that is (almost always) guaranteed to exist *and* writable by the user.
so now deken does something similar: if the directory itself exists and is writeable, it uses it. else it asks the user.
so if no ./local it would not take it, but the next suggestion and if in the puredata group which can write to /var/lib/pd take this or
well, you can already do this:
- create a group "puredata"
- add yourself to the "puredata" group
- create "/usr/local/lib/pd-externals/"
- make "/usr/local/lib/pd-externals/" writable by the "puredata" group
- use deken
apart from the last bit, nothing is related to Pd; i therefore think that it is *not* Pd's task to do anything of it (*maybe* this can be added to a puredata.deb or .rpm)
c) deken at least ask where to write it
which is what it does.
gasmr IOhannes
To sumarize the discussion about deken path:
I mostly agree IOhannes and Miller:
- no writing without asking, avoid hidden operations to the file system
- pd should be sensible to standard system and user paths
- deken uses Pd conventions without adding something
Since modern linux desktops respect the "Standard Linux system path" recommendations [1], ( like it or not it is the way to go if we want Pd to be accepted in standard linux desktops and not patched by packagers for the distributions )
we should add the default user path to Pd: "~/.local/lib/pd/extra" (see patch attached) and leave for backward compatibility the "~/pd- externals" path. Since new path is preferred we place it before the old one. (simple patch attached.)
Argumentation
Preassumption: I want to control and know the behaviour, versions and places where Pd stuff is stored, know which objects is part of a what library. I also prefer (for education) that users know what they are doing on their systems and don't have to make a forensic research what happened after a automatic install.
Analyzing my use cases, I look at external libraries in two different ways:
(1) externals which I trust and always use as a base (here at IEM the iemlibs, zexy, acre, ...)
(2) externals I need for a special kind of problem like communication, sensors, ... (eg. iemambi, iem_bin_ambi, comport, ...)
and decide two main use cases when working with Pd:
(A) prototype with pd and explore something...
(B) make an project which should work until eternity and is easily error-free reproducible on different systems for concerts, installations and distributions.
So starting Pd I want my trusted libraries (1) in my standard path and I do not want any other libraries loaded or found without [declare]s.
The extra libraries (2) I want to add
use case (A) to a temporary project folder somewhere
use case (B) to a directory in my project folder. I moslty use "libs/" with a script in libs for (down)loading externals from somewhere, so these will not be content of my project repository)
To accomplish this with "deken", I only load the 1) libraries to my home standard path, where pd find it without extra "declare -path" or install them as system package. (in debian).
All other externals I load with deken plugin to my project (being asked where to store it) and adding an "declare -path libs/" or so in my main patch.
Since there are two naming conventions for external container: ".../pd- externals/" and ".../pd/extra/" it would prefer the second for relative path since maybe there will be added some other stuff like in pd/doc ... and then there is only one "pd" directory in the path.
The next story would be where to store the config/setting files od deken and Pd, but this is another thread.
mfg winfried ritsch
PS: ad a) A deken-download script outside Pd would be great to automate filling the libs from deken-sources without using deken dialog.
[1] https://specifications.freedesktop.org/basedir-spec/latest/Standard
Am Mittwoch, 4. Mai 2016, 23:01:58 schrieb IOhannes m zmölnig:
On 05/04/2016 03:27 PM, Winfried Ritsch wrote:
a) Deken should not take just pathes from pd but try preferred ones and add pathes to pd on startup
i strongly oppose. it's Pd's job to use sensible default search paths, and deken should follow the lead. put otherwise: there should only be a single central place where the default search paths are defined, and this ought to be within Pd-core (since deken is just a GUI addon, that won't unfold it's power if there was no gui)
b) Pd suggest as first writeable pathes among others non user-writeable: /var/lib/pd (group puredata set) /usr/local/share/pd, (group puredata set)
i don't think that either of those places is the correct place.
- /var is for "variable files—files whose content is expected to
continually change during normal operation of the system—such as logs, spool files, and temporary e-mail files." - this is definitely *not* addon libraries.
- /usr/local/share or /usr/share is for "architecture-independent
(shared) data." and most Pd-libraries (installed via deken or otherwise) are architecture dependent binaries.
$(HOME)/.local/lib/pd $(HOME)/pd-external
and deken decides: if the parent dir is writeable it create it and uses it.
deken did this in the past. it ended up creating ${HOME}/pd-externals (which we all hate), because ${HOME} is the only place of all your proposals that is (almost always) guaranteed to exist *and* writable by the user.
so now deken does something similar: if the directory itself exists and is writeable, it uses it. else it asks the user.
so if no ./local it would not take it, but the next suggestion and if in the puredata group which can write to /var/lib/pd take this or
well, you can already do this:
- create a group "puredata"
- add yourself to the "puredata" group
- create "/usr/local/lib/pd-externals/"
- make "/usr/local/lib/pd-externals/" writable by the "puredata" group
- use deken
apart from the last bit, nothing is related to Pd; i therefore think that it is *not* Pd's task to do anything of it (*maybe* this can be added to a puredata.deb or .rpm)
c) deken at least ask where to write it
which is what it does.
gasmr IOhannes
On 05/08/2016 11:00 AM, Winfried Ritsch wrote:
Since there are two naming conventions for external container: ".../pd- externals/" and ".../pd/extra/" it would prefer the second for relative path since maybe there will be added some other stuff like in pd/doc ... and then there is only one "pd" directory in the path.
i think that /usr/local/lib/pd-externals/ was introduced exactly because there was a need to make it different from /usr/local/lib/pd/extra (both /usr/bin/pd and /usr/local/bin/pd would look for externals in /usr/local/lib/pd-externals/)
gfrdsa IOhannes
-
Antonio Roberts -
Chris McCormick -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jack -
Lorenzo Sutton -
Miller Puckette -
patrice colet -
Simon Iten -
Winfried Ritsch