Gracefully fail when env.use_ssh_config == True but there is no config file

[rbp]

If env.use_ssh_config is True, Fabric tries to load the env.ssh_config_path. However, if that is not set, or if the config file is not present, fabric aborts.

It would be very handy to be have env.use_ssh_config gracefully fall back to returning an empty dict when there is no config file available, just like ssh would behave (i.e., use config file if available, otherwise carry on with defaults).

If this makes sense, I'll be glad to provide a patch (even if it turns out not to be as trivial as it seems).

[bitprophet]

I think that's fine, but it should at least emit a warning of some kind, the reason it fails hard right now is that use_ssh_config is off by default, so the assumption is if it's on the user is expecting it to successfully load a file. Silent failure in that scenario would be bad.

[rbp]

Fair enough. Although the use case I bumped into was: we're using Fabric to automate a build/deploy system that a few different people can trigger (on the command-line or via Jenkins), and some of these people require ~/.ssh/config to be read (because they use different keys for different hosts), and some don't (because they use a single key that's used by default). Doesn't seem to be so far fetched.

Anyway, I'll write a small patch and do a pull request a bit later today. Thanks!

[bitprophet]

While it's a relatively crude method, you might want to experiment with setting use_ssh_config to False again globally, and have the users that need it create a ~/.fabricrc containing use_ssh_config = yes (technically that'll set it to "yes" but that's still a true value and Fabric's 'rcfile' only allows for strings, sigh...).

It's been a while but I believe that will correctly activate the setting for those users. Worth trying, especially since it could eliminate the discussed warning that some of your users would have to see every time.

[bitprophet]

Ironically I got bit by this myself just recently in a very similar situation to @rbp. Don't see a PR but AFAICT all we need to do is change the abort to a warn -- I am not sure why it was an abort to begin with. Doing this now.