Issue 2121 Allow the ability to set and override environment variables from a config file.

Title Allow the ability to set and override environment variables from a config file.
Priority wishlist Status given-up
Milestone Resolved in
Superseder Nosy List mulander
Assigned To
Topics UI

Created on 2012-01-12.20:48:37 by mulander, last changed 2017-07-31.00:32:32 by gh.

msg14985 (view) Author: mulander Date: 2012-01-12.20:48:34
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.
msg15001 (view) Author: ganesh Date: 2012-01-13.19:09:48
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
msg15012 (view) Author: kowey Date: 2012-01-13.21:56:44
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 
repo only?
- 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)
Date User Action Args
2012-01-12 20:48:37mulandercreate
2012-01-13 19:09:49ganeshsetmessages: + msg15001
2012-01-13 21:56:45koweysetstatus: unknown -> needs-implementation
topic: + UI
messages: + msg15012
2017-07-31 00:32:32ghsetstatus: needs-implementation -> given-up