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

Support JSON response when tagging #29

Closed
advplyr opened this issue Sep 25, 2022 · 3 comments
Closed

Support JSON response when tagging #29

advplyr opened this issue Sep 25, 2022 · 3 comments

Comments

@advplyr
Copy link

advplyr commented Sep 25, 2022

When tagging there is only a response to be used in a CLI.

Also, when the tag fails there is no way to check if the tag failed since everything is written to stdout.

@sandreas
Copy link
Owner

That`s a good point. I'll see what I can do here.

@sandreas
Copy link
Owner

sandreas commented Feb 15, 2023

@advplyr
So I started to implement this yesterday and the following questions came up:

  • What would you expect, when a file is tagged with parameters, that do not change anything?
    • No output at all
    • Full output
  • Would you expect the full metadata information result after tagging or only patch information?
  • What would you expect on errors besides return code different from 0? (e.g. file cannot be updated, disk full, etc.)
    • No output at all
    • No output on stdout, error message on stderr

My current implementation plan is:

  • no changes => no output
  • never a full result, only patch information (its better to see what changed then getting bombed with information)
  • error with return code > 0 and output error message on stderr (stderr can be ignored in wrappers, but at least you may understand the problem)

The patch plan is not ready yet and maybe change to full result because I have to check a library that offers the JsonDiff stuff... I would also use the "NON RFC" Patch variant, although I love RFCs it is not helpful to see what operations must be applied in the terminal but only the "changeset"...

@advplyr
Copy link
Author

advplyr commented Feb 15, 2023

@advplyr So I started to implement this yesterday and the following questions came up:

  • What would you expect, when a file is tagged with parameters, that do not change anything?

Having some indication that the process executed is helpful. I'm not sure what that would be though, so as long as the exit code is 0 and nothing is returned then I can work with that.

  • Would you expect the full metadata information result after tagging or only patch information?

I think it is perfectly fine to return the full metadata information. For Abs when applying the updates to objects we will be comparing the new details with the old ones anyway.

However, returning just the patched information is probably more friendly to other clients.

If it saves you from including another package in the library then I would say just return the full metadata.

  • What would you expect on errors besides return code different from 0? (e.g. file cannot be updated, disk full, etc.)

No output on stdout and error message in stderr. Ideally the error message is something I could show the user.

If you have more complete error data then that would require a JSON object.
Like some APIs return a user-friendly message and a more verbose message for the devs, but I doubt that is necessary here.

My current implementation plan is:

  • no changes => no output
  • never a full result, only patch information (its better to see what changed then getting bombed with information)
  • error with return code > 0 and output error message on stderr (stderr can be ignored in wrappers, but at least you may understand the problem)

The patch plan is not ready yet and maybe change to full result because I have to check a library that offers the JsonDiff stuff... I would also use the "NON RFC" Patch variant, although I love RFCs it is not helpful to see what operations must be applied in the terminal but only the "changeset"...

This plan works for me. Abs doesn't need the patch information necessarily so the full metadata is also fine.

Thanks for working on this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants