Gatti Lorenzo
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