(1) I'm starting to get the idea. `foo.nims` _can_ replace `foo.nim.cfg`, or it
can be _additional_. The standard .cfg files (e.g. `nim/config/nim.cfg`,
`./nim.cfg`, `foo.nim.cfg`) are all read _before_ `foo.nims`. The docs could be
more clear.
(2) I see the problem now. We cannot have a global nimscript because, well, it
would have a separate execution context, so there's no point.
What I need -- in order to avoid doing the same work in each nimscript -- is a
way to `include` a global nimscript into a tool-specific nimscript...
And in fact, `include bar.nims` works within nimscript. Nice!
(3) A "task" is used to provide new arguments to `nim`. E.g. if I provide
echo "hi"
task novelty, "Example":
echo "where"
setCommand "dump"
Then I can run as `nim novelty foo.nim`, which is quite nice!
And `setCommand()` in `foo.nims` is used to change what nim command to run, if
desired.
I still don't understand what a "hidden" task is though, as I do not see
`--help` info on `foo.nims` tasks.
(4) This might help others:
[https://github.com/nim-lang/Nim/wiki/Using-nimscript-for-configuration](https://github.com/nim-lang/Nim/wiki/Using-nimscript-for-configuration)
(5) I guess the real problem is that, once my Nim library is installed,
consumers of my library are on their own. I guess that's just a hard problem to
solve.
(6) Maybe a good idea is to provide a nimscript _with_ my installed library, so
that consumers can `include` that. And maybe that should become best-practice
for libraries with foreign dependencies. Thoughts?
