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

ARGV cleanup: Deprecate ARGV methods that are never used internally #5762

Closed
wants to merge 5 commits into from

Conversation

BenMusch
Copy link
Contributor

@BenMusch BenMusch commented Feb 17, 2019

  • 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 tests with your changes locally?

Addresses part of #5730

This PR deletes ARGV methods which are never used internally in ARGV (for example, it keeps build_head? because it is used in build_stable?, and refactoring methods which have internal usage is a bit more complex of a question in terms of how it is refactored. Will definitely look into cleaning that up later, but wanted to open this PR for all the work which could be done without too much thought

cc_arg = "--cc=clang"
ARGV << cc_arg
expect(Homebrew.args.cc).to be nil
allow(Homebrew.args).to receive(:cc).and_return("clang")
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just wanna make sure: This is a valid replacement in tests for adding values to ARGV, right?

Copy link
Member

Choose a reason for hiding this comment

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

Yep 👍

@@ -47,7 +48,7 @@
end

it "ignores bogus Python error" do
ENV["HOMEBREW_VERBOSE"] = "1"
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same here: Wanna make sure it's okay to replace env var values with Homebrew.args stubs

Copy link
Member

Choose a reason for hiding this comment

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

Yep 👍

@BenMusch
Copy link
Contributor Author

BenMusch commented Feb 17, 2019

Not really sure I follow why tests are failing (brew tests passes locally), but it definitely seems like it may be related to my changes. Looks like brew test bot might have to be updated? https://github.com/Homebrew/homebrew-test-bot/blob/master/cmd/brew-test-bot.rb#L274 If so, are there any other packages this might affect?

@MikeMcQuaid
Copy link
Member

@scpeters
Copy link
Contributor

Also https://github.com/Homebrew/homebrew-livecheck

Perhaps we could deprecate these old methods to give downstream taps a chance to notice the changes (see #5477 for an example). Then we could merge this without being blocked or breaking homebrew commands in external taps.

@MikeMcQuaid
Copy link
Member

Perhaps we could deprecate these old methods to give downstream taps a chance to notice the changes (see #5477 for an example).

This seems like a good call 👍 . For those that we notice have been used anywhere outside Homebrew/brew an odeprecated and odisabled make sense before their removal. For consistency they could also call back to Homebrew.args.foo rather than querying ARGV.foo directly.

@BenMusch
Copy link
Contributor Author

Looks like the deprecations are still failing the build -- should I be doing this differently? https://dev.azure.com/Homebrew/Homebrew/_build/results?buildId=4180

@BenMusch BenMusch changed the title ARGV cleanup: Replace ARGV methods that are never used internally ARGV cleanup: Deprecate ARGV methods that are never used internally Feb 17, 2019
@jonchang
Copy link
Contributor

jonchang commented Feb 18, 2019

Looks like the deprecations are still failing the build -- should I be doing this differently? https://dev.azure.com/Homebrew/Homebrew/_build/results?buildId=4180

The issue is in https://github.com/Homebrew/homebrew-test-bot/, not your pull request.

I believe you'll have to do the pull request in several parts: first to add the new API, then a pull request to test-bot to use the new API, then the deprecations in a final pull request to deprecate the old API. Probably a pull request to homebrew-core fixing all uses of the old API should be in there somewhere as well. brew test-bot runs with HOMEBREW_DEVELOPER=1 set I believe so warnings (including deprecations) become errors.

Longer term we should probably look at moving the homebrew/test-bot code into homebrew/brew.

@jonchang
Copy link
Contributor

Actually it looks like you're not adding any new APIs here, just deprecating old ones. So a pull request to homebrew-test-bot fixing its calls should be sufficient.

@BenMusch
Copy link
Contributor Author

Ah thanks @jonchang! Didn't see the line about throwing an error when homebrew_developer? is true. Opened a PR to change the test-bot: Homebrew/homebrew-test-bot#238

@MikeMcQuaid
Copy link
Member

@BenMusch Some failing tests but not brew test-bot any more 🎉

@MikeMcQuaid
Copy link
Member

Cross-posting from Homebrew/homebrew-test-bot#240:

I would suggest making use of ARGV.freeze to catch these cases (both here and in Homebrew/brew) and fix/refactor them before any more ARGV to Homebrew.args conversion is done.

@BenMusch
Copy link
Contributor Author

BenMusch commented Feb 18, 2019

@MikeMcQuaid should we also find a way to prevent modification of ENV (hopefully without interfering with anything non-argv-related values), since Homebrew.args values are also controlled by that?

@MikeMcQuaid
Copy link
Member

@MikeMcQuaid should we also find a way to prevent modification of ENV (hopefully without interfering with anything non-argv-related values), since Homebrew.args values are also controlled by that?

@BenMusch Good question. I don't believe there are (m)any cases where ENV is overridden and the expectation is that ARGV.whatever? will change so we're fine from that perspective. Also, we relatively often need to modify ENV for subprocesses so I think we're left with what we have for now (without introducing a new API for ENV which also updates CLI::Parser which I think would be overkill for now).

@BenMusch
Copy link
Contributor Author

Sounds good. Just posting this as a heads up: probably won't be able to make progress on the PR for a week or so due to some schoolwork that's come up. But definitely intend on getting back to it once I'm free

@MikeMcQuaid
Copy link
Member

No worries, thanks @BenMusch!

@BenMusch
Copy link
Contributor Author

BenMusch commented Mar 6, 2019

Just a heads up: Busier with schoolwork than I thought so it might not be a while until I pick this up again. Will check-in periodically to keep the PR up-to-date with master, and anyone who wants to take over the work on this should feel welcome to if my timeliness becomes an issue!

@MikeMcQuaid
Copy link
Member

@BenMusch Would you be able to extract the minimal version that still passes tests (perhaps into a new PR)? Thanks!

@BenMusch
Copy link
Contributor Author

BenMusch commented Mar 6, 2019

@MikeMcQuaid Definitely, would a minimal version of this be: not deprecating existing methods, and only changing the ARGV.* to Homebrew.args.* when it doesn't result in test failures?

@scpeters
Copy link
Contributor

scpeters commented Mar 6, 2019

would a minimal version of this be: not deprecating existing methods, and only changing the ARGV.* to Homebrew.args.* when it doesn't result in test failures?

that sounds good to me

@stale
Copy link

stale bot commented Mar 27, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@stale stale bot added the stale No recent activity label Mar 27, 2019
@stale stale bot closed this Apr 3, 2019
@lock lock bot added the outdated PR was locked due to age label May 3, 2019
@lock lock bot locked as resolved and limited conversation to collaborators May 3, 2019
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 stale No recent activity
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants