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

feat(cast): add an unformatted output mode #6600

Open
Tracked by #8794
CodeSandwich opened this issue Dec 14, 2023 · 6 comments
Open
Tracked by #8794

feat(cast): add an unformatted output mode #6600

CodeSandwich opened this issue Dec 14, 2023 · 6 comments
Assignees
Labels
C-cast Command: cast T-feature Type: feature
Milestone

Comments

@CodeSandwich
Copy link
Contributor

CodeSandwich commented Dec 14, 2023

Component

Other (please describe)

Describe the feature you would like

Foundry is a great tool for running operations manually, but it's sometimes problematic to automate. The main problem is the output format, it's tailored for reading, so it often needs extra processing, and it sometimes changes to further improve readability. Some examples of problems I've encountered when writing scripts using foundry:

  • cast call to a function returning a string prints its value in quotes, which need to be stripped
  • cast call to a function returning a number may or may not print the output twice, the second time in the scientific notation (see cast call returns integers in scientific notation #6598)
  • forge create prints the whole deployment report with the transaction hash, the deployer address and the compilation result, but scripts usually only need the deployed address, which needs to be extracted

It would be great to have a mode that would keep the output simple and stable for the automation, with no decorations for easier reading.

Some commands have the --json option, for example forge create. It's inconvenient, because it requires piping the output through a jq script, but it's a viable workaround. This option isn't available everywhere, for example cast call doesn't support it.

Additional context

No response

@CodeSandwich CodeSandwich added the T-feature Type: feature label Dec 14, 2023
@mds1
Copy link
Collaborator

mds1 commented Dec 14, 2023

I agree cast in general needs some cleanup, I suspect there's a lot of other inconsistencies. To start, I think the default return values from cast call should never have quotes, and when there's multiple data it should be comma-separated or in some other machine-friendly format. As we do with other commands like forge inspect, we can add a --pretty or --verbose flag to get more human friendly output

@CodeSandwich
Copy link
Contributor Author

I think that the defaults should be human friendly, as it is now. When the user manually executes a command, they probably won't remember, won't bother to type or simply won't have the knowledge to add the extra parameter, and they will be stuck with the unfriendly output. Scripts on the other hands are written with more care and preparation, and usually only once, so adding a flag won't be that annoying.

@mds1
Copy link
Collaborator

mds1 commented Dec 14, 2023

I think that the defaults should be human friendly, as it is now.

I don't feel strongly here, but AFAIK this was a breaking change which is why it should be reverted. Once we have a v1, we can make the default change to human friendly at that point. Other commands like forge inspect currently default to non-prettified outputs and require --pretty, and consistency between commands is the least surprising UX

@Inphi
Copy link
Contributor

Inphi commented Dec 14, 2023

In general, tools should default to use --pretty, otherwise humans have to add that flag every time in a cli. Whereas in a script, the human only has to specify --raw once.
So I'd go as far as to modify forge inspect to be --pretty by default. But also in favor of maintaining consistency, if that isn't desired, by adding a --pretty option for cast commands.

@mds1
Copy link
Collaborator

mds1 commented Dec 14, 2023

Agreed that human readable is a better default, but will defer to forge maintainers if they're ok with the pre-v1 breaking change that would be required to keep consistency across commands

@zerosnacks
Copy link
Member

Adding this ticket to #8794

--json will me made available as a flag for consistent serialized output throughout Foundry with the expectation it can easily be parsed line by line with | jq

If you see specific areas that are lacking or run into issues please let me know

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-cast Command: cast T-feature Type: feature
Projects
Status: Todo
Development

No branches or pull requests

4 participants