Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Easy creation of v2+ Connection objects from v1 'env' module state #1849
This is another "make it easier to upgrade to v2 piecemeal" feature: with
Brainstorm re: appropriate API:
Thoughts as I run down
added a commit
Aug 19, 2018
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")
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?