Skip to content
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

CLI and API command output encoding #215

Draft
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

jbouwman
Copy link

@jbouwman jbouwman commented Aug 19, 2021

Following the approach described in #115, define a new method signature on Command that supports full processing of the Response object when text encoding is requested.

Add an encoding check and dispatch to DisplayCLI in local, http client, and http handler code paths.

Unblocks resolution of encoding option processing in multiple go-ipfs issues.

Closes #115

@welcome

This comment has been minimized.

@jbouwman jbouwman marked this pull request as ready for review August 21, 2021 18:58
@BigLep BigLep requested a review from lidel September 3, 2021 15:12
Copy link
Member

@Stebalien Stebalien left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for implementing this, it's been bugging me for a while... And thanks for making it possible to incrementally switch over, that'll make this much easier to land.

executor.go Outdated Show resolved Hide resolved
http/responseemitter.go Outdated Show resolved Hide resolved
http/client.go Outdated Show resolved Hide resolved
executor.go Outdated Show resolved Hide resolved
@Stebalien
Copy link
Member

Sorry for the very slow response, things that touch this library tend to be scary so I tend to procrastinate. This looks quite reasonable, so I'll be sure to make future review cycles shorter.

@jbouwman
Copy link
Author

jbouwman commented Sep 7, 2021

Sorry for the very slow response, things that touch this library tend to be scary so I tend to procrastinate. This looks quite reasonable, so I'll be sure to make future review cycles shorter.

No worries whatsoever. Thanks very much for the review.

Following the approach described in ipfs#115, define a new method signature on `Command` that supports full processing of the `Response` object when text encoding is requested.

Add an encoding check and dispatch to DisplayCLI in local, http client, and http handler code paths.

Unblocks resolution of `encoding` option processing in multiple go-ipfs issues.

- ipfs/kubo#7050 json encoding for `ls`
- ipfs/kubo#1121 json encoding for `add`
- ipfs/kubo#5594 json encoding for `stats bw`
- When both PostRun (output transformer) and DisplayCLI (terminal output) are present, ensure that both are run.

`EmitResponse` helper in executor.go is invoked by both local and HTTP client executors: the client fibs the command.Run interface via anonymous function.
executor.go Show resolved Hide resolved
@djdv
Copy link
Contributor

djdv commented Sep 20, 2021

Sorry for the conflicts (;´∀`)
Just as a heads up, feel free to keep or clobber whatever variable/function names were used in #216 and #217
The names don't matter compared to the fix itself, so the choice is yours when resolving the conflict.

Also, if this gets merged #219
it'll introduce another one. In cli.Run for this line if encType == cmds.Text && !cmd.HasText() {
If the linked PR is correct, you should be able to just drop the conflicting hunk in this PR when that happens.
(No guarantees that I'm right on that though, or that it gets merged in - but if so I see that you already handle this in cli.Parse too if req.Command.HasText() { )

^ Not worth it.

I'll try not to create any more trouble ;^)

Copy link
Member

@lidel lidel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resolved conflicts. ✨

It seems #215 (comment) the only remaining question / concern – @jbouwman mind taking a look at @Stebalien's question?

@lidel lidel added the need/author-input Needs input from the original author label Sep 23, 2021
Close the channel immediately if it will never be used.
@jbouwman
Copy link
Author

Resolved conflicts. sparkles

It seems #215 (comment) the only remaining question / concern – @jbouwman mind taking a look at @Stebalien's question?

@lidel sure thing, done. @Stebalien does that look right, in terms of order of error checks?

executor.go Show resolved Hide resolved
@Stebalien
Copy link
Member

does that look right, in terms of order of error checks?

Yes. But I missed the other thing.

@jbouwman
Copy link
Author

does that look right, in terms of order of error checks?

Yes. But I missed the other thing.

I had cycles to look at this again. The cli.ResponseEmitter wrapper for DisplayCLI seems a little odd -- its main role seems to be in allowing PostRun-enabled commands access to process exit value via a cast. I didn't see a less invasive way to do it though. I'd welcome your thoughts.

@BigLep BigLep requested a review from Stebalien October 1, 2021 15:15
@BigLep BigLep removed the need/author-input Needs input from the original author label Oct 1, 2021
Copy link
Member

@Stebalien Stebalien left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me think about this a bit.

stdout io.Writer
stderr io.Writer

re cmds.ResponseEmitter
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can embed this instead of manually forwarding.

go func() {
err := req.Command.DisplayCLI(res, os.Stdout, os.Stderr)
if err != nil {
dre.CloseWithError(err)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm. This isn't going to work:

  1. The caller will send an error to dre via CloseWithError.
  2. DisplayCLI will get this error from res, and return it.
  3. We're then going to feed it back into dre here.

Really, we need to expose this error via some method and/or a channel. I'll try to think of the right approach.

Comment on lines +67 to +90
func (dre *displayResponseEmitter) SetLength(l uint64) {
dre.re.SetLength(l)
}

func (dre *displayResponseEmitter) SetStatus(code int) {
dre.l.Lock()
defer dre.l.Unlock()
dre.exit = code
}

func (dre *displayResponseEmitter) Status() int {
dre.l.Lock()
defer dre.l.Unlock()
return dre.exit
}

func (dre *displayResponseEmitter) Stderr() io.Writer {
return dre.stderr
}

func (dre *displayResponseEmitter) Stdout() io.Writer {
return dre.stdout
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can actually just drop these methods from the interface. But it'll require some investigation.

@aschmahmann aschmahmann added need/analysis Needs further analysis before proceeding kind/enhancement A net-new feature or improvement to an existing feature labels Oct 8, 2021
@BigLep
Copy link

BigLep commented Nov 12, 2021

@Stebalien : what are the recommended next steps? Is this high enough priority for us to engage on right now?

@BigLep BigLep requested a review from Stebalien March 3, 2022 13:44
@BigLep BigLep assigned jbouwman and unassigned Stebalien Mar 3, 2022
@BigLep
Copy link

BigLep commented Mar 3, 2022

@jbouwman : it looks like there are some comments from @Stebalien that you can incorporate (but I see there are open questions too).

@Stebalien : are you able to give definitive on what should be done here, or should we drop this for now due to not having bandwidth to engage?

@BigLep BigLep added this to the Best Effort Track milestone Mar 10, 2022
@BigLep BigLep marked this pull request as draft March 10, 2022 07:58
@BigLep
Copy link

BigLep commented Mar 10, 2022

@jbouwman : I have converted this back to draft. Please mark it as "Ready for review" when comments have been incorporated.

@Stebalien
Copy link
Member

are you able to give definitive on what should be done here, or should we drop this for now due to not having bandwidth to engage?

I just don't have the bandwidth right now, unfortunately.

@BigLep BigLep added need/author-input Needs input from the original author and removed need/analysis Needs further analysis before proceeding labels May 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement A net-new feature or improvement to an existing feature need/author-input Needs input from the original author
Projects
No open projects
Status: 🥞 Todo
Development

Successfully merging this pull request may close these issues.

PostRun is an awkward fit for CLI output
6 participants