Skip to content

Easy creation of v2+ Connection objects from v1 'env' module state #1849

Closed
@bitprophet

Description

@bitprophet

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 than from_module as env 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...

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 a Config.from_v1 to accompany this?
    • You'd still potentially need to call both, though could probably state that Connection.from_v1 implicitly calls Config.from_v1 internally by default?
  • 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 set run.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
  • key wants to become connect_kwargs.pkey - lol nope whoops v1 does extra work here we do not want to replicate
  • key_filename -> connect_kwargs.key_filename
  • keepalive probably also goes into connect_kwargs? I forget. - v2 doesn't support it yet
  • hosts might want to be used by, say, a Group.from_v1? - that wants to wait for improved roles in v2 for sure
  • no_agent -> not connect_kwargs.allow_agent
  • password -> probably connect_kwargs.password only? since in Paramiko it's backwards compat too?
  • passwords -> yank out the value mapping to current host_string? - wait for per-host config feature
  • port -> straight to port kwarg
  • ssh_config_path -> same name in v2, at Config level (is not a Cxn kwarg)
  • sudo_password -> sudo.password
  • sudo_passwords -> yank out the value mapping to current host_string? - wait for per-host config feature
  • sudo_prompt -> sudo.prompt
  • timeout -> timeouts.connection
  • use_ssh_config -> config
  • user -> user kwarg
  • warn_only -> run.warn

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions