[PD] standard paths for externals

Roman Haefeli reduzent at gmail.com
Wed Jun 13 09:18:46 CEST 2018


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180613/c61b0a46/attachment.sig>


More information about the Pd-list mailing list