New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Easy creation of v2+ Connection objects from v1 'env' module state #1849
Comments
Been using this for a while internally with just host-string/key-filename; time to polish it up and release it. Want to get more of the checklist ticked off, though I am still going to punt on anything too complex. Intent is to have it Just Work for the average user while not spending forever in a rabbit hole. |
Some boolean settings whose values flipped in v2, like
My initial thought here was to just mark these as "not supported" and not port them, because I assumed the obvious desired behavior here is to move to the new, v2 default behaviors (e.g. pty off, ssh config on). However I'm now wondering: maybe USING the v1 defaults makes more sense? If one is truly attempting to get a v2 Connection obj that "feels like" their v1 setup, they'd WANT whatever the v1 defaults were? A counter-counterpoint might be that they'll be set up for a nasty surprise once they finally do away with their v1 code and switch from I think given that I'm torn, it still makes more sense to skip those for the time being, and then if enough users say they felt that preserving that behavior was what they were expecting, we can "add" them in. It's harder to remove it in the opposite scenario. |
I keep waffling though. Writing out the explanation for this in the docs just feels bad and overly complicated. What are the use cases in my head for this? My default one was my own: writing new v2-using code inside a legacy codebase (to avoid making more work for a planned future migration of existing code to v2). In this scenario, I want things like pty/ssh_config to "feel like" v2, because it is new code I am writing from scratch. But I bet at least as many, if not more, users would use this to port existing v1 using code to v2, for example turning this: run("blah")
sudo("seriously, please blah")
put("file") into this: c = Connection.from_v1()
c.run("blah")
c.sudo("seriously, please blah")
c.put("file") in which case, having So I'm gonna go with "rock the boat less" for now. |
Grumble, ran into a stumbling block: so far, I've been dealing with data that is pertinent to Connection itself, like user/host/port or connect_kwargs members. But some things, like Clearly, we cannot modify I seem to have missed writing it down, but I now recall earlier thinking we might need another analogue to The only use case this doesn't seem to serve well is when users are trying to merge a config handed to them from elsewhere (eg a vanilla Invoke or host-less Fabric CLI+ |
A few days removed, I find that I implemented Suspect it's to do with my internal usage needs or something, but regardless, it just seems so unintuitive & so hard to work around (how is a user supposed to slowly start migrating away from that v1 env for any settings that conflict?) I'm gonna try reversing it to see what, if anything, breaks on my end. At the least, if that happens & I remember what made it seem sensible, I can record it in the warning block and here... |
OK, basically everything obvious has been set up to be pulled into Going to just drop the automagic "does the import for you" for now, if people complain about needing one extra (or modified) import line and one explicit value reference, I feel like maybe they'd have trouble with almost any API? |
After spending waaaay too much time wrestling with Travis, I got a v1-and-v2-at-same-time sanity check working there too. (You could say the sanity check cost my my sanity…) This is |
And what do you do with the |
This is another "make it easier to upgrade to v2 piecemeal" feature: with
fabric
andfabric2
both imported, create afabric2.Connection
from one's currentfabric.state.env
contents.TODO
Thoughts
Brainstorm re: appropriate API:
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?from fabric.api import env
? Convenient but very fragileConnection.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.Thoughts as I run down
env
:Config
; implies we may want aConfig.from_v1
to accompany this?Connection.from_v1
implicitly callsConfig.from_v1
internally by default?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".env
vars of interest:host_string
, just hosthost_string
, user toohost_string
, port toohost_string
, all 3always_use_pty
, would setrun.pty
forward_agent
can just map to the same exact kwarggateway
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
kwargssh_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
-> configuser
->user
kwargwarn_only
->run.warn
The text was updated successfully, but these errors were encountered: