[PD] Standard Paths & Canonical practice for managing/installing externals

[me.grimm]

>> the pros of using standard paths for externals are their
>>functionality with the Pd browser, and simplifying pathing,

good thoughts...

>>simplify the Pd experience

especially this

+1

On Fri, Jul 28, 2017 at 2:12 AM, Derek Kwan <derek.x.kwan at gmail.com> wrote:

> Alexandre Torres Porres <porres at gmail.com> writes:
>
> > My view is reinforced by [declare]'s object design, which loads
> > externals/libs from there with the -stdpath & -stdlib flags. Who
> > agrees/disagrees? and if standard paths* are not good for externals,
> > what they good for?
>
> Some random, scattered thoughts on the topic:
>
> I think there are many issues that arise with the use of standard paths
> although I would advocate for their use with library management and the
> use of standard paths seems to be prevalent across other creative coding
> platforms and programming language enviornments.
>
> In a sense, I suppose standard paths could be seen as less transparent
> since the object binaries and abstractions aren't in the immediate
> vicinity of the patches worked on. And with Pd-extended, a lot of people
> assumed that objects were just there as part of the typical Pd install
> and so people need to be helped out with what libraries are, where and
> how to install them, etc. I think this a lot of this stuff is solved
> with Deken by automating the whole process and also by people like
> myself and Alex who have writted thorough documentation of how the whole
> thing works. I'd agree that the concept is just yet another thing to
> teach/learn when getting accustomed to Pd and perhaps very casual users
> don't need to understand the concept of standard paths and how they
> work, but I don't the concept is so heady as to not be teachable in a
> relatively concise manner to new users and it's a concept that carries
> over to situations outside of Pd.
>
> Additionally, the use of standard paths brings up issues of libraries
> "locally" installed in specific project folders vs "globally" installed
> in a user's folder (and furthermore, "globally" installed in system
> folders outside of a user's folder). In this case, I'd propose perhaps
> some sort of hierarchy where local installs take precedence over user
> global installs which take precedence over system global
> installs. Perhaps this may be easier said than done due to how libraries
> are loaded at start-up and the scopes of different Pd windows being
> open, and what to do when they're closed or switched, what to do with
> the Pd browser,... but at least as an end user, this hierarchy seems to
> make the most sense to me.
>
> Standard paths interacting with the Pd browser can be kinda messy. For
> objects to show up in the browser, they need a help file (and here I'd
> propose perhaps allowing abstraction patches, ie patches that don't end
> in -help.pd, to appear as well since sometimes they are documented well
> enough not to need help patches). And even with navigating the Pd
> browser, the functionality of objects is unclear since there's no
> description field (but I think I'm getting off-track here
> haha). Double-loading libraries means they show up twice in the Pd
> browser (I suppose I don't really see a good way around this).
>
> Anyways, the pros of using standard paths for externals are their
> functionality with the Pd browser, and simplifying pathing, and well,
> having standard paths between different patcher windows, which simplify
> the Pd experience, especially when not using a saved patch in a specific
> project folder but rather a new patch.
>
> Derek
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>



-- 
____________________
m.e.grimm, m.f.a, ed.m.
syracuse u., tc3
megrimm.net
____________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170728/5f932b72/attachment.html>