suggestion: make [declare -path] also search user added paths

[porres]

This is an issue that relates to other Pull requests and parallel discussions, like: #183

In short, some of us were used to relying on "additional standard paths" for managing externals, but @millerpuckette points out (and I quote) "the way forward is to somehow get the "path" mechanism to do what people are asking for." see full message at: https://lists.puredata.info/pipermail/pd-list/2017-07/119839.html

Regarding that, there is a user case related to [declare] if you use "standard paths" and the -stdlib and -stdpath flags that I hope we can achieve with the -lib and -path flags as well.

Say you have externals elsewhere than Standard Paths (which should only be the "extra" folder, according to Pd's manual). The idea is that you have to add them to pd's Path, but if you wanna use [declare], you can only use relative or absolute paths, which I think are much more complicated to manage. So we could make the "-path" flag also search and find subdirectories in user added paths.

Let me illustrate. If I have cyclone in a standard path, I can keep the search path empty and just use declare to call it. This seems to be what Miller suggests it's a good practice in #152 (comment) - and I agree it's a nice one, but we need an enhancement to [declare] so it really works.

See the picture below: search path is empty, and declare is being used to load cyclone with the "-stdpath" flag.

So, now we do not want to mess with standard paths no more, and we can put it in a different folder, such as ~/Documents/Pd/externals - if I have cyclone in there, I cannot use [declare] in a simple way like this:

Unless I do an absolute path, and that is much more complicated than before with standard paths. But if [declare -path] also searches in the added search paths, this would happen.

cheers

[Spacechild1]

[declare -path] is explicitly meant for patch relative searching - for example to load a specific version of a library bundled in a project. if [declare -path] would look also in user-paths, this could create many problems and defeats some of the purpose of -path.
I think it would make more sense to add this behaviour to [declare -stdpath] since both standard paths and user paths are currently used for the same purposes - at least I can't see any conflicts. or add another set of flags to [declare]?

[porres]

I think it would make more sense to add this behaviour to [declare -stdpath] since both standard paths and user paths are currently used for the same purposes

it would be confusing, as "standard path" is meant to be something specific (the "extra" folder, and only that).

So if this screws things up, maybe the way out is another flag, but that seems confusing and complex - I don't know what to suggest in that case

[Spacechild1]

it would be confusing, as "standard path" is meant to be something soecific (the "extra" folder, and only that).

in theory yes. but in practice, -stdpath also includes some OS specific folders (I don't have to tell you that :-)). I don't really see how the standard paths and user paths differ in the actual usage... but I'm not sure as well...

[porres]

in practice, -stdpath also includes some OS specific folders (I don't have to tell you that :-))

yeah, you don't need to :) and (as I've been pointing elsewhere) I see it as an issue to be dealt with. In theory, the standard path should only be "extra" as it is said so in the manual, and it is also what Miller recently manifested... so... I don't know how these additional ones ended up there, and even if you count them as "standard paths", they would still be a separate concept than a "path". Mentioning them doesn't make things less confusing, but even more confusing.

Like:

• If there's no difference between a standard path and a regular path, why call it a "standard path"?
• Or are we to change completely the notion and definition of "standard path"? Like, now "standard path" is what any user added path is...

See? Really confusing...

I don't really see how the standard paths and user paths differ in the actual usage... but I'm not sure as well...

Maybe it's because this is still very confusing and not documented in Pd... a source of lots of noise... and I'm trying to clean this up so we can get over this chaos.

Standard Path is a standard location for Pd to search for things automatically. Thus, it doesn't need to be added to the path's preferences. In the case of [declare], -stdpath and -stdlib refer to search for things in the standard path and not the "other paths" Pd will search for - which would be user added paths, relative paths and even absolute paths.

So far, [declare -path] is only "relative path" or "absolute path", so it doesn't count standard paths, but it also doesn't count user added paths. Now, I can't see yet how making it also count user added paths would be a problem, can you give me an use case?

Moreover, the -lib flag ACTUALLY counts user added paths, despite it saying it does not in the documentation. So if you have "Gem" outside the standard path and added to the path's preferences, [declare -lib Gem] will load it !!!

So I guess we need to keep this feature and update the help file. I particularly like this feature and consider it essential. I just hope -path would also count user added paths.

[Spacechild1]

Moreover, the -lib flag ACTUALLY counts user added paths, despite it saying it does not in the documentation.

this is because both -lib and -stdlib try to load a library, the difference is just where they start to look first. if [declare -lib] doesn't find the lib in the patch relative paths, it moves on to the standard path and the user paths.

Now, I can't see yet how making it also count user added paths would be a problem, can you give me an use case?

hmmm... I guess I was just paranoid. since the patch relative paths are always search first, there should be no problems. maybe you're right about using -path then...

[danomatika]

See #205.

[porres]

since the patch relative paths are always search first, there should be no problems.

yeah, I had a hunch that was the case, I was about to ask to make it sure

See #205

YAAAAYYY

[porres]

Hi, as I see it, this is not a suggestion to "enhance" Pd, but really to "fix a bug". I explain it better in my first comment about this issue, but let me point it out in short: We have a new understanding since the release of 0.48-0, but some things do not work as they should now, hence, a "bug", so I'm proposing this.

[porres]

This is in! Hurray!!!