Re: [PD] standard paths for externals

[Roman Haefeli]

On Fri, 2018-07-13 at 14:27 -0300, Alexandre Torres Porres wrote:
> 
> 
> 2018-07-13 11:12 GMT-03:00 Roman Haefeli :
> > So, does that mean the [declare]-flags -stdlib and -stdpath are
> > obsolete now?

Oops, bad wording on my part. I should have said 'in the declare-path
branch' instead of 'now' as readers might think it was already changed
in Pd, which is _not_ the case. I'm talking about a feature branch that
  possibly/hopefully makes it into Pd. 

> yes, and this was mentioned in this thread already - but it is kept
> there for backwards compatibility concerns, for not to have a change
> in behaviour from one version to another, so your old configuration
> still works 

Alright, that's absolutely correct. Old flags still work with old
layout, new flags work with new layout. So there is no problem with the
transition. Thanks for the clarification. 

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Alexandre Torres Porres]

This is not a switch in behaviour as I see it, since you can keep things as
they are and the behaviour is still the same. Hence, no compatibility
breakage here.

Now, if you wanna do things differently, in a new way, as another option,
then this is provided and you should adapt your patches.

So it is a matter of deciding wether if it is worth to change your setup or
not...

cheers

2018-07-13 11:12 GMT-03:00 Roman Haefeli :

> On Thu, 2018-06-14 at 16:32 -0300, Alexandre Torres Porres wrote:
> > 2018-06-14 15:35 GMT-03:00 Roman Haefeli :
> > > Is this the idea?
> >
> > Yes! And it's working like that in my tests.
>
> Ok, it's working for me, too. I see significant progress in that (after
> having cleared all preferences) I end up with a "working" setup by
> clicking myself through the defaults. Things get downloaded to
> ~/Documents/Pd/externals, which was automatically created added to the
> search paths. After installing externals through 'Find externals', I
> can load them by [declare -lib ] and [declare -path ].
>
> So, does that mean the [declare]-flags -stdlib and -stdpath are
> obsolete now?
>
> I can't spot any problems with the branch feature/declare-path, but
> virtually all of my patches are broken with it because of incompatible
> [declare] flags. I like the 'new way' much better, but I wonder what is
> a good path to get there. It's actually an easy thing to replace all
> occurences of -stdlib/-stdpath with -lib/path. But switching behaviour
> from one version of Pd to the next seems bold.
>
> Roman
>
>
>
>
>
> ___
> 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

Re: [PD] standard paths for externals

[Roman Haefeli]

On Thu, 2018-06-14 at 16:32 -0300, Alexandre Torres Porres wrote:
> 2018-06-14 15:35 GMT-03:00 Roman Haefeli :
> > Is this the idea?
> 
> Yes! And it's working like that in my tests.

Ok, it's working for me, too. I see significant progress in that (after
having cleared all preferences) I end up with a "working" setup by
clicking myself through the defaults. Things get downloaded to
~/Documents/Pd/externals, which was automatically created added to the
search paths. After installing externals through 'Find externals', I
can load them by [declare -lib ] and [declare -path ].

So, does that mean the [declare]-flags -stdlib and -stdpath are
obsolete now?

I can't spot any problems with the branch feature/declare-path, but
virtually all of my patches are broken with it because of incompatible
[declare] flags. I like the 'new way' much better, but I wonder what is
a good path to get there. It's actually an easy thing to replace all
occurences of -stdlib/-stdpath with -lib/path. But switching behaviour
from one version of Pd to the next seems bold.

Roman






signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Dan Wilcox]

> On Jun 14, 2018, at 9:44 PM, pd-list-requ...@lists.iem.at wrote:
> 
> User adds '/home/jane/fanypdcollection/' to the paths in Pd's
> preferences. Then she installs iemnet to
> /home/jane/fancypdcollection/iemnet after she configured Deken to
> install libraries to /home/jane/fanypdcollection/. Then she creates a
> new patch, therein a [declare -path iemnet] and a [tcpclient] and the
> latter creates successfully.
> 
> Is this the idea?


Yup, with the PR. I'd suggest making a custom build with it and testing 
(please).

Additionally, if iemnet is located in the same folder as the opening patch, it 
would be chosen first over the global location. Also, you can specifically 
*ignore* searching beyond the local scope by adding a ./ in the front of the 
path. :)


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Antoine Rousseau]

>
> Is this the idea?
>
> I think so; anyway, I personally agree with this.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Alexandre Torres Porres]

2018-06-14 15:35 GMT-03:00 Roman Haefeli :

>
> Is this the idea?
>

Yes! And it's working like that in my tests.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Roman Haefeli]

On Thu, 2018-06-14 at 14:18 -0300, Alexandre Torres Porres wrote:
> > Now, I'm going to load mylib with [declare -{std}path mylib] in my
> > patch which fails. What am I missing here?
> 
> Yes, there's the declare issue we know and are addressing, but I'd
> also like to highlight that Deken also asks if you want to add what
> you downloaded to the search path. This intentionally provided a
> working solution to this issue at the time of the release, making it
> all just work by clicking "yes" to stuff, which is quite fine for
> newcomers.  

OK. Just to be sure we are on the same page, I understand that the
following assumptions will be true, once the PRs are accepted:

 * The user defines the environment. The user can define in the pre-
   ferences in which paths [declare] looks for libraries.

 * Patches can use [declare] to load libraries, regardless where they
   are installed as long as the install path was added as searchpath
   in the preferences

 * Patches don't need to know anything about the environment.


Example:


User adds '/home/jane/fanypdcollection/' to the paths in Pd's
preferences. Then she installs iemnet to
/home/jane/fancypdcollection/iemnet after she configured Deken to
install libraries to /home/jane/fanypdcollection/. Then she creates a
new patch, therein a [declare -path iemnet] and a [tcpclient] and the
latter creates successfully.

Is this the idea?

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Alexandre Torres Porres]

2018-06-14 4:52 GMT-03:00 Roman Haefeli :
>
> Does Pd now look into extra's subfolders?


If I got it right, the deal is that Pd always searches in "extra" (but not
subfolders), so if you have a bunch of things in "extra", the thing is
they're always in the search way, so it can be a good idea to keep it as
clear as possible.

My beef with it is that - the way it is presented to me -  it suggests to
> do things that create confusion later.  As a new user: "Do you want to
> create ~/Documents/Pd"?
>
> Yes
>
> "Do you want to add it to the searchpaths?"
>
> Yes
>

It's just one question, the first one, but it does add it to the search
path as well.


> When downloading stuff with deken: "Do you want to install 'mylib' to
> ~/Documents/Pd?"
>
> Yes
>
> Now, I'm going to load mylib with [declare -{std}path mylib] in my patch
> which fails. What am I missing here?
>

Yes, there's the declare issue we know and are addressing, but I'd also
like to highlight that Deken also asks if you want to add what you
downloaded to the search path. This intentionally provided a working
solution to this issue at the time of the release, making it all just work
by clicking "yes" to stuff, which is quite fine for newcomers.

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Dan Wilcox]

> On Jun 14, 2018, at 10:21 AM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Roman Haefeli mailto:reduz...@gmail.com>>
> To: Pd-List mailto:pd-list@lists.iem.at>>
> Subject: Re: [PD] standard paths for externals
> Message-ID: <0b50bb13c24e850d65000e980526f8234a138f61.ca...@gmail.com 
> <mailto:0b50bb13c24e850d65000e980526f8234a138f61.ca...@gmail.com>>
> Content-Type: text/plain; charset="utf-8"
> 
> Hey Dan
> 
> Thanks for trying to explain.
> 
> On Thu, 2018-06-14 at 01:18 +0200, Dan Wilcox wrote:
>> There seems to be a bit of FUD in this "discussion."
> 
> Maybe things aren't that bad as they were presented. For my part, I
> lost track of who favors what kind of design.
> 
>> Some things from my perspective:
>> 
>> 1. Pd's library/path mechanism is largely oriented toward *local*
>> libs first and *global* ones later, ie. download externals to
>> individual project (sub)folders.
> 
> Pd already used to work like that for quite a while, no?
> 
>> I believe the centralized loading was added later on in Pd-extended. 
> 
> I don't understand what you mean by that. Pd-extended already pre-
> loaded a subset of the installed externals (do you mean this?), which -
> imho - was a bad design choice. It meant there was one person deciding
> what comes pre-loaded and what not.

Yes and continuing that mechanism by installing things into more "standard 
places" is perhaps less ideal, even if it is easy, ie. ~/Library/Pd.

>> If we follow the "programming language model", this might be similar
>> to installing a Python egg locally or globally. I don't see how
>> supporting both modes of working is a problem.
> 
> Me neither.
> 
>> 2. IOhannes convinced me, over time, that the "stdpath" loading
>> mechanism used by the "extra" folder is problematic as it adds too
>> many (sub) search paths by default and it becomes harder to
>> tell/control what's being loaded.
> 
> Forgive my ignorance, but I don't understand. Does Pd now look into
> extra's subfolders? Currently I still have to actively load stuff with
> [declare -stdlib] or [declare -stdpath]. 

It always has, that's one of the "standard paths" aka those that [decalre's 
-stdpath] uses. These are different from the "user search paths" which are 
those  specified in the Path dialog and/or via [declare -path]. Similarly, 
[declare -stdlib] search for lib names *only* in the "standard paths" while 
[decalre -lib] looks only in supplied "user search paths". This is where great 
confusion comes and arguments over what is a path and how things should/can be 
searched.

Our utltimate solution is to move to dis-favor the separation and simply have 
[declare -path] and [dlecare -lib] search both the "standard paths" and the 
"user search paths", first locally, then the "suer paths", and finally the more 
global "standard paths".

>> The "better way" is for people to specify those externals paths
>> directly, either with the user search paths and/or declare.
>> There is much less ambiguity as to what's going on at the loss of
>> "just put things in this place" ease.
> 
> So paths added by the users will be searched by deken? So  instead of
> specifying paths to the library root - as we currently do it - adding a
> path in the future means adding a searchpath that is container for many
> libraries? And deken will find libraries inside the newly added
> searchpath root? 

By deken, do you mean [declare]?

Deken is unrelated to path searching, all it does is download things to a 
place, either the ~/Documents/Pd/externals directory or some other places 
specified by you.



> 
>> 3. As suggested by Alexandre, I wrote a PR to help address how
>> declare search when using -path & -lib by having them search along
>> user search paths as well: https://github.com/pure-data/pure- 
>> <https://github.com/pure-data/pure->
>> data/pull/205. I feel this is a much closer method of using declare
>> to how other programming languages handle such things, ie. Lua's
>> require.
> 
> OK, I hopefully understand now. Am I right in thinking that declare's
> -stdlib, -stdpath flags are considered superfluous because -lib and
> -path will scan all searchpaths in a local -> global order, including
> the parent patch's folder?

That's the general idea. As I mention before, it's hard to tell which to use 
since people tend to put things in different places and, as you mention in a 
previous email, where is the "right" place to put things. I think the "right 
place" should be wherever you want a

Re: [PD] standard paths for externals

[Alexandre Torres Porres]

2018-06-13 20:18 GMT-03:00 Dan Wilcox :

> 2. IOhannes convinced me, over time, that the "stdpath" loading mechanism
> used by the "extra" folder is problematic as it adds too many (sub) search
> paths by default and it becomes harder to tell/control what's being loaded.
>

hmm, I see...


> The "better way" is for people to specify those externals paths directly,
> either with the user search paths and/or declare. There is much less
> ambiguity as to what's going on at the loss of "just put things in this
> place" ease.
>

But now we have a folder like ~/Documents/Pd that Pd suggests you to use,
and then it creates it for you, and also creates ~/Documents/Pd/externals,
and Deken puts thins in there for you... So, where I'm getting at is that this
new process provides exactly that "*just put things in this place*" kind of
ease, and therefore *no* loss - plus, we also have less ambiguity and avoid
a problematic Ioading mechanism. In short, looks like a "win-win"
situation...

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Dan Wilcox]

There seems to be a bit of FUD in this "discussion."

Some things from my perspective:

1. Pd's library/path mechanism is largely oriented toward *local* libs first 
and *global* ones later, ie. download externals to individual project 
(sub)folders. I believe the centralized loading was added later on in 
Pd-extended. If we follow the "programming language model", this might be 
similar to installing a Python egg locally or globally. I don't see how 
supporting both modes of working is a problem.

2. IOhannes convinced me, over time, that the "stdpath" loading mechanism used 
by the "extra" folder is problematic as it adds too many (sub) search paths by 
default and it becomes harder to tell/control what's being loaded. The "better 
way" is for people to specify those externals paths directly, either with the 
user search paths and/or declare. There is much less ambiguity as to what's 
going on at the loss of "just put things in this place" ease.

3. As suggested by Alexandre, I wrote a PR to help address how declare search 
when using -path & -lib by having them search along user search paths as well: 
https://github.com/pure-data/pure-data/pull/205 
. I feel this is a much closer 
method of using declare to how other programming languages handle such things, 
ie. Lua's require.

4. The Pd Documents path (aka ~/Documents/Pd) is simply a helper location for 
beginners. It is only a regular user search path added by default (when 
desired) and does not search subfolders. Nobody has to use it and it can be 
disabled at any time.

5. Yes, the macOS hiding the ~/Library folder is problematic for many users as 
they don't know how to show it and are afraid to modify things within it. I've 
recently taught classes to beginners that are just learn gin the concept of a 
"file system" as they grew up mainly using "mobile phones" ... Plus, 
~/Library/Pd was also a "kitchen sink" std path with the issues listed in #2.

6. I've attempted to provide some solutions to various issues outlined over the 
last year regarding [declare] and folders. It would be helpful to get more 
feedback earlier on in testing / experimentation, rather well after a release. 
OTOH if I attempted to do work for free on Pd that pleased *everyone*, I 
suppose I wouldn't bother.

(7. Code talks.)


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Alexandre Torres Porres]

2018-06-13 14:20 GMT-03:00 Christof Ressi :

> basically, I agree with Alexandre. To sum it up quickly from my point of
> view:
>
> 1) "-path" in [declare] should apply to *all* paths - including the user
> defined paths.
> 2) "-stdpath" and "-stdlib" should be deprecated and just become aliases
> to "-path" and "-lib"
>

Well, I mentioned about a pull request that was fixing [declare]. Here it
is: https://github.com/pure-data/pure-data/pull/205

And in fact it does all of that you just asked for. If I use [declare -path
else] I can get it to search for the else folder inside "extra". By the
way, it is already working like that for [declare -lib]. Check it out
yourself if you haven't.

this way we would have a unified way of dealing with paths which would be
> less confusing. does anyone see possible issues with that?
>

I don't think anyone has searched for more issues than me when this new way
of handling externals was proposed by Dan. I was very conservative! But
then Miller said we could just get the path mechanism and [declare] to
behave as people wanted, and I couldn't really find any issue with that.

Of course we still needed to do stuff in order for that to happen. But this
fix for [declare] was actually the only thing I found in the way of the new
process. I just couldn't find anything else...

And responding to your question, I can't see any issue with the fix from
the Pull Request. It has no backwards compatibility issues, it makes
perfect sense, it simplify things dramatically and it integrates pretty
well with the new process for Pd.

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Christof Ressi]

basically, I agree with Alexandre. To sum it up quickly from my point of view:

 

1) "-path" in [declare] should apply to *all* paths - including the user defined paths.

2) "-stdpath" and "-stdlib" should be deprecated and just become aliases to "-path" and "-lib"

 

this way we would have a unified way of dealing with paths which would be less confusing. does anyone see possible issues with that?

 

Christof

 

Gesendet: Mittwoch, 13. Juni 2018 um 17:13 Uhr
Von: "Alexandre Torres Porres" 
An: "Roman Haefeli" 
Cc: Pd-List 
Betreff: Re: [PD] standard paths for externals


 
 
2018-06-13 4:18 GMT-03:00 Roman Haefeli <reduz...@gmail.com>:


I seem to disagree in almost everything you say.

 

I didnt say anything, I'm quoting someone else...

 

Your proposal has two - imho: major - drawbacks.

 

It's not my proposal, I'm not proposing anything...

 

By putting libraries
anywhere (outside any searchpath) and loading them per preferences, you
loose the ability to 'activate' libraries on the fly from the patch
with [declare]

 

Like I said, there is a Pull Request that already fixes this. And I'm the one who reported that issue, by the way, so I know about it.

 

I don't see a good reason to proactively work against this as you seem to
do.

 

again, this is not me, not my proposal, so I'm not doing anything...

 

In my understanding, the user should just know what libraries to
download and the rest is done by the patch by using the right
[declare}s. Also, by preventing [declare] from working - as you propose

 

It's funny how you keep putting this on my bill as my proposal. I dont know where you got the idea Im proposing that... all I said is that things are going this way now, and there might still be issues as with declare, but it'll be fixed in the next release. This is not a matter of opinion, not a proposal, just reporting facts here.

 

> > there's a deep rift between the factions.
>
> Ok, I don't know about that

Now you know.

 

All I know is that you're reporting a bug that has a Pull request that already fixes it. And by the way, it already works like that if you want to load libraries like cyclone, zexy, Gem. The issue is only with adding a path to declare. I, for one, just do not use [declare], and can live pretty well without it, really.

Deken has made it painless to download and add a path for you. I get it if you like [declare] and want to use it so maybe don't do this way right now. But you can live without it if you wanted. There are ways to manage dependencies and everything. All this argument seem to imply [declare] is the only possible mechanism to deal with importing libraries. It is not.

 

By 'new way' you mean that libraries should be installed anywhere and
added to the preferences?

 

yes, add it to the path, that is what Miller said in that message and all discussions prior to 0.48 went in this direction where we don't want people to install libraries to "Standard Paths", just into user added paths. Again, for the 1000th time, that wasn't my proposal, I actually argued against it, using the very same argument that [declare] wouldn't work well, but the idea is now to just fix that...

 

So yeah, I'm now cool with it...

 

It appears to me that you created this mess by requesting that  ~/Library/Pd should be replaced by ~/Documents/Pd (in macOS, at least).



I don't have the power to change Pd. And I didn't create any "mess" because I didn't propose a change to not use "standard paths" as you didn't like.

 

Yes, I proposed a new standard path change, but the outcome was that Miller and Dan felt users shouldn't use "standard paths", like I said before.

 


I couldn't care less about macOS, but in my opinion the fact that you need to hit Shift-Cmd-G to
graphically visit this folder doesn't warrant this change in Pd.

 

That is not what happened. Pd didn't change because of Apple... at all. 

 

Why does the user need to check that folder anyway, since
Deken already manages it quite well?

 

It actually doesn't, you still need to access folders to do simple things like removing an older version of a library before installing a new one. But again, you're not getting the real issue. None of this came up because of apple, or because deken is not perfect yet. It is only a matter of not wanting people to install libraries in "Standard Path" in the first and only place. Don't try to find other reason that that. That is it.

 

If you have an issue with that besides the bug that is already being fixed. Please bring it to the table.

 

sorry for saying it directly - which you are at least partially responsible for.

 

wow, I didn't realize when you mentioned a million times before I had responsibility for this :) thanks for being direct.

 

I hope you realize though I had zero responsibility (not even partial) as. I never proposed

Re: [PD] standard paths for externals

[Alexandre Torres Porres]

2018-06-13 4:18 GMT-03:00 Roman Haefeli :

>
> I seem to disagree in almost everything you say.
>

I didnt say anything, I'm quoting someone else...


> Your proposal has two - imho: major - drawbacks.


It's not my proposal, I'm not proposing anything...


> By putting libraries
> anywhere (outside any searchpath) and loading them per preferences, you
> loose the ability to 'activate' libraries on the fly from the patch
> with [declare]


Like I said, there is a Pull Request that already fixes this. And I'm the
one who reported that issue, by the way, so I know about it.


> I don't see a good reason to proactively work against this as you seem to
> do.


again, this is not me, not my proposal, so I'm not doing anything...


> In my understanding, the user should just know what libraries to
> download and the rest is done by the patch by using the right
> [declare}s. Also, by preventing [declare] from working - as you propose
>

It's funny how you keep putting this on my bill as my proposal. I dont know
where you got the idea Im proposing that... all I said is that things are
going this way now, and there might still be issues as with declare, but
it'll be fixed in the next release. This is not a matter of opinion, not a
proposal, just reporting facts here.


> > > there's a deep rift between the factions.
> >
> > Ok, I don't know about that
>
> Now you know.
>

All I know is that you're reporting a bug that has a Pull request that
already fixes it. And by the way, it already works like that if you want to
load libraries like cyclone, zexy, Gem. The issue is only with adding a
path to declare. I, for one, just do not use [declare], and can live pretty
well without it, really.

Deken has made it painless to download and add a path for you. I get it if
you like [declare] and want to use it so maybe don't do this way right now.
But you can live without it if you wanted. There are ways to manage
dependencies and everything. All this argument seem to imply [declare] is
the only possible mechanism to deal with importing libraries. It is not.


> By 'new way' you mean that libraries should be installed anywhere and
> added to the preferences?


yes, add it to the path, that is what Miller said in that message and all
discussions prior to 0.48 went in this direction where we don't want people
to install libraries to "Standard Paths", just into user added paths.
Again, for the 1000th time, that wasn't my proposal, I actually argued
against it, using the very same argument that [declare] wouldn't work well,
but the idea is now to just fix that...

So yeah, I'm now cool with it...


> It appears to me that you created this mess by requesting that
> ~/Library/Pd should be replaced by ~/Documents/Pd (in macOS, at least).


I don't have the power to change Pd. And I didn't create any "mess" because
I didn't propose a change to not use "standard paths" as you didn't like.

Yes, I proposed a new standard path change, but the outcome was that Miller
and Dan felt users shouldn't use "standard paths", like I said before.


> I couldn't care less about macOS, but in my opinion the fact that you need
> to hit Shift-Cmd-G to
> graphically visit this folder doesn't warrant this change in Pd.


That is not what happened. Pd didn't change because of Apple... at all.

Why does the user need to check that folder anyway, since
> Deken already manages it quite well?


It actually doesn't, you still need to access folders to do simple things
like removing an older version of a library before installing a new one.
But again, you're not getting the real issue. None of this came up because
of apple, or because deken is not perfect yet. It is only a matter of not
wanting people to install libraries in "Standard Path" in the first and
only place. Don't try to find other reason that that. That is it.

If you have an issue with that besides the bug that is already being fixed.
Please bring it to the table.

sorry for saying it directly - which you are at least partially responsible
> for.
>

wow, I didn't realize when you mentioned a million times before I had
responsibility for this :) thanks for being direct.

I hope you realize though I had zero responsibility (not even partial) as.
I never proposed any of this and, in fact, like I said in the first
message, I had opposed myself.

Sorry to repeat myself over and over. But it seems it was necessary to make
a point I'm not your target.

Cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[IOhannes m zmoelnig]

On 2018-06-12 12:10, Max wrote:
> I'm looking for the canonical paths to install externals for the
> different platforms and only can find information which seems to be
> outdated, like here:
> 
> http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files

why do you think it is outdated?

> At least deken seems to install into ~/Documents/Pd/externals instead.
no. that's only half-true.
deken uses a configured install path or - as a fallback - the first
available (and writable) sys_search path.
when *you* clicked on "yes, please create a ~/Documents/Pd/ folder for
me where i want to put all the externals into" at the "first" startup of
Pd, you implicitely created ~/Documents/Pd/externals/ and added it to
deken's install path.

however, apart from this (missing) new-fangled path which seems to not
integrate that well with Pd's search in the first place, everything you
found on the how-do-i-install-exernals-and-help-files FAQ is correct.

> There has been discussions about this frequently, but I can't seem to
> find the results of it. Was there something which was agreed upon?

nothing.
there's a deep rift between the factions.

> 
> For which paths should an installer (ore make install) of an external
> look for?

in general i tend to use the pd-lib-builder Makefile as a reference for
such things any such things (it's a bit less conservative than myself,
without falling for each and every bel-de-jour).

btw, you should really consider using pd-lib-builder Makefile as the
buildsystem for all externals.

fgasdrmn
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list