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

[Alexandre Torres Porres]

Good thoughts indeed Derek, which also points me to more details I could
deal with in this documentation, thanks. So, we agree it's the "normal way"
and I also agree things can still be improved, but we could discuss that in
a different thread, like I said ;)

2017-07-28 12:18 GMT-03:00 me.grimm <megrimm at gmail.com>:

> >> 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/li
>> stinfo/pd-list
>>
>
>
>
> --
> ____________________
> m.e.grimm, m.f.a, ed.m.
> syracuse u., tc3
> megrimm.net
> ____________________
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170728/5ca0f73e/attachment-0001.html>