[chuck-users] R: Importing in Python - was: ChucK article(s)

[robin.escalation]

Gatti Lorenzo <lorenzo.gatti at dsdata.com> wrote:

> A significant difference in usage between Python and ChucK is that
> Python libraries and extensions tend to be either an integral part
> of a project or stable shared dependencies of other libraries or
> applications, while most ChucK libraries can be expected to be
> 
> 1) experimental or hacked versions of standard library modules,
> overriding the originals
> 
> 2) foreign and/or hacked code adopted from other people
> 
> 3) personal work-in-progress toolboxes.

Actually I don't see how this is really different for the two
languages. If anything it's a difference of degree and not of kind. I
hack lots of my own libraries in Python, and some of these fit all
the above categories. In no cases do I want to store them in the
application tree, and so I need to be able to specify where they are.

I am not a big fan of environment variables, since they are global
for all apps on the system. I take it from your comments you are of
like mind. However they are simple solutions that work for simple
cases. Other solutions are better.

> There are two mostly orthogonal important design decisions about
> library search paths on the command line: whether to specify
> directories (including all their content) or single files and
> whether the list of library locations should be in a command line
> option or indirectly referenced from a configuration file. 

In the first case: why not both? A path could point to either a file
of a folder.

In the second: A configuration file is more flexible. The
command-line can reference it, reducing verbosity. Multiple configs
can be maintained for different environments. Apps could alter the
config file directly (OK, not ChucK apps... yet) for further
flexibility (and potential mayhem!).

The config can be a simple list of paths. When searching for a file
to import, ChucK first looks in the folder of invocation, then in the
config file, reading bottom up, then lastly in the ChucK application
mandated location. 

This means that a file I'm hacking in the current folder will be
found first. If the file isn't there, it will be loaded from one of
my library locations, and finally the standard library.

The same sort of search could be done to find data files, like wavs
to open. 

Similarly, to find the config file itself, ChucK looks first on the
command-line, next in the invocation folder, and lastly in the ChucK
application folder.

(And maybe looks to an environment variable.)

-- robin