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

IO managment #633

Open
jkthorne opened this issue May 18, 2021 · 3 comments
Open

IO managment #633

jkthorne opened this issue May 18, 2021 · 3 comments

Comments

@jkthorne
Copy link
Contributor

I think we should include a standard IO management for all the CLI commands. This might be able to be pulled into the core Lucky lib. I have built a few CLIs in Crystal now and I have been doing IO managment and think I have found a suitable pattern since there is no default CLI framework in Crystal.

I think we should have three methods accessible to the CLI commands input_io, data_io, and human_io. This makes it very easy to check input_tty? and only output the IO you actually need. This more conforms to UNIX style programs and lucky easier to use with other linux tools.

@jwoertink
Copy link
Member

I like that idea. We sort of started going that path. The main thing is when the CLI has any output, or specific errors, we need to be able to test that the output matches what we expect, or the errors contain the proper error message.

The other thing I'd like to do is unify the error messages for these. Like displaying the difference between UX error (i.e. "You must include X, but you did not"), and an exception (i.e. "Overload missing for Type Whatever"). These are sort of mixed right now.

@matthewmcgarvey
Copy link
Member

This should probably be transferred over to https://github.com/luckyframework/lucky_task

@jkthorne
Copy link
Contributor Author

Looking through the CLI I think there are multiple places this could go.

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

3 participants