Closed
Description
This is another "make it easier to upgrade to v2 piecemeal" feature: with fabric
and fabric2
both imported, create a fabric2.Connection
from one's current fabric.state.env
contents.
TODO
- Port over all low hanging fruit env vars so it mostly Just Works for the average user
- Take another whack at testing+implementing automatic 'from fabric.api import env', or roll it back in the docs if it's just not feasible to test.
- Try real quick to add a Travis-oriented task or script line, which installs v1 and v2 side by side to do an integration level test of this functionality (regardless of whether we implemented automatic importing; can just do it explicitly.)
Thoughts
Brainstorm re: appropriate API:
- Presumably wants to be a classmethod-constructor on
Connection
.from_v1
? bit on the nose/awkward but very clear/accurate.from_env
? easily mistaken for other more general senses of "env"....from_module
? ditto, could mean a lot of things....from_dict
? (actually more accurate thanfrom_module
asenv
is a dict subclass, just one that is a singleton _in_a module) - not amazing but not awful.from_env_dict
.from_v1_env
- nicely explicit? slightly more obvious than just.from_v1
too?.import
? since we're "importing" v1 state?
- Arguments?
- None - implicitly does its own
from fabric.api import env
? Convenient but very fragile - Env obj - you do
Connection.from_v1_env(env)
and we don't care how you imported it? Less fragile, slightly more work depending on how often users are calling it. - Both? No real reason why not...having the ultra-convenient no-args version seems like a big win for removing friction.
- Any behaviors we want toggle-able/overrideable at this level? Easy enough to add later...
- None - implicitly does its own
Thoughts as I run down env
:
- Going to focus on just basic Connection vars for right now, the rest can remain TODOs
- Most of those other settings probably want to end up in a
Config
; implies we may want aConfig.from_v1
to accompany this?- You'd still potentially need to call both, though could probably state that
Connection.from_v1
implicitly callsConfig.from_v1
internally by default?
- You'd still potentially need to call both, though could probably state that
- Any defaults from v1 that aren't properly
None
or other "empty, not explicitly false" values will be problematic, e.g.use_ssh_config==False
should not necessarily be interpreted as "user wants SSH config files to not be loaded".- Especially annoying for settings that v2 inverted the effective default of, like SSH conf loading
- Some not listed below are skipped because they represent 'missing' features from v2; once those features are ported/implemented, we could expand this.
env
vars of interest:
-
host_string
, just host -
host_string
, user too -
host_string
, port too -
host_string
, all 3 -
always_use_pty
, would setrun.pty
-
forward_agent
can just map to the same exact kwarg -
gateway
can just map to the same exact kwarg, it's a host-string -
- lol nope whoops v1 does extra work here we do not want to replicatekey
wants to becomeconnect_kwargs.pkey
-
key_filename
->connect_kwargs.key_filename
-
- v2 doesn't support it yetkeepalive
probably also goes intoconnect_kwargs
? I forget. -
- that wants to wait for improved roles in v2 for surehosts
might want to be used by, say, aGroup.from_v1
? -
no_agent
->not connect_kwargs.allow_agent
-
password
-> probablyconnect_kwargs.password
only? since in Paramiko it's backwards compat too? -
- wait for per-host config featurepasswords
-> yank out the value mapping to current host_string? -
port
-> straight toport
kwarg -
ssh_config_path
-> same name in v2, at Config level (is not a Cxn kwarg) -
sudo_password
->sudo.password
-
- wait for per-host config featuresudo_passwords
-> yank out the value mapping to current host_string? -
sudo_prompt
->sudo.prompt
-
timeout
->timeouts.connection
-
use_ssh_config
-> config -
user
->user
kwarg -
warn_only
->run.warn