Consider reinstating --gateway in v2 somehow

[bitprophet]

In v1, the --gateway CLI option set env.gateway to a host string, which triggered use of a ProxyJump/direct-tcpip style gateway.

In v2, the gateway config option gets used as a default value for Connection(xxx, gateway=yyy), which can be either a string (triggering ProxyCommand style gatewaying) or another Connection (triggering ProxyJump style gatewaying).

What this means is that v2 lost the ability to specify a ProxyJump style gateway at runtime; the only current possibility is to do eg INVOKE_GATEWAY="ssh foobar" fab mytask (or any other Fabric 2 bearing Python program), which can only set a string because that's how env vars tend to work, and thus can only be used for ProxyCommand style gatewaying.

---

It'd be nice to address this, but doing so does require leaning more heavily on string-to-object shorthand. We do retain that to some degree (the first arg to Connection can resemble v1 host strings) so it's possible, just not 100% ideal.

More importantly is just the split between the two gateway styles; if we want to do this properly we need two CLI flags so we can tell exactly what the user intends, otherwise it's ambiguous ("ok, we parsed the CLI, and we have a gateway string. should we be trying to make a Connection out of it or no?").

---

FWIW - given we have SSH config support and other strong (including Python-format) configuration file support, and that one's need to use a gateway is usually not something that changes minute to minute, this feels low priority to me considering it's a nontrivial bit of work and extra CLI args. So I'm not putting it in any milestones yet.

[jalaziz]

We're in the process of upgrading to Fabric 2.x and we hit this issue. We're trying to work around the issue or patch in support for ProxyJump style gatewaying va the CLI.

Just thought I'd leave a note here since it's documented as something you might consider adding if users actually notice the lack of the feature.