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

Gracefully initialize/auto-detect behind the scenes? #20

Closed
epage opened this issue May 11, 2021 · 3 comments
Closed

Gracefully initialize/auto-detect behind the scenes? #20

epage opened this issue May 11, 2021 · 3 comments

Comments

@epage
Copy link

epage commented May 11, 2021

For a CLI app, the user will need to support args and might have other constraints.

However, passing color information to a deeply nested crate can be impractical. For example, Someone might use mockall which uses predicates which uses difference, and difference wants to print colored diffs, where appropriate.

Alternatively, some times there isn't a good initialization point for a crate, like with tests. The above example is more likely to live in a test than in a bin.

Depending on the approach, this might be a counter example to #17.

Note: this is more brainstorming, I'm unsure how this will look.

@SergioBenitez
Copy link
Owner

I don't think we should make any decisions for the user here. They should be able to (or be able not to) conform to any standard or non-standard they want. But I don't quite understand your example. Can you be specific, perhaps with code?

@epage
Copy link
Author

epage commented Jun 14, 2021

Let's break apart the users involved

  • User running a program
  • Program author
  • Test crate author

Ultimately, the color policy is left for the program author to decide but generally will follow a standard the user running the program expects.

Now, a crate author might try to make testing easier, and want colored output to help, like pretty_assertions. The program author would then be using this as part of their testing. The user running the program never sees this.

Options for test tool crates, like pretty_assertions

  • Hard code colors on
  • Put colors behind a feature flag
  • Use a once_cell to call color detection code and store the value

Rather than every test crate handling this on their own, what if we provided a feature flag that had logic from #18 in it and would ensure we do the "right thing" in these cases.

@SergioBenitez
Copy link
Owner

I don't think conforming to a variety of standards should be yansi's prerogative. I don't want yansi to be opinionated here: I want it to fit every use-case. If another crate wants to provide utilities that conform to these standards, then that's totally great. But I think we should leave it to other crates.

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