[PD] standard paths for externals

Roman Haefeli reduzent at gmail.com
Thu Jun 14 09:52:41 CEST 2018


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.

> 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]. 

>  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? 

> 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.

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?

> 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. 

Now you challenge my understanding of the term searchpath again. I
thought the new idea is that you will be able to load libraries with
[declare] from user-added searchpaths? What's the point of creating
that folder then? 

> Nobody has to use it and it can be disabled at any time.

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

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?


> 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"

I don't see how deken requires users to have a notion about a
filesystem. Ideally, I'd use deken to tell _what_ I want to install.
Ideally, I'd tell my patch through [declare] _what_ to load. All the
_where_ stuff shouldn't be a question neither at installing nor loading
time. The _where_ stuff should only matter when the user tweaks their
environment: "I'd rather put my 4.5 TB of Pd externals on my external
drive ". 

>  ... 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. 

Valid and important point. I will try to the get a more clear picture
from the actual implementation instead of a messy Pd list thread.

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/20180614/41d12093/attachment.sig>


More information about the Pd-list mailing list