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

Separation of local vs remote lowercase-C contexts (for cd, prefix, run/local, etc) #1752

Open
bitprophet opened this Issue May 14, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@bitprophet
Member

bitprophet commented May 14, 2018

(Cannot find an old ticket for this :( thought there was one...)

Fabric 1 had with cd: and with lcd: and similar dual APIs for users that needed to track context-y state (cwd, prefixes list etc) differently for the remote vs local ends.

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 run to Fabric 2's local", which presents its own set of problems around "what kind of Context am I dealing with right now and what methods does it have?").

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 with c.cd() currently changes both ends and will revert to changing only one) but the software's only been out a week and I think we can argue that this was a bug. Otherwise it'll be the shortest lived major version number ever 😐

This is strongly related to #1686 which is for the run-vs-local config divergence.

@rpkilby

This comment has been minimized.

Show comment
Hide comment
@rpkilby

rpkilby May 14, 2018

Contributor

Hi @bitprophet - were you thinking of #1637?

Contributor

rpkilby commented May 14, 2018

Hi @bitprophet - were you thinking of #1637?

@bitprophet bitprophet changed the title from Separation of local vs remote lowercase-C contexts (for cd, prefix, etc) to Separation of local vs remote lowercase-C contexts (for cd, prefix, run/local, etc) May 14, 2018

@bitprophet

This comment has been minimized.

Show comment
Hide comment
@bitprophet

bitprophet Jun 22, 2018

Member

#1637 got rebased into #1755, FTR. And I still have to doublecheck whether that approach works for me or not!

Member

bitprophet commented Jun 22, 2018

#1637 got rebased into #1755, FTR. And I still have to doublecheck whether that approach works for me or not!

@rpkilby

This comment has been minimized.

Show comment
Hide comment
@rpkilby

rpkilby Jun 22, 2018

Contributor

Yep. There is still some work to be done on #1755, but it's in a state where it and it's sibling PR for invoke can be reviewed/discussed.

Contributor

rpkilby commented Jun 22, 2018

Yep. There is still some work to be done on #1755, but it's in a state where it and it's sibling PR for invoke can be reviewed/discussed.

@bitprophet

This comment has been minimized.

Show comment
Hide comment
@bitprophet

bitprophet Aug 22, 2018

Member

#1858 brings up one possible angle on the run-vs-local side of things, namely adding a local to invoke.Context so that the two APIs resemble one another more closely.

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 cd, or any new API members either side of the equation adds later).

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......)

Member

bitprophet commented Aug 22, 2018

#1858 brings up one possible angle on the run-vs-local side of things, namely adding a local to invoke.Context so that the two APIs resemble one another more closely.

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 cd, or any new API members either side of the equation adds later).

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......)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment