2018-04-13 8:21 GMT-03:00 Alexandre Torres Porres <porres@gmail.com>:

2018-04-13 4:10 GMT-03:00 Liam Goodacre <liamg_uw@hotmail.com>:

distributing externals along with an abstraction is bad form like you said, in my opinion
Assuming that there is something wrong with the method outlined above, what is the proper use of [declare] in this instance? [declare -lib ctx_externals/zexy -path ctx_externals/cyclone -path ctx_externals/else ...] seems to work for me here, but I know that the use of -path and -lib is changing, so I just want to be sure.
current behaviour of [declare -path] works for objects in paths related to the patch, so yeah, this works. And this won't change

So, when do you want to use "libname/external" and when should you just use "external"? I think this is important to mention and is related to this question. First, how should you use it? You need to have the parent folder where the external folders are included to be added to the search path. Since Pd 0.48, Pd creates a "Pd documents" folder for you and also an "externals" folder in there, and this folder is automatically added to the search paths (that is if you just agree to Pd's suggestions when opening the application for the first time). In macOS, for instance, this is ~/Documents/Pd/externals

So, for whatever libraries you include in that folder, for example, you can use the "libname/external" method and it will work. Cause it'll search inside ~/Documents/Pd/externals for the "libname/" subfolder and then the external. Now, if you also add the "libname/" path, even though you already have

~/Documents/Pd/externals as a search path, what you have now is the option to not worry about using "libname".

But I like using "libname/external" because: 1) it makes it explicit where this object comes from. 2) It avoids possible nameclashes with other externals that have the same name and might be called eariler in the search priority. 3) It doesn't need [declare] in the patch.

Currently [declare] doesn't work if you want to call paths from user added paths anyway, so you can't use it if you want to call externals from there. But if https://github.com/pure-data/pure-data/pull/205 is merged, then this changes, and [declare -path] will be able to include subfolders relative to user added paths. For me, this is a crucial feature, as it basically makes [declare] useless for me right now, when I'm including all my externals in ~/Documents/Pd/externals - so I either have to use "libname/external" or add the external subfolder as well to the user added paths.

I expect that some of you will bring up the point that distributing externals along with an abstraction is bad form, as it might interfere with the user's own versions of the same externals. The solution we arrived at in the last thread was to let the user decide whether to have Context provide its own externals (basic), or whether to provide them manually (advanced). This is what I intend to achieve,.

Yeah, it might interfere with other versions and stuff, but the point here maybe is how we want to handle dependencies. And all in one, it just looks like a hideous kludgy and counterproductive strategy, to me.

I think ideally we should have an external manager that install missing dependencies, and this has been discussed here. Like, Pd could sense a patch wants an external from cyclone and, if you don't have it, it asks you if you want to download or install it. Yeah, but I don't see anything like that coming right away, maybe something like it, in this direction, some time later. So what to do for now?

Well, another deal is that it should be clear for Pd users to handle dependencies and installing externals, so all you need to say is this requires libraries "a, b, c", and they should know how to easily do it and/or you should provide a nice step by step manual on how they need to proceed. But perhaps a nice and straightforward common practice for installing externals in Pd is not yet consolidated, hence all the questions, debate and proposals for improvement.

cheers