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/pin: Update pinned formula messaging #16301

Merged

Conversation

apainintheneck
Copy link
Contributor

@apainintheneck apainintheneck commented Dec 6, 2023

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

Resolves #16212

The hope is that this will be clearer and less annoying for users.

A user came to us a couple weeks ago stating that it was confusing that the brew upgrade command printed an error when a pinned formula had a new version available and didn't get upgraded. Not upgrading a package is the expected result of pinning it.

This PR changes that message to a warning from an error. While looking into this we found that there is another message that gets printed when a package dependent doesn't get upgraded because it is pinned and that got turned into a warning from a normal message. Honestly that should be more worrying for the user anyway; it could lead to a program not working correctly in the worst case scenario.

I also added a message to the brew pin command warning about potential unintended behavior if a dependency gets pinned and another package requires a newer version of it.

Lastly, I added a commented out deprecation notice for the brew upgrade --ignore-pinned command since it's now essentially the default.

Library/Homebrew/cmd/upgrade.rb Outdated Show resolved Hide resolved
Library/Homebrew/cmd/upgrade.rb Outdated Show resolved Hide resolved
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 so far, thanks! My questions are:

  1. does this indicates if a specific formula has not been upgraded because of the brew pin of a dependency?
  2. does brew upgrade foo fail/error if foo is pinned?
  3. same as 2) but if one of foo's dependencies are pinned.

@apainintheneck
Copy link
Contributor Author

apainintheneck commented Dec 8, 2023

  1. does this indicates if a specific formula has not been upgraded because of the brew pin of a dependency?
  1. same as 2) but if one of foo's dependencies are pinned.

The answer to 1 and 3 is essentially the same.

If one of foo's dependencies is pinned and the current version is too old, the install will raise an error in the FormulaInstaller#check_install_sanity method (great method name by the way).

return if pinned_unsatisfied_deps.empty?
raise CannotInstallFormulaError,
"You must `brew unpin #{pinned_unsatisfied_deps * " "}` as installing " \
"#{formula.full_name} requires the latest version of pinned dependencies"

This error gets caught, printed and then we skip trying to install that formula. That seems to be the case when installing or upgrading formulae so it's even more complex than I originally thought.

rescue CannotInstallFormulaError => e
ofail e.message
nil

rescue CannotInstallFormulaError => e
ofail e
nil

  1. does brew upgrade foo fail/error if foo is pinned?

No, it would print a warning. This used to be an error message (ofail) and is the message that was brought up in the original issue. That means it won't return a non-zero exit code either anymore.

The hope is that this will be clearer and less annoying for users.

A user came to us a couple weeks ago stating that it was confusing
that the `brew upgrade` command printed an error when a pinned
formula had a new version available and didn't get upgraded.

This PR changes that message to a warning from an error. While looking
into this we found that there is another message that gets printed
when a package dependency doesn't get upgraded because it is pinned
and that got turned into a warning from a normal message. Honestly,
that should be more worrying for the user anyway; it could lead to
a program not working correctly in the worst case.

I also added a message to the `brew pin` command warning about
potential unintended behavior if a dependency gets pinned and another
package requires a newer version of it.

Lastly, I added a commented out deprecation notice for the
`brew upgrade --ignore-pinned` command since it's now the default.
@MikeMcQuaid
Copy link
Member

Great, 1 and 3 sound right 👍🏻

No, it would print a warning. This used to be an error message (ofail) and is the message that was brought up in the original issue. That means it won't return a non-zero exit code either anymore.

I feel like brew upgrade shouldn't print an error or have non-zero exit code but brew upgrade foo should because you've specifically requested an upgrade of foo, one is available but you've pinned it. Thoughts?

@apainintheneck
Copy link
Contributor Author

I feel like brew upgrade shouldn't print an error or have non-zero exit code but brew upgrade foo should because you've specifically requested an upgrade of foo, one is available but you've pinned it. Thoughts?

That sounds reasonable. In that case, should we still deprecate the --ingore-pinned option? This change probably removes the need for that option for most uses cases but not all.

@MikeMcQuaid
Copy link
Member

In that case, should we still deprecate the --ignore-pinned option?

I don't feel strongly either way. brew upgrade foo --ignore-pinned when foo is pinned feels like a pretty weird invocation. If there's other cases outside of that: I'm happy to leave it. Could always leave it for now and see if we end up iterating post-merge based on more feedback?

The idea here is that it should be expected that `brew upgrade` will
not upgrade pinned packages but will attempt to upgrade everything else.
For that reason, it will only show a warning about pinned packages
in that case.

If, on the other hand, you pass the name of a pinned package explicitly
to the upgrade command, like in `brew upgrade PINNED`, we want to show
an error since we cannot upgrade that package until it gets unpinned.
@apainintheneck
Copy link
Contributor Author

I don't feel strongly either way. brew upgrade foo --ignore-pinned when foo is pinned feels like a pretty weird invocation.

Me thoughts exactly. I'll leave the deprecation in.

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 all the work here @apainintheneck and sorry for the amount of back and forth needed!

@MikeMcQuaid MikeMcQuaid merged commit cd8a9c0 into Homebrew:master Dec 13, 2023
25 checks passed
@Moulick
Copy link
Contributor

Moulick commented Dec 14, 2023

In that case, should we still deprecate the --ignore-pinned option?

I don't feel strongly either way. brew upgrade foo --ignore-pinned when foo is pinned feels like a pretty weird invocation. If there's other cases outside of that: I'm happy to leave it. Could always leave it for now and see if we end up iterating post-merge based on more feedback?

Does feel weird, the one case that comes to mind is that if foo is pinned and you want to upgrade foo only this time but leave it pinned for the next time, without having to unpin, upgrade, re-pin

@apainintheneck
Copy link
Contributor Author

Does feel weird, the one case that comes to mind is that if foo is pinned and you want to upgrade foo only this time but leave it pinned for the next time, without having to unpin, upgrade, re-pin

@Moulick I don't believe that was possible before this change either. This strictly changes messaging not how brew install behaves when a formula is pinned.

@Moulick
Copy link
Contributor

Moulick commented Dec 19, 2023

Does feel weird, the one case that comes to mind is that if foo is pinned and you want to upgrade foo only this time but leave it pinned for the next time, without having to unpin, upgrade, re-pin

@Moulick I don't believe that was possible before this change either. This strictly changes messaging not how brew install behaves when a formula is pinned.

Sure, I get that this is just a message change, not arguing that fact at all 😄. From a power users' perspective, looking at the command brew upgrade foo --ignore-pinned, logically I'd think it would upgrade foo ignoring the fact that it is pinned or not, even though it does not do that. Anyways, I don't think we really need it anyways, it's more of a convenience that would help if someone wanted to upgrade without having to unpin, but for now a user can unpin, upgrade, re-pin if they so wanted. (Like I do for a couple of dependencies) ¯\_(ツ)_/¯

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

Correct log level when ignoring pinned package on brew upgrade
4 participants