[PD] declare vs. namespaces - current best practice

[Christof Ressi]

> (which actually might be tricky depending on platform/how their system is set up). 

exactly, that's why it's better not to make any assumptions. just tell users: "needs zexy, cyclone ..." and it's their responsibility to add the necessary search paths/load libs if necessary.

and again:

> > imagine you want to use both [foo/obj] and [bar/obj] in the same
> > abstraction. how could you possibly force on or the other with
> > declare?


> Gesendet: Samstag, 06. Januar 2018 um 12:53 Uhr
> Von: "Derek Kwan" <derek.x.kwan at gmail.com>
> An: "Alexandre Torres Porres" <porres at gmail.com>
> Cc: "Christof Ressi" <christof.ressi at gmx.at>, Pd-List <pd-list at lists.iem.at>
> Betreff: Re: [PD] declare vs. namespaces - current best practice
>
> 
> >> And to come back to my first remark here on this thread, if
> >> [declare] cannot always force a priority, shouldn't it?
> >
> > I don't think so. [declare]'s job is to add paths to the search path
> > and load libraries. it has nothing to do with namespacing.
> >
> > imagine you want to use both [foo/obj] and [bar/obj] in the same
> > abstraction. how could you possibly force on or the other with
> > declare?
> >
> 
> Well, I suppose one way of forcing the use of cyclone's gate without
> typing out the entire thing and dealing with this whole namespacing
> thing is to basically use the -noprefs flag when launching pd (and
> assuming the people you are distributing the patch to have Pd somewhere
> in their path which might be a big if, you can send along a shell script
> that launches pd with that flag for them) and using [declare] to control
> what gets loaded and what paths are added (which actually might be
> tricky depending on platform/how their system is set up). And of course
> not loading the prefs file affects more than just paths/loading...
> 
> So maybe now that I type it out this isn't such a simple idea to
> implement haha, but maybe it could be helpful for some use cases...
> 
> Derek
> -- 
> Derek Kwan
> www.derekxkwan.com
>