Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Separation of local vs remote lowercase-C contexts (for cd, prefix, run/local, etc) #1752
(Cannot find an old ticket for this :( thought there was one...)
Fabric 1 had
Invoke only has the one local context and doesn't care.
Fabric 2 inherits from Invoke but failed to grow distinct remote-vs-local APIs before 2.0 (besides the much earlier implementation of "move Invoke's
This needs solving and I assume in the obvious fashion, i.e. growing new API members (named explicitly either after local or remote) and the appropriate state storage (on Connection or in config).
This will sadly be a backwards compatibility break (insofar as
This is strongly related to #1686 which is for the run-vs-local config divergence.
#1858 brings up one possible angle on the run-vs-local side of things, namely adding a
I think we still want to reject this approach, as it sullies Invoke and doesn't entirely solve the issue (we're still gonna have problems with things like
I also do still think (at this point in time, months later) that #1755's approach may be the only sensible way forward, tho I have to reread it and give a harder think on any other obvious APIs that come to mind. But having the two sides of the conversation as discrete API objects seems hard to beat for explicitness. It's just gonna be hard to wrangle re: backwards compatibility (& if put out in a backwards compat fashion it'll introduce extra confusion; however given there's already a lot of confusion around this......)
Had an idea.. it might be possible to maintain compatibility at the executor level. In #1755,
The question then is whether or not it's worth the added complexity and whether or not this behavior will confuse users. IDK if this might be too "clever". Worth trying - can always dump the changes.
I'd suggest replacing the "Connection" object with a multi-context: FabricContext.
By default FabricContext would delegate all Context API calls to its remote (fabric
This is a very similar proposal to #1755, but drops the necessity to support two separate APIs. The
Moreover, this opens up the possibility of supporting multiple remotes in a single Context without hacky modifying of 'host' dynamically.