Thanks Alex, you've pretty much answered all my questions. I have a bit of confusion though, because for me, [declare] in 0.48 does seem to add custom search paths (see attached screenshot). Doesn't this contradict what you said?

As to whether I should do it or not, I have users telling me that I should and developers telling me that I shouldn't, which puts me in a bit of a bind. Ultimately, I'm worried that a complex install process will scare a lot of new users off, which is why I'm looking for a solution. I've given up on many computer programs before simply because I couldn't get them to work in the first 5 minutes; haven't you?

The previous thread from 2017 seemed to arrive at the conclusion that there was a compromise to be found by distributing two versions of Context, one with and one without externals. I've modified this a little in that I was planning to release one package with externals included and a simple way of disabling them. The reason for this is simply so that I can avoid the complication of handling two packages, but I'm willing to be talked back into the two-package solution if there are compelling reasons.

Now that you have clarified the difference between declaring via paths and via [declare], I have another idea. What if I do the following:

Go back to using [library/object] everywhere and [declare] nowhere (save for Zexy);
Include a "cyclone" and "zexy" etc. folder with the relevant objects in the main Context folder, not in a special "ctx_externals" folder.

This way, Context will find the local externals by default, meaning that the user doesn't have to bother with downloading them. The readme file then provides simple instructions that if the user doesn't want to use the local externals, s/he can simply delete the given folders. All of the external objects in the Context patch, which are given as [library/object], proceed to search for the relevant object in "PD documents". This seems about as simple as it ever could be. Or am I wrong?

Liam

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