2018-06-12 8:00 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:

why do you think it is outdated?

I think cause it doesn't say about the new way of doing things since 0.48.

everything you found on the how-do-i-install-exernals-and-help-files FAQ is correct.

Well, recent discussions seem to have at least challenged this entry. Specially Miller and Dan felt it wasn't the right approach or the way to do things.

The FAQ basically describes three different "Standard Paths" (paths automatically searched for things) for Pd. They are the app specific ("extra" folder), local and global path. Although Pd has these 3 locations hard coded as "Standard Paths", there seems to be a conflict/inconsistency in what "Standard Path" is or should be, and that the local and global path shouldn't really exist. I say that because:

*A)* Pure Data, up to this day, does come with or create the local/global folder, so the user has to go for it. *B)* The local/global folder are never mentioned in Pd Vanilla's documentation. And in fact, only the "extra" folder is described as a "Standard Path" in Pd Vanilla's manual, and - see http://msp.ucsd.edu/Pd_documentation/x3.htm#s5 for reference *C)* Miller stated that "Standard Path" was always meant to refer to what comes with Pd - that is, of course, things in the "extra" folder, and not the other folders which don't come with Pd (see "A") and are not even documented (see "B"). Here's the reference: https://lists.puredata.info/pipermail/pd-list/2017-07/119839.html

Now, regarding "A)", I know Pd Extended did create at least the "local" folder, for macOS. So this seems to have been something well integrated in Pd Extended. Hence, I wonder if these two other paths (local/global) got into Vanilla from Extended's influence without Miller noticing it - as it'd explain them not being documented in Pd's manual, not being provided by the software and Miller stating he never meant those folders to be "Standard Paths". Perhaps someone here can tell me more about how this got into Pd.

But that is a parallel discussion. What's more relevant is that, influenced by this FAQ entry, I proposed a different/better folder for macOS. Well, to my surprise, all this idea I got about that FAQ entry being the canonical way of doing things just fell apart, and Miller/Dan went for another approach that kinda ignores this FAQ entry, which is the new way since 0,48 (here's a long discussion for reference https://github.com/pure-data/pure-data/pull/139).

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?

Well, there has definitely been results in the design of Pd that came out of recent discussions. Let me point again to what Miller said in https://lists.puredata.info/pipermail/pd-list/2017-07/119839.html to highlight the notion that we should not use "Standard Path" to install externals, and this is regardless if there is one or more of them, and if there should be only one... it doesn't matter, just don't use them.

As Miller said in that message, we should just use the "Path" mechanism, and no Standard Paths. This means just have your externals anywhere and put them in "Preferences => Path" if you want them to be automatically loaded. Now, this may not yet be 100% fully well integrated with Pd, I don't know what IOhannes meant by that, but I can say that if you want to use [declare] instead of doing this, it won't work well, but there's already a Pull Request that fixes it. So whatever is not perfect yet with the new system should be fixed soon.

there's a deep rift between the factions.

Ok, I don't know about that, and I haven't seen one. By the way, let me just make it clear that I do not have a dog in this fight, I'm just going with the flow without disputing anything. Yeah, I actually first opposed to the new way of doing things since 0.48, as I was influenced by that FAQ entry and worried about a good integration to Pd's mechanism, so I argued on it. But once things went the way they did, I'm embracing it and thought that was the new consensus. And speaking as someone that had lots of resistance to the new approach in the beginning, I don't see any real issues now. If you or anyone else have issues, let's put them on the table and work on them.

One way or another, I just hope that aren't rifts and that such challenging notions get sorted out. I say that because I want to write a new documentation on how to install externals nowadays, and there still seems to be lots of confusion in the air, which gets in the way of writing a clear documentation, and prevents the development of a text that would make things more objective and clear to everyone. This thread is a very good example on how even advanced users are still confused about all this, so we should do something about it. I think it's very important. If advanced users are confused, imagine newcomers...

cheers

2018-06-13 4:18 GMT-03:00 Roman Haefeli reduzent@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 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

2018-06-13 14:20 GMT-03:00 Christof Ressi christof.ressi@gmx.at:

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