Pure-data: feature-request [declare]: print added absolute paths in the verbose console

[mxa]

It would be quite useful for debugging to know the actual absolute paths added to Pd by a [declare] object when relative paths are included with the object. These paths could be printed to the console in verbose level.

[porres]

I just went through some trouble yesterday because of something like this. Dreadfully mysteriously I had an external folder in ~/library/pd and didn't know about it, so [declare -path] was actually loading it.

Anyway, I see this as an addition to this request: https://github.com/pure-data/pure-data/issues/281

I guess it's a good idea to be able to know wether a path or a lib was loaded or not and where it was found

[mxa]

To clarify: When using [declare -path ./xy] or [declare -path xy] or even [declare -path ../xy] and using the declare inside an abstraction which is in a subfolder it quickly gets to a complex folder up up down up situation where I'm only 98% sure that I've actually added the right path. It would be nice to actually see this relative path translated to an absolute path in the console to verify if the correct path was added to the search paths.
I did have the situation that a patch I distributed worked on my system because i happen to had the library globally added, but I thought it worked because I declared it as a path in the patch.

[Spacechild1]

These paths could be printed to the console in verbose level.

I don't know if it's helpful to do this automatically for every [declare] object. For a larger project, this would spam the console, especially with nested abstractions where search paths accumulate.

Maybe [declare] could take a message? Or it could be part of @porres's [canvas] project (https://github.com/pure-data/pure-data/pull/617), something like [canvas path] for getting a list of all search paths for a specific canvas.

[umlaeute]

i assume that with "verbose" level, the console gets spammed anyhow.

and then there's also "the other" verbose level (specifying -v as startup flag; or ticking the Verbose checkbox in the prefs), which gives you another layer of verbosity in which we could hide the info requested by mxa.

...but wait, if you do run Pd with -v then you already know by which path a given object gets loaded. so @mxa could have already used this information.

[umlaeute]

Or it could be part of @porres's [canvas] project (#617), something like [canvas path] for getting a list of all search paths for a specific canvas.

hmm, isn't [canvas path] already what would give you the absolute path of the abstraction where a given canvas belongs to?
(speaking of which: it seems that the [canvas] object mixes the concepts of "canvas" and "abstractions")

Maybe [declare] could take a message?

this.
i think that we should keep related functionality in specific objects, rather than creating big catch-all objects that deal with everything.
this should keep the cognitive load of the user low (at the expanse of the cognitive load of the developer who has to think properly about interfaces; which is a good thing)

[mxa]

...but wait, if you do run Pd with -v then you already know by which path a given object gets loaded. so @mxa could have already used this information.

IOhannes in his signature snarkyness points this out, true, but I'd like to stress that it's a slightly different information to know through which path an object got loaded or which path the declare object added.

[Spacechild1]

or which path the declare object added.

Agreed. I might make a PR with a message for [declare] which spits out the canvas search paths, maybe with an option to show only the paths added by [declare].

[Ant1r]

IMHO [declare] doesn't add any absolute paths to the list (excepting if you [declare] an absolute path); it only adds (many!) new possibilities to search for an object. If and how it is actually used will be determined by the success of each object search.

For example, if you [declare -path foo], one object could be successfully loaded from /usr/lib/pd/extra/foo/firstObject.pd, and the other from yourPatchDirectory/foo/secondObject.pd...

So I think only object loading information is really meaningful; [declare] itself is just... itself.

[Spacechild1]

doesn't add any absolute paths to the list (excepting if you [declare] an absolute path); it only adds (many!) new possibilities to search for an object.

yes, but it's still possible to iterate over all those (new) possibilities and output the result, so the user can see the directories which would be tried in case of a "real" object search.

[mxa]

[declare] doesn't add any absolute paths to the list (excepting if you [declare] an absolute path); it only adds (many!) new possibilities to search for an object

I think this is another issue in itself that the search paths become easily spammed and overloaded. IMHO it would be cleaner if a declared relative path would only be relative to the patch it is in. But that really is another issue / discussion which should not be part of this one.