[PD] standard paths for externals

Christof Ressi christof.ressi at gmx.at
Thu Jun 14 10:21:48 CEST 2018


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

because Pd didn't create any folder by default for installing libraries (unlike most other programs). rather than creating the folder in one of those awkward user paths (btw, in Windows it's something like C:\Users\Christof\AppData\Roaming\Pd - of course it's hidden), we offer the user a folder they can easily access, following the Arduino model.

> Yes
> 
> Now, I'm going to load mylib with [declare -{std}path mylib] in my
> patch which fails.
> 
> What am I missing here?

because right now [declare] doesn't work with user specified paths (yet). Dan's PR attempts to fix this.


> Gesendet: Donnerstag, 14. Juni 2018 um 09:52 Uhr
> Von: "Roman Haefeli" <reduzent at gmail.com>
> An: Pd-List <pd-list at lists.iem.at>
> Betreff: Re: [PD] standard paths for externals
>
> 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_______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
> 



More information about the Pd-list mailing list