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

WIP Add configuration option to use STDERR for output #217

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

alexanderilyin
Copy link

@ewels is adding config.stderr property similar to other settings is the right way to implement this?

@ewels
Copy link
Owner

ewels commented Dec 5, 2024

Thanks for this @alexanderilyin!

There's already been some discussion around printing to stderr, see #164. If I understand @dwreeves correctly, Click usually prints to stdout for help messages and stderr for error messages. Rich-click aims to emulate this behaviour.

That said, I'd be happy to make this behaviour configurable as long as the default matches Click. So in other words, add a config option as you suggest and make it opt-in.

Does that sound ok?

@alexanderilyin
Copy link
Author

@ewels sound like a plan. Yep I love that rich-click is Plug & Play but for my CLI app I want all human readable things go to STDERR for now, and STDOUT is reserved for programmatic interactions, in other words I don't want JSON in STDOUT be broken due to any other output, and I do need to control exit codes. Note to self: I can grab STDERR as is and internally merge it with JSON from STDOUT on "client" side.

Thanks in advance, I'll put PR sometime this week, cause I don't want to have a fork and all overhead related to it.

@ewels
Copy link
Owner

ewels commented Dec 5, 2024

Yup, the use case sounds valid. Should be simple enough to convert what you have here to something in the config scope, false as default and then you'd just need one line of config in your app to use it.

@alexanderilyin
Copy link
Author

alexanderilyin commented Dec 6, 2024

@ewels one more opt-in feature I want to add is help for arguments. Wonder if any work was happening in that direction. I looked quickly around but seems that there is no support for that yet.

P. S. Currently I can put arguments description in command's doc block, but given show_arguments=True, feature it seems that it should be right to allow set help=... for arguments as well.

@ewels
Copy link
Owner

ewels commented Dec 6, 2024

Yes I've wondered about that in the past. Again it moves us further from the original click syntax so needs some care, but it may well be worth it. Please create an issue for that so we can track it and discuss that there.

@dwreeves
Copy link
Collaborator

dwreeves commented Dec 7, 2024

Help for arguments is something I'm thinking about for 1.9. I'm personally open to it. If you'd like to take it on then that works.

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

Successfully merging this pull request may close these issues.

3 participants