bundle config exits with successful exit status even when requested setting isn't set

[jasonkarns]

bundle config SOME_SETTING is expected to print the value for the requested setting.

If the setting has a value, it is printed to STDOUT and exit status of 0 is returned as expected. If the requested setting is not set or has no value, it is expected that a non-zero exit status is returned. (as is conventional for cli programs) However, an exit status of 0 is returned in all cases.

This means that scripts and utilities that wish to interrogate bundler to find the value for a given setting have to parse the STDOUT of bundle config in order to determine if a particular setting is unset.

$ bundle config something
Settings for `something` in order of priority. The top value will be used
You have not configured a value for `something`
$ echo $?
0

Further, if any work is done on this, I would strongly request that the output from this command go to STDERR.

I would expect bundler config foo 2>/dev/null to print nothing but the final computed value of foo. All the rest of bundler's output (which is indeed super helpful), should go to STDERR as it is extraneous to the core role of bundle-config. And thus bundler config UNSET 2>/dev/null would print no output and exit non-zero.

[segiddins]

I'm not sure why bundler would exit non-zero if the setting isn't set -- nothing has "failed" when invoking that command, since all settings are allowed to be nil

[jasonkarns]

The command is querying for the configuration, so I'd expect querying for a configuration setting that doesn't exist to be considered an error. (We're asking for the value of a setting, but the setting doesn't exist.) It's indistinguishable from a typo in the setting name, which from a user perspective would be helpful to notice was mis-typed.

If a setting is explicitly set to nil, then it wouldn't be an error because the setting exists and is set with a value. That's a meaningfully different condition for the configuration to be in.

To go further, if the bundle config command were to respond with the effective value of an unset setting (say, responding with the default value of any given setting), then I could see an argument for returning 0 in that case. But that would still allow for returning nonzero for unset settings that aren't recognized or don't have defaults.

Prior art:

$ git config fooey; echo $?
error: key does not contain a section: fooey
1
$ git config core.fooey; echo $?
1

(Just noticed that the aws cli also exits nonzero for missing config option.)

[segiddins]

If a setting is explicitly set to nil, then it wouldn't be an error because the setting exists and is set with a value. That's a meaningfully different condition for the configuration to be in.

Right now, there is no way to store nil in the settings file

[jeromedalbert]

The last comment was 6 years ago, should this issue be closed?

[deivid-rodriguez]

In my opinion, this request still makes sense and makes bundle config more useful, even if it's old.

[jeromedalbert]

Ok! There are two requests here:

1. Add a non-zero exit status if the setting is not set. Samuel had some reservations about this.
2. Output informational message to stderr. It is similar to work done in Emit progress to stderr when --print is passed to bundle lock #7957 and Emit progress to stderr during bundle outdated --parseable #7966. If this request makes sense I can make a PR.

[deivid-rodriguez]

Yep, a PR would be great!

I think the fact that Bundler can't distinguish between a explicit nil setting and an "unset" setting doesn't contradict this proposal?

There are of course backwards compatibility concerns when making a command that previously succeeded start failing, but I think it will probably affect few people, an maybe actually help catching typo bugs. If we do this, I'd ship it with December's minor, tagging it as a minor breaking change.

[jeromedalbert]

Regarding request 2, on second thought I think outputing the informational message to stderr is not needed here. If you don't need to parse the output, it does not really matter that all output is emitted to stdout. If you need the parse the output, bundle config something --parseable should be used, and this option does not display any informational message so it can be easily parsed. The --parseable option does not seem to be documented in the manpage though.

So that leaves us with request 1 for this issue: adding a non-zero exit status if the setting is not set.

[jasonkarns]

If you don't need to parse the output, it does not really matter that all output is emitted to stdout.

I think I would disagree with this assertion. As authors of the cli, we cannot foresee all the possible needs and use cases of the tool. This is why adherence to the standards and conventions (ala, a "specification") is so vital.

Example: It's exceedingly common for tools (scripts, wrappers, subshells, even just blocks of commands, etc) to silence stdout so that they may be compliant even if the wrapped tools are not. In such a case, the STDOUT output may not be necessary (thus not parsed or using --parseable), but STDERR would still be expected to contain the diagnostic messages of any failures. If bundler doesn't distinguish the two, then its informational display would be swallowed unknowingly.

[jeromedalbert]

I was talking in the context of this output when running bundle config something:

Settings for `something` in order of priority. The top value will be used
You have not configured a value for `something`

The first line is a green informational message.
The second line displays You have not configured a value for something when there is no value, or something like Set for the current user (/Users/jerome/.bundle/config): true when there is a value.

For this particular output I meant that both lines going to stdout was arguably fine.

STDERR would still be expected to contain the diagnostic messages of any failures.

Are you implying that You have not configured a value for something should be emitted to stderr? Or that both lines should be (which doesn't seem right since the first one is not failure-related)?

[deivid-rodriguez]

What @jeromedalbert said makes sense to me, in the particular context of bundle config. Let's implement just request 1.