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

fix(vendor-gems): redirect bundler stdout to stderr #11479

Merged
merged 1 commit into from
Jun 3, 2021

Conversation

gibfahn
Copy link
Contributor

@gibfahn gibfahn commented Jun 2, 2021

  • Have you followed the guidelines in our Contributing document?
  • Have you checked to ensure there aren't other open Pull Requests for the same change?
  • Have you added an explanation of what your changes do and why you'd like us to include them?
  • Have you written new tests for your changes? Here's an example.
  • Have you successfully run brew style with your changes locally?
  • Have you successfully run brew typecheck with your changes locally?
  • Have you successfully run brew tests with your changes locally?

I didn't add a test for this as I wasn't sure we wanted to be running a full bundle install for a single test, let me know if there's a good way to test this.


Commits (oldest to newest)

11b3266fd fix(vendor-gems): redirect bundler stdout to stderr

When running brew commands and interpreting the output, e.g. running
brew livecheck --json, it's necessary to stop other programs Homebrew
happens to execute from writing logging output to stdout. Most programs
don't do this, but bundle install does seem to.

To reproduce the issue you can run:

git -C "$(brew --prefix)" clean -ffdx Library/Homebrew/vendor
stdout=$(HOMEBREW_FORCE_VENDOR_RUBY=1 brew livecheck --newer-only --json --cask $(brew --repo homebrew/cask)/Casks/grid.rb)
echo "^^^ was stderr, >>> is stdout: $stdout"

If you run it without this change it will print a bunch of output like
this to the stdout before printing out the livecheck JSON output:

Using bundler 1.17.3
Fetching byebug 11.1.3
Fetching coderay 1.1.3
Installing byebug 11.1.3 with native extensions
Installing coderay 1.1.3
Fetching colorize 0.8.1
Installing colorize 0.8.1

[
  # Contents of the JSON block.
]

With this change the stdout from bundle install will be redirected to
brew's stderr, meaning only the JSON goes to stdout, and the rest goes
to stderr.


Comment on lines 147 to 152
unless system_redirect_stdout_to_stderr bundle, "install"
message = <<~EOS
failed to run `#{bundle} install`!
EOS
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I erred on the side of making the minimal changes here, but I believe if we changed this to:

Suggested change
unless system_redirect_stdout_to_stderr bundle, "install"
message = <<~EOS
failed to run `#{bundle} install`!
EOS
begin
safe_system_redirect_stdout_to_stderr bundle, "install"
rescue ErrorDuringExecution =>
message = <<~EOS
failed to run `#{bundle} install`!
EOS

then we could get rid of the system_redirect_stdout_to_stderr and just use the safe_ one everywhere. Not sure if this is preferable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did this ^

@gibfahn gibfahn force-pushed the redirect_stdout branch 2 times, most recently from b514c8f to 11b3266 Compare June 2, 2021 10:53
Copy link
Member

@MikeMcQuaid MikeMcQuaid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work so far! Totally agree with the intent here, good shout 👏🏻

@@ -40,7 +40,7 @@ def vendor_gems
end

ohai "bundle install --standalone"
safe_system "bundle", "install", "--standalone"
safe_system_redirect_stdout_to_stderr "bundle", "install", "--standalone"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about using these methods just to be used in a single place each (unless you have other ideals). I'd be tempted to just inline the methods?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah agreed that two single-use methods are overkill. I went with combining into one method, that is now used in both places. I suspect there are other invocations of bundler or other tools that would need this, so having a function for it seems probably worth it, what do you think?

When running brew commands and interpreting the output, e.g. running
`brew livecheck --json`, it's necessary to stop other programs Homebrew
happens to execute from writing logging output to stdout. Most programs
don't do this, but `bundle install` does seem to.

To reproduce the issue you can run:

```shell
git -C "$(brew --prefix)" clean -ffdx Library/Homebrew/vendor
stdout=$(HOMEBREW_FORCE_VENDOR_RUBY=1 brew livecheck --newer-only --json --cask $(brew --repo homebrew/cask)/Casks/grid.rb)
echo "^^^ was stderr, >>> is stdout: $stdout"
```

If you run it without this change it will print a bunch of output like
this to the stdout before printing out the livecheck JSON output:

```text
Using bundler 1.17.3
Fetching byebug 11.1.3
Fetching coderay 1.1.3
Installing byebug 11.1.3 with native extensions
Installing coderay 1.1.3
Fetching colorize 0.8.1
Installing colorize 0.8.1

[
  # Contents of the JSON block.
]
```

With this change the stdout from `bundle install` will be redirected to
brew's stderr, meaning only the JSON goes to stdout, and the rest goes
to stderr.
@MikeMcQuaid
Copy link
Member

Looks good, nice work here @gibfahn!

@MikeMcQuaid MikeMcQuaid merged commit 654c78c into Homebrew:master Jun 3, 2021
@gibfahn gibfahn deleted the redirect_stdout branch June 3, 2021 12:01
@github-actions github-actions bot added the outdated PR was locked due to age label Jul 4, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 4, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
outdated PR was locked due to age
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants