Darcs has a large set of environment variables as documented at
Under MS Windows that leads to a set of inconveniences:
- the ENV var UI is bad on MS Windows and not pleasant to work with
- it requires the user to restart all cmd/powershell instances in order to see the changes in
- it's a management overhead for corporate installations. It's easy and less bug prone to tell
people to drop a config file somewhere - not so with env. var setup.
I would like a way to override values from the environment variables by setting their equivalents
in local (to the repo) or global (for the user) config files as described in
The values from the config file should take precedence over the environment variables.
ok, so we could _darcs/prefs/env and .darcs/env to hold these settings,
with the format
I'm not entirely convinced about the priority - I guess if the user set
variables in their global environment they would want the darcs settings
to take priority, but if they set them on the command line they would
probably want those to take priority. People probably don't want to set
things both in the global environment and in the global darcs config, so
I argue the precedence should be (lowest -> highest): global darcs
config; repo config; environment variables
Worthwhile and low-priority, as far as I can tell. Implementor should
maybe watch out for things like quoting/escaping
There's a danger of this adding another pebble to our pile of config
mechanisms. I'm tempted to mark this need-design and say, whoah we need
to think config a bit more carefully, things like:
- how do we avoid a proliferation of config mechanisms?
- how do we make it clear what sort of config travels from repo to repo
(eg. boring file if you save it), and what sort is really just for one
- what config is meant to be read by other darcs? (motd)
- environment variables - why do we use them?
- how do we continue to offer levels of control (global vs local vs one-
- how does this fit with command line switches
I don't want to get in the way of progress, just saying that this could
be the sort of thing we'd want to get right in Darcs 3. (There could
also be things to learn from Git here, dunno)