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

Start spinner only when the stdout file descriptor is a terminal #131

Merged
merged 1 commit into from Feb 7, 2022

Conversation

dwertent
Copy link
Contributor

@dwertent dwertent commented Feb 7, 2022

No description provided.

@briandowns
Copy link
Owner

Thanks for the addition!

@briandowns briandowns merged commit 16b2c08 into briandowns:master Feb 7, 2022
@mislav
Copy link
Contributor

mislav commented Feb 8, 2022

@briandowns We at GitHub CLI love the spinner library, but I must voice my disappointment with the fact that a massive functional change like this one made it into a patch release (v1.18.1).

@dwertent
Copy link
Contributor Author

dwertent commented Feb 8, 2022

@mislav I had made this patch in my project to prevent the spinner from starting when I wrote to a file. What is the case you want the spinner to start when you are not writing to the stdout? If it is the stderr, I can add that as well...

@theckman
Copy link

theckman commented Feb 8, 2022

@dwertent I think this impacts more than just writing to files. If you ran a task in Jenkins, for example, I believe this change would also prevent the spinner from outputting any information there too, as that's technically not a TTY. There are ways you could use the spinner in that non-TTY setup where the output wouldn't look bad, but now that's been effectively broken that in a patch release.

Not that we need feature parity between the different spinners in our ecosystem, but it might be better to extend this change to behave more like my spinner (yacspin). Specifically this semantic: https://github.com/theckman/yacspin#supporting-non-interactive-tty-output-targets

This allows you to continue supporting folks not running the code within a TTY, while providing a pretty good end user experience.

@mislav
Copy link
Contributor

mislav commented Feb 8, 2022

@dwertent I get what this change does, and I don't blame you for contributing it. I just don't think a functional change should have been a patch release. Since this change is backwards-incompatible (now there is added detection on os.Stdout where before there was none), I would argue this should have been v1.19 or even v2.

@briandowns
Copy link
Owner

@mislav Happy to make adjustments.

@QuLogic
Copy link

QuLogic commented Feb 13, 2022

This also broke tests (PS, you have .travis.yml, but it doesn't run because Travis is dead for all intents and purposes.)

@briandowns
Copy link
Owner

Thanks for pointing that out @QuLogic . I've updated the tests for now and moved to CicleCI. I'll clean things up a bit more tomorrow.

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.

None yet

5 participants