extra folder should have search priority over user added search paths

[porres]

Hi, in cyclone we have a hilbert~ object, that I'm trying to load only as [cyclone/hilbert~], so just "[hilbert~]" would still call the abstraction that resides in "extra".

But that never happens as it seems externals have priority in the search path before the extra folder.

So the only way I can load pd vanilla's hilbert~ is if I don't have cyclone in Pd's path or in [declare], which is bad...

this could be fixed if extra had priority in the search, which I think it'd be common sense, as Pd Vanilla objects actually do have priorities over externals in general.

cheers

[umlaeute]

i concur.

each and every software i know will prioritize in the following order:

1. user specific (e.g. %AppData%\Pd)
2. administrator provided data (e.g. %CommonProgramFiles%\Pd)
3. system provided data (e.g. %ProgramFiles%\Pd\extra)

if you want to avoid nameclashes with "builtins", you shouldn't create them in the first place.

[porres]

if you want to avoid nameclashes with "builtins", you shouldn't create them in the first place.

I ended up not including a [hilbert~] option for cyclone.

But I still think Pd Vanilla objects should have priorities over externals.

[danomatika]

ping @umlaeute @millerpuckette

My first take was "oh no, reordering paths might break something" but, in this case, the following is a good point:

this could be fixed if extra had priority in the search, which I think it'd be common sense, as Pd Vanilla objects actually do have priorities over externals in general.

This is not likely to change many setups unless they rely on putting everything in extra, however we've clearly demphasized this with [declare] and the Documents/externals directory + documentation.

[porres]

reordering paths might break something

can't see how

This is not likely to change many setups unless they rely on putting everything in extra

but how? If everything is in extra, things will still be found. It'll just look there first

[danomatika]

I think you misread my email. I was agreeing with and saying that changing this should *not* really break anything. My first paragraph was about my initial reaction, not my later agreement.

[millerpuckette]

I'm scared of changing anything related to search paths - I can't see how it won't just deepen the confusion and misery that already reigns - and I'm sure somthing will break, as it always does when anything regarding search paths gets touched. cheers Miller

…

On Sat, Aug 10, 2019 at 09:52:13AM -0700, Dan Wilcox wrote: I think you misread my email. I was agreeing with and saying that changing this should *not* really break anything. My first paragraph was about my initial reaction, not my later agreement. enohp ym morf tnes ----------- Dan Wilcox danomatika.com robotcowboy.com > On Aug 10, 2019, at 6:19 PM, Alexandre Torres Porres ***@***.***> wrote: > > reordering paths might break something > > can't see how > > This is not likely to change many setups unless they rely on putting everything in extra > > but how? If everything is in extra, things will still be found. It'll just look there first > > ??? > You are receiving this because you commented. > Reply to this email directly, view it on GitHub, or mute the thread. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #289 (comment)

[porres]

yeah, I can't see the issues, but my vision is limited anyway so I can't argue :)

Since I'm now more worried about documenting Pd and editing the manual, I'm just concerned on understanding how it really works so I can explicitly explain this structure in that reference.

So it seems the search priority for externals is: relative folder (relative to the patch), then the user added search paths (in preferences => path), and then finally the standard paths (which still includes global system provided data, administrator provided data and finally the user/application folder - which is the 'extra' folder - in the very end of the search list.

It did make sense to me that "extra" should have a search priority over other externals, it seems weird to point out in the manual that this is the last place Pd will ever search for something - but maybe not that many people will question it as I did. Maybe if we say this is more of just another external library, and not something to be deeply connected to Pd itself, it can make more sense - otherwise it seems counterintuitive to me.

[porres]

and actually, as I'm revising Pd's manual, it does say pretty clearly, already, that 'extra' is searched for last. This may indicate it was all very intentional. If so, @millerpuckette can you tell us the reasoning behind it?

[millerpuckette]

So that you can override stuff in extra with your own better objects.

[porres]

So that you can override stuff in extra with your own better objects.

I don't think I can make better ones :) but that reminds me we could include some information on how Pd allows you to override internals with compiled objects, and then it can also include this idea that objects in 'extra' can also be overriden!

So I'll do that in my manual revision, and I might just say that the reason is because you can override stuff with better objects, cause it sounds funny :)

Anyway, will close this issue and my PR

Thanks