Closed arichiardi closed 6 years ago
Oh this is great! I love fact that the advice from Sean is included too :smile:
I'm trying to think of any downsides to this, like where people may have relied on the completely accumulative nature of this argument before. It's the only accumulative argument with a :default
specified which is good.
I think this is all fine and I'm happy to merge, thank you so much for working it out and fixing it, it's massively appreciated. I'm thinking of making this a major version bump since the user facing API has changed (not accreted a new thing, but changed an existing one), thoughts?
Also, this now works with your project? Did it fix that issue you were having a while ago?
Thank you! Yeah I think should be major probably. BTW it still accumulates, it does not accumulate the default if other are specified.
I will double check in replumb as well maybe that's solved too.
Hello @Olical is there any blocker in merging this to the repo? I know I can use shas but it feels better not to use them :smile:
Nope, I will merge it today. Was just waiting to see if it helped get your original repo working or not really, I'll check it out later. At work today and feeling kind of ill so if not today then over the next 48 hours :sweat_smile:
Deployed in v3.0.0
Awesome thank you!
Because of the way
tools.cli
threads default values, the default dir was always conjoined in the:dir
key. This is not what we want, cause if the user specifies the--dir
option, she likely does not have "test" in her code base.This patch uses the new
:default-fn
feature (present intools.cli
0.4.1
) to set the default value after the command line option parsing.