[PD] How to declare custom libraries in abstractions

[Alexandre Torres Porres]

nice tune :)

2018-04-13 16:51 GMT-03:00 Lucas Cordiviola <lucarda27 at hotmail.com>:

> Hi Liam,
>
> Take a look at this example: ---> http://lucarda.com.ar/lucarda2010b.rar
>
> I distribute externals in the "externals" folder and also their licenses
> (see: data/externals/Licenses/readme.html).
>
> I only do [declare -path %%]. I'm using some objects from Zexy but from
> the v00-extended (single binary ones).
>
> In this example I only use [ggee/image] and the rest of the externals are
> not used. This externals package is what i require for other "Pd Albums"
> available on my site. (This is just my unified pkg )
>
> PS: Last month I did an especial w64 folder with self-compiled externals
> for windows 64-bit. I was lucky that my unified pkg has few externals (and
> sources available) and it was easy to compile them with pd-lib-builder.
>
> Hope it helps,
> Lucarda.
>
>
> --
>
> Mensaje telepatico asistido por maquinas.
>
> On 4/13/2018 2:41 PM, Liam Goodacre wrote:
>
> 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:
>
>    1. Go back to using [library/object] everywhere and [declare] nowhere
>    (save for Zexy);
>    2. 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
>
>
> *From:* Alexandre Torres Porres <porres at gmail.com> <porres at gmail.com>
> *Sent:* 13 April 2018 15:43
> *To:* Liam Goodacre
> *Cc:* PD list
> *Subject:* Re: [PD] How to declare custom libraries in abstractions
>
> 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
>
>
> _______________________________________________Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180413/2d382850/attachment-0001.html>