Hello list,

I have a couple of questions or more like "views" on this too.

1. the problem with using [library/object] method (when libraries compiled
as one single file) is that you must always include the complete external
library and this, as Liam said, may cause a 2 mb project to extend to 35mb,
to give an example.

2. I am more worried if some libraries are going to change or not to a
single compiled file, in this case, the [library/object] I think becomes
obsolete as the library must be loaded independently. making patches that
were using an old version of the library to cause "couldn't create" error.

so if let's say "cyclone" decides to compile it into one file, I am not
sure if objects created with [library/object] in a patch will
successfully create.
so for a while now I have been using declare for my projects, and loading
the libs on startup. I always have subfolders in my project that are
declared with -path and usually copy externals needed in there.

my two cents

On Fri, Apr 13, 2018 at 6:41 PM, Liam Goodacre <liamg...@hotmail.com> 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 <por...@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 <por...@gmail.com>:
> 2018-04-13 4:10 GMT-03:00 Liam Goodacre <liamg...@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@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list

José Rafael Subía Valdez
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 

Reply via email to