[PD] How to declare custom libraries in abstractions

Alexandre Torres Porres porres at gmail.com
Fri Apr 13 16:43:03 CEST 2018


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

>
>
> 2018-04-13 4:10 GMT-03:00 Liam Goodacre <liamg_uw at hotmail.com>:
>
>>
>>  distributing externals along with an abstraction is bad form like you
> said, in my opinion
>
>>
>>    1. 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180413/ddd03894/attachment-0001.html>


More information about the Pd-list mailing list