Remove additional "standard paths" in conflict with Pd's documentation #321
Conversation
|
Related to this Pull Request is #320 - where it now prompts the user to add these folders, which aren't created by Pd. This adds yet more noise to the system, but by removing these extra standard paths, deken won't prompt you to create these folders anymore. |
|
And by the way, any special usage we had for additional standard paths have been made obsolete with this Pull Request and the ability of [declare] just search anywhere #205 |
There was a problem hiding this comment.
So this PR just removes ~/.local/lib/pd/extra/ (on linux; on macOS it removes ~/Library/Pd and on W32 it removes %AppData%\Pd).
i think this is a regression, as it violates the expectation that a plugin-aware application has a standard user-specific installation path for plugins. just like other applications (e.g. firefox) do it and how it is codified in (for linux) in the XDG specs (cf. #414)
if the documentation is confusing, please fix the documentation.
PR #205 addresses the actual problem (by providing a unified interface to adding relative search-paths).
if #205 gets applied, I don't see any advantage in removing built-in search paths (in Pd<0.47 there was an issue with load-speed penalty with more search-paths; this is practically gone).
so i'd vote to accept #205 instead of this.
| @@ -259,7 +259,7 @@ void sys_setextrapath(const char *p) | |||
| sys_expandpath("%CommonProgramFiles%/Pd", pathbuf, MAXPDSTRING); | |||
| STUFF->st_staticpath = namelist_append(STUFF->st_staticpath, pathbuf, 0); | |||
| #endif | |||
| /* add built-in "extra" path last so its checked last */ | |||
| */ | |||
| STUFF->st_staticpath = namelist_append(STUFF->st_staticpath, p, 0); | |||
There was a problem hiding this comment.
if you want to get rid of code, remove it, rather than commenting it out (and having to remove useful (explanatory) comments because C-comments don't stack).
Hi, the issue I raised is that we seem to have a conflict of what "standard paths" are. The solutions I see is either: 1) remove these extra ones as this PR suggests; or 2) fix the documentation with a better understanding of what "standard paths" are and should be. I don't see how the PR #205 deals with that.
What I see and already brought up is that - if PR #205 gets accepted - I don't see any special functionality or reason for these extra folders to exist anymore. And besides not seeing advantages in keeping it, the "advantage" or idea behind removing is to solve the issue I raised, making things less confusing and without conflict. But then again, what we could do instead is work on the documentation and explain what's the special functionality for this, why wee need it, how we use it. I'd be happy to work on such documentation update, and in fact even provide an extensive manual on how to manage externals in Pd. But as it is right now, I just wouldn't really know what to say about this other than (again, if #205 gets it) it has no having advantage and is just some kind of garbage - of course this is just my understanding and I could be missing something... |
|
Since #205 is now in, is this PR still relevant? I agree that it would be cleaner to also remove the older functionality but, in most cases, it doesn't really hurt anything to leave it for legacy support. Pd is not known for dropping entire bits of functionality quickly and someone may rely on it for some obscure reason on some obscure system... |
danomatika
added
the
wontfix
My point is that it becomes relevant with #205 Though I get the point that, if anything, we could at least phase out and not just drop it.
it's good we reach a consensus about this, cause now my focus is on writing a new and proper documentation for managing externals. If we agree this is not pertinent to current functionality I can address the existence of this as Legacy / Obsolete |
|
i fail to see how this is legacy/obsolete. compare (personally i would be happy to remove the non-standard |
|
I'm actually fixing this now by revising Pd's documentation! |
|
new information has been added in 8e7fae6 - but I'll still revise it and bring it again to the pd-list for further discussion and revision |
This is a reboot of #183
I just commented out additional "standard paths" that are not the "extra" folder. There's a long discussion that led to this proposal of mine in an earlier Pull Request that got rejected - see #139
I wanted to add a better additional "standard path" than what we had (~/Documents/Pd besides ~/Library). As I understand, the rejection came from the notion that "Standard Path" should only refer to the "extra" folder and not anything else, but somehow these additional paths are here. Pd's manual actually makes it clear that the "standard path" is only the "extra" folder, and teaches you how to use the Path mechanism to add other "paths" to Pd and says nothing about these folders.
From the discussion in that earlier Pull Request, the ~/Documents/Pd folder has actually been included as a conventional location for externals, but not as a "Standard Path", reinforcing the notion that we should not have another "Standard Path" other than the "extra" folder.
Thus, in order to avoid confusion and better sort Pd's path mechanism, I propose we get rid of these additional "Standard Paths" that are not even mentioned in Pd's manual and in fact present themselves in a conflicting matter to Pd's Manual and all the reasoning behind earlier discussions that did not lead to add yet another "Standard Path" location.