Forwarding my reply to the list too. :)

On 29 March 2012 16:55, Ville Voutilainen ville.voutilainen@gmail.com wrote:

On 29 March 2012 16:41, Rudi Schlatte rudi@ifi.uio.no wrote:

...

Ville Voutilainen ville.voutilainen@gmail.com writes:

...

Here's a tentative patch. I opted for a new keyword argument, since the new function approach would've led to duplication or to a macro that has the new argument anyway.  Untested so far, so this is for general review. Also lacking the docstring changes.

Here's my version, using your getenv and process-builder changes.  I get by with only the :environment key, see the docstring for an example on how to overwrite PATH and keep the rest.  Lightly tested.

Looks reasonable. Some questions though:

...

-(defun run-program (program args &key environment (wait t)) +(defun run-program (program args &key (environment nil environment-p) (wait t))

Ah, yes, this works too, no need for a separate clear-env. But, does this change the semantics? Our previous code did an environment-merge if an environment is supplied. This one will clear and insert, and requires using getenv-all if you want to replace only some parts. I don't want to do such a semantics change. By avoiding the semantics change, I don't need to worry about breaking asdf.

For that point, I'm still biased towards the clear-env keyword arg approach. In that approach, getenv-all is just an utility function that you can use if you want to do weird-complex environment processing, but possibly the most common use cases are still "replace a couple of values by providing an environment without clearing" and "run in a very restricted environment with only a handful of variables", neither of which requires the use of getenv-all.

Comments?