Alexandre Torres Porres porres@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