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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
