> "." in a path means "the current directory" when it should have meant "the
directory this patch right here is in".

Actually, I'm mostly concerned with the common case, which is the user
who doesn't do anything at all-- no [declare], no clue what a "path" is, just
modularity from dropping an abstraction in "the directory this patch right here
is in".  We can't even assume that this class of user knows what "/" or "./"
means.  They may only be familiar with the file system from a native dialog.
(And even that may be secondary to just auto-saving junk in the cloud.)

This is the user targeted by your tutorial #12:
"There is a separate file in this directory named 'sendnumber.pd' which is loaded every time you type 'sendnumber' in an object box."

This is the logic that allows a user to ship a zip-file of their patch and its
"helpers", and be sure that it works as they intend on any other user's
computer.  The closer we can get to guaranteeing the quoted
sentence to always be true, the better.

As I understand it, IOhannes' change to the loader search order gets us
closer to this.

I asked about user control of the loader order because there may be cases
where the user really wants abstractions first, and binaries second.  But the
cases I can think of have to do with overriding internal classes, so that's
probably outside the scope of this patch set.

-Jonathan




On Thursday, September 24, 2015 3:23 PM, Dan Wilcox <danomatika@gmail.com> wrote:


To be fair, Deken puts things in ~/pd-externals because it was there and working already without requiring *yet another patch*. Having a base place to install externals fixes the need to install directly to extra on platforms where that doesn’t make sense aka within OSX app bundles.


On Sep 24, 2015, at 1:00 PM, pd-dev-request@lists.iem.at wrote:

here are a couple more (perhaps more minor) ones:
Searching a fixed directory like "~/pd-externals" is a rotten idea - I
don't know why I ever accepted it as an idea. And now the "deken" engine
puts patches there!


_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at
http://lists.puredata.info/listinfo/pd-dev