On Tue, 2018-06-12 at 16:16 -0300, Alexandre Torres Porres wrote:
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.
I seem to disagree in almost everything you say.
I tell people to do exactly the opposite of what you're telling them. Your proposal has two - imho: major - drawbacks. 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] since they are already loaded anyway. By doing it this way, you require the user to modify their environment in order for them to run a certain patch. In my understanding of programming environments, the software imports/declares its own dependencies. The dependencies need to be installed, but the actual loading happens from within the software. I guess that is common quite common practice. I don't see a good reason to proactively work against this as you seem to do. 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
- how is a patch dev supposed to document the patch's dependencies?
What you suggest just simply doesn't add up for me.
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
Now you know.
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,
By 'new way' you mean that libraries should be installed anywhere and added to the preferences? It appears to me that you created this mess by requesting that ~/Library/Pd should be replaced by ~/Documents/Pd (in macOS, at least). Now, Deken asks to create this folder that is of no practical use. This proposal probably got triggered by the fact that Apple decided to hide ~/Library from Finder. 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. Yeah, it was stupid move by Apple, but shouldn't every macOS user know how to visit invisible folders anyway? Does the Pd community have to care about that? Why does the user need to check that folder anyway, since Deken already manages it quite well? Now there is a new folder which is not a standard path and just creates mess and confusion and pages long discussions in github issues and - sorry for saying it directly - which you are at least partially responsible for.
Roman