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

cmd/outdated: display warning for disabled casks #17124

Closed
wants to merge 1 commit into from

Conversation

bevanjkay
Copy link
Member

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

This is an initial pass at warning users when they have casks installed that are disabled so that they can consider alternatives, and be alerted that a cask is leaving soon.

I am not 100% sure on the best place to position the warning yet, so the first option here is to show the list when running brew outdated. I'm not sure if this should be behind a flag, but it should probably be suppressed with the --quiet flag. The other location could be when running brew upgrade or brew update, but I'm hesitant for it to be too naggy.

@MikeMcQuaid
Copy link
Member

The other location could be when running brew upgrade or brew update, but I'm hesitant for it to be too naggy.

I think formulae just do this on brew doctor. I think it's worth emulating what formulae do here and being consistent across the too and adding more "noise" if we feel it is needed.

Doing so on brew update feels justifiable and maybe even brew upgrade if that's insufficient.

@bevanjkay
Copy link
Member Author

To be clear, are you suggesting not listing these on brew outdated and consider brew update instead?

From memory one of the main motivators for adding deprecate/disable to Casks was that we could then alert users when something they have installed becomes disabled. Otherwise I don't see a significant benefit over just removing them how we used to.

My concern is that it does become too naggy if it shows all the time, and in cases where the user would like to keep the application but not the Caskfile, we may need a way to remove it from Homebrew without removing the application?

@MikeMcQuaid
Copy link
Member

To be clear, are you suggesting not listing these on brew outdated and consider brew update instead?

Yes (and before that brew doctor).

My main consideration is: let's be consistent with what we do for formulae and casks.

@bevanjkay
Copy link
Member Author

Thanks @MikeMcQuaid - a list of disabled casks/formula is already being output when running brew doctor.
I do think it would be useful for users to be alerted more prominently.

I can re-work this PR to include some output when running brew update, or would you prefer to leave this for now?

@MikeMcQuaid
Copy link
Member

Thanks @MikeMcQuaid - a list of disabled casks/formula is already being output when running brew doctor.

Thanks for checking!

I do think it would be useful for users to be alerted more prominently.
I can re-work this PR to include some output when running brew update, or would you prefer to leave this for now?

I don't have strong feelings about whether we do either or both. If we do outdated: probably need to think about how brew outdated --json handles this.

@Homebrew/maintainers any thoughts here on how we are more noisy about deprecated formulae/casks?

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.

A few code comments but feel free to hold off implementing until we decide whether to move forward with outdated and/or update. Feel free to discuss them before that.

if args.named.present?
select_disabled(args.named.to_casks)
else
select_disabled(Cask::Caskroom.casks)
Copy link
Member

Choose a reason for hiding this comment

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

Can you use hyperfine to see how much slower this makes the default brew outdated?

@@ -78,6 +78,7 @@ def run
end

print_outdated(outdated)
print_disabled(disabled_casks)
Copy link
Member

Choose a reason for hiding this comment

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

As mentioned: if we output casks here: we should also output formulae. May also want to think about how --json is handled.

@bevanjkay
Copy link
Member Author

Waiting to see if anybody had any thoughts here before going any further, but if there's no appetite for more warnings, I'm okay to leave it for now.

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.

I'm good to proceed with this approach, I agree it would be an improvement. A fair bit to go, unfortunately, but I've commented with a bunch of the needed changes.

casks.each do |cask|
opoo "#{cask.token} is #{DeprecateDisable.message(cask)}"
end
puts "Consider looking for alternatives, as they will be removed from Homebrew soon."
Copy link
Member

Choose a reason for hiding this comment

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

Need to handle this (and probably also the opoo above differently when STDOUT is not a TTY e.g. compare brew outdated and brew outdated | cat output.

Copy link

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

@github-actions github-actions bot added the stale No recent activity label May 31, 2024
@bevanjkay
Copy link
Member Author

I still have this on my radar, but probably won't get to it for a couple of weeks, so happy for this to close and reopen when I have some more time.

@bevanjkay bevanjkay closed this Jul 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale No recent activity
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants