The use case is you have a collection of D scripts within the
same directory subtree (maybe a git repo) that all share some
common configuration. Maybe they all require extra search paths
to find source/libraries, or they all throw exceptions to the
user and should be compiled with debug symbols so exceptions
print their full stacktrace, etc. Rather then requiring the user
to call the script in a particular way or wrapping all the
scripts with yet another tool, what about adding support in rdmd
for configuration files? The configuration file could live in
any parent directory of the script being ran:
FileSystem:
/a/b/c/myscript.d
Shell:
/a/b/c> rdmd myscript.d
rdmd checks for /a/b/c/rdmd.config
rdmd checks for /a/b/rdmd.config
rdmd checks for /a/rdmd.config
rdmd checks for /rdmd.config
The rdmd.config file would apply to all rdmd scripts in all
subdirectories on the file system. It works similar to how git
determines whether or not it lives in a repository (searches all
parent directories for the .git directory).
Additionally, allowing rdmd to be configured through files makes
more complicated configurations more reasonable. For example, if
your scripts depend on a dub package, you could do this easily in
a configuration file, whereas doing this on the command line
would be a nightmare.
Supporting this type of configuration could easily be implemented
in a wrapper around rdmd (rdmdc?), however, if this idea is
generally useful then it should be added to rdmd itself so
everyone benefits. The question is, is this feature general and
useful enough to justify adding to rdmd itself, or is this only
useful in rare cases meaning it should live inside an rdmd
wrapper?

The use case is you have a collection of D scripts within the
same directory subtree (maybe a git repo) that all share some
common configuration. Maybe they all require extra search paths
to find source/libraries, or they all throw exceptions to the
user and should be compiled with debug symbols so exceptions
print their full stacktrace, etc. Rather then requiring the
user to call the script in a particular way or wrapping all the
scripts with yet another tool, what about adding support in
rdmd for configuration files? The configuration file could
live in any parent directory of the script being ran:
FileSystem:
/a/b/c/myscript.d
Shell:
/a/b/c> rdmd myscript.d
rdmd checks for /a/b/c/rdmd.config
rdmd checks for /a/b/rdmd.config
rdmd checks for /a/rdmd.config
rdmd checks for /rdmd.config
The rdmd.config file would apply to all rdmd scripts in all
subdirectories on the file system. It works similar to how git
determines whether or not it lives in a repository (searches
all parent directories for the .git directory).
Additionally, allowing rdmd to be configured through files
makes more complicated configurations more reasonable. For
example, if your scripts depend on a dub package, you could do
this easily in a configuration file, whereas doing this on the
command line would be a nightmare.
Supporting this type of configuration could easily be
implemented in a wrapper around rdmd (rdmdc?), however, if this
idea is generally useful then it should be added to rdmd itself
so everyone benefits. The question is, is this feature general
and useful enough to justify adding to rdmd itself, or is this
only useful in rare cases meaning it should live inside an rdmd
wrapper?

In my opinion, adding this complexity to rdmd is overkill. When
you need to use this, IMHO, you should write a little shell
script that calls rdmd passing the correct arguments. It's very
easy, just a couple of lines of shell script. Maybe even a
one-liner.
In file rdmd_wrapper.sh:
rdmd -my-special -command-line -parameters $*
When you call it this way:
./rdmd_wrapper mymodule.d
It will execute this:
rdmd -my-special -command-line -parameters mymodule.d
If you need the same configuration really often, you can add the
wrapper to the path, so you can call it from everywhere.
But this is just my opinion, many may disagree.

...
Additionally, allowing rdmd to be configured through files
makes more complicated configurations more reasonable. For
example, if your scripts depend on a dub package, you could do
this easily in a configuration file, whereas doing this on the
command line would be a nightmare.

In my opinion, adding this complexity to rdmd is overkill. When
you need to use this, IMHO, you should write a little shell
script that calls rdmd passing the correct arguments. It's very
easy, just a couple of lines of shell script. Maybe even a
one-liner.
In file rdmd_wrapper.sh:
rdmd -my-special -command-line -parameters $*
When you call it this way:
./rdmd_wrapper mymodule.d
It will execute this:
rdmd -my-special -command-line -parameters mymodule.d
If you need the same configuration really often, you can add
the wrapper to the path, so you can call it from everywhere.
But this is just my opinion, many may disagree.

I don't necessarily agree or disagree with you, thanks for
providing your opinion. A wrapper script would certainly solve
the simple cases. The con is that it adds an extra layer to the
script and every application will have their own solution which
makes a project more isolated. The wrapper script was the first
solution that came to my mind but as I thought about
configuration files, they seemed worth considering.
I'm curious what you think about the more complex operations that
configuration files could facilitate. The example I gave was that
this could enable a script to use dub package dependencies that
are automatically downloaded and built by rdmd, but I'm sure
there are other interesting use cases. An argument could be made
that this should go in an external tool rather then rdmd though,
but that thought seemed a bit odd since rdmd is already a wrapper
around dmd itself, but maybe that's ok. Do you have any new
features rdmd could support if it had configuration files?

I don't necessarily agree or disagree with you, thanks for
providing your opinion. A wrapper script would certainly solve
the simple cases. The con is that it adds an extra layer to
the script and every application will have their own solution
which makes a project more isolated. The wrapper script was
the first solution that came to my mind but as I thought about
configuration files, they seemed worth considering.

I agree that a custom wrapper script has the drawbacks you said.
But I fear that a configuration-file-based system would either
only solve simple cases or would become very complex and
difficult to master in order to accomodate to most special uses,
thus becoming less appealing than a simple script.
A config file format is one more thing to know and to look up:
"how do I do this with rdmd-config?", while the Internet is full
of tutorials on "how to do this with bash". The same happens to
DUB: it allows to do many things when building the project, so
people asks "how can I do this with DUB?" while it would probably
be easier to just write a shell script that calls DUB and then
(or before) does the other thing.
We should avoid reinventing the wheel.

I'm curious what you think about the more complex operations
that configuration files could facilitate. The example I gave
was that this could enable a script to use dub package
dependencies that are automatically downloaded and built by
rdmd, but I'm sure there are other interesting use cases. An
argument could be made that this should go in an external tool
rather then rdmd though, but that thought seemed a bit odd
since rdmd is already a wrapper around dmd itself, but maybe
that's ok. Do you have any new features rdmd could support if
it had configuration files?

I think that many reasonable but not-trivial things can already
be done with DUB, which allows custom compiler and linker flags,
custom commands before and after the build, different
configurations and so on. It is already a very complex
configuration system, and can also do the job of rdmd ("dub run"
executes the project, using a cached compiled file if available
and up to date, as rdmd).
DUB also allows to have single-source packages, where the DUB
configuration and dependencies are embedded in a comment at the
beginning of the source, which would be a great solution for your
example, as it doesn't even require a configuration file.