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

dev-cmd/edit: Move path specific functions to Pathname #16029

Merged
merged 16 commits into from
Sep 27, 2023

Conversation

abitrolly
Copy link
Contributor

@abitrolly abitrolly commented Sep 24, 2023

This PR reduces edit.rb complexity to solve #16015.

  1. Moves to Pathname the logic that checks if the path is core tap, cask or formula.
  2. Moves failure handler when path does not exist into separate method.

This makes the code easier to read to fix the name conflict between formula and existing directory.

  • 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?

@abitrolly
Copy link
Contributor Author

CI fails with Style/Next: Use next to skip iteration. (https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/Next), but if I autofix it, it becomes Style/UnlessLogicalOperators, which is unfixable. What to do?

@abitrolly abitrolly marked this pull request as ready for review September 24, 2023 19:31
Library/Homebrew/dev-cmd/edit.rb Outdated Show resolved Hide resolved
Library/Homebrew/extend/pathname.rb Outdated Show resolved Hide resolved
@apainintheneck
Copy link
Contributor

Thinking about this a little more I think we should check that the paths are valid before checking to see if we want to print the install warning.

@abitrolly
Copy link
Contributor Author

Thinking about this a little more I think we should check that the paths are valid before checking to see if we want to print the install warning.

@apainintheneck moved path validation before checking for warning message. The code for error message is also in a new method, so the logic should be even more readable now.

The last two offences are not easy to fix, though.

 /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/dev-cmd/edit.rb:92:7: C: Style/CombinableLoops: Combine this loop with the previous loop.
      expanded_paths.each do |path| ...
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/dev-cmd/edit.rb:93:9: C: [Correctable] Style/Next: Use next to skip iteration.
        if (path.core_formula_path? || path.core_cask_path? || path.core_formula_tap? || path.core_cask_tap?) && ...
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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.

Thanks for the PR and work so far!

Library/Homebrew/extend/pathname.rb Outdated Show resolved Hide resolved
Library/Homebrew/dev-cmd/edit.rb Outdated Show resolved Hide resolved
Library/Homebrew/dev-cmd/edit.rb Outdated Show resolved Hide resolved
@abitrolly
Copy link
Contributor Author

I guess I addressed all review comments.

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.

Thanks again! A few more thoughts.

Library/Homebrew/dev-cmd/edit.rb Outdated Show resolved Hide resolved
@@ -28,6 +54,40 @@ def edit_args
end
end

sig { params(path: Pathname, cask: T::Boolean).void }
def fail_with_message(path, cask)
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
def fail_with_message(path, cask)
def raise_unless_existing!(path, cask)

Copy link
Member

Choose a reason for hiding this comment

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

@abitrolly Still prefer this naming or at least something with raise and the ! to be more in keeping with typical Ruby behaviour.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Renamed to raise_with_message!

Library/Homebrew/dev-cmd/edit.rb Outdated Show resolved Hide resolved
Library/Homebrew/dev-cmd/edit.rb Outdated Show resolved Hide resolved
end
expanded_paths = args.named.to_paths
expanded_paths.each do |path|
fail_with_message(path, args.cask?) unless path.exist?
Copy link
Member

Choose a reason for hiding this comment

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

How about moving the unless path.exist? into raise_unless_existing ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It can be done, but I would rather declare fail_with_message as T.noreturn to keep the branch flow in edit. So what is your decision?

Copy link
Member

Choose a reason for hiding this comment

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

You can still have it as void as long as the return value is not used by callers.

Library/Homebrew/dev-cmd/edit.rb Outdated Show resolved Hide resolved
@apainintheneck
Copy link
Contributor

I'm fine with this once the linter is happy. If it's too difficult to make the linter happy, you could just keep the original loop logic minus the select statement and add the Pathname refinements which still makes this clearer IMO.

@abitrolly
Copy link
Contributor Author

@apainintheneck I reworked the warning message test to use any?, so linter is now happy. Now only typecheck is not satisfied.

@abitrolly
Copy link
Contributor Author

abitrolly commented Sep 26, 2023

I don't think I am able to fix the typecheck error for this code. I opened sorbet/sorbet#7350 to get better docs about what to do with refinements, but for now it is beyond my abilities.

@MikeMcQuaid
Copy link
Member

I don't think I am able to fix the typecheck error for this code. I opened sorbet/sorbet#7350 to get better docs about what to do with refinements, but for now it is beyond my abilities.

CC @dduugg @reitermarkus for ideas and thoughts here on how best to handle things.

Would prefer to use Refinements if possible but if we can't with Sorbet: so be it (and then I think the old approach is better than moving to Pathname).

@dduugg
Copy link
Member

dduugg commented Sep 26, 2023

I don't think I am able to fix the typecheck error for this code. I opened sorbet/sorbet#7350 to get better docs about what to do with refinements, but for now it is beyond my abilities.

CC @dduugg @reitermarkus for ideas and thoughts here on how best to handle things.

Would prefer to use Refinements if possible but if we can't with Sorbet: so be it (and then I think the old approach is better than moving to Pathname).

Genuinely curious, why do you prefer refinements @MikeMcQuaid ? IIUC they're a fix intended to scope legacy monkey-patches to where they are used, not a good idea for new code. They're banned at Shopify and Stripe.

Sorbet doesn't support refinements. The workaround I used in brew code for existing refinements was to T.bind the defs to the class being refined (example). (You may also need to add the defs to an rbi file, but it looks like the linked example didn't need to.)

@abitrolly
Copy link
Contributor Author

abitrolly commented Sep 27, 2023

Maybe https://ruby-doc.org/stdlib-2.2.1/libdoc/delegate/rdoc/SimpleDelegator.html can be used to wrap Pathname instead of the Refinement?

EDIT: sorbet contributors confirmed it probably won't support refinements sorbet/sorbet#7350 (comment)

@MikeMcQuaid
Copy link
Member

Genuinely curious, why do you prefer refinements @MikeMcQuaid ? IIUC they're a fix intended to scope legacy monkey-patches to where they are used, not a good idea for new code. They're banned at Shopify and Stripe.

I prefer them to adding mode global monkeypatches to Pathname. I don't prefer them to e.g. the existing approach.

@abitrolly
Copy link
Contributor Author

All green. Let me know if there is anything else left.

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.

Looks good! Thanks again @abitrolly and sorry for all the back and forth.

@MikeMcQuaid MikeMcQuaid merged commit 67be775 into Homebrew:master Sep 27, 2023
25 checks passed
@abitrolly abitrolly deleted the edit-simplify branch September 27, 2023 12:52
@abitrolly
Copy link
Contributor Author

No problem. I am glad it helped. )

@github-actions github-actions bot added the outdated PR was locked due to age label Oct 28, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 28, 2023
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.

4 participants