-
-
Notifications
You must be signed in to change notification settings - Fork 10.1k
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
Don't remove cask directories when upgrading. #15138
Conversation
Okay, so instead of essentially Do you have an example cask that breaks if you remove it completely to test this? |
That's the gist of it. I haven't figured out an automated test case yet since I don't know of any APIs that Apple exposes for the dock / Launchpad. However, I have been manually testing using the
With the original code, the 1Password app will disappear from the dock and will be moved out of the folder in Launchpad. With this code, the app remains in the dock and the Launchpad folder. One possible automated test case could be making sure the inode number stays the same before and after the upgrade. That wouldn't check Launchpad or the dock directly but it will ensure the directory isn't deleted. |
Is copying |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code seems reasonable to me but will wait for another @Homebrew/cask 👍🏻/✅ first.
If this stops the "multiple VSCode icons in my toolbar" issues: I will be very grateful.
@MikeMcQuaid Unfortunately this won't solve the issue with Visual Studio Code. There's something with the architecture that allows multiple instances of the app to be running, and when two different versions of the app are open, two icons are present in dock. I have checked out this branch and will see how it goes over the next day or so with these changes and report back. |
I can confirm that this is working as expected with a cask that is known to have this issue (Spotify). A couple of questions;
|
For the xattrs part, the original behavior includes copying xattrs (link), so I kept that for consistency.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would love if this resolves our long standing issue. Thanks @JBYoshi!
I've changed the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there is an edge case that still needs to be handled here:
If an app is renamed, will this leave an empty directory for the old app name?
Does this work with codesigning too? Otherwise it'll disable any upgraded app on ARM. |
@SMillerDev I have been using this branch on my ARM MacBook for the last couple of days and all seems to be well. |
Good point. I've added some behavior to handle that by passing in the old and new versions of the casks to the artifact installation and uninstallation steps. |
Looks like this needs to be updated to reflect the changes made to |
Updated to fix the merge conflicts. |
Fine with this when @reitermarkus is. |
Any updates on this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some small suggestions, but should be ready to merge after that.
Maybe the artifacts.any?
part can also be moved into a helper method since it's the same for move
and delete
.
ohai "Removing #{self.class.english_name} '#{target}'" | ||
raise CaskError, "Cannot remove undeletable #{self.class.english_name}." if MacOS.undeletable?(target) | ||
|
||
return unless Utils.path_occupied?(target) | ||
|
||
if target.parent.writable? && !force | ||
if !successor.nil? && target.directory? && successor.artifacts.any? do |a| | ||
a.class.dsl_key == self.class.dsl_key && a.target == self.target |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a.class.dsl_key == self.class.dsl_key && a.target == self.target | |
a.class == self.class && a.target == self.target |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated, with one caveats from the style checker. It doesn't like an equality test on the classes, so I used a two-way instance_of?
check that has the same behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One small change still needed, otherwise looks ready to merge.
Updated for that feedback. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that there's a new release tag, we should get this in ASAP so this has time to bake.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Some style suggestions.
@MikeMcQuaid Done. |
Thanks so much for your first, great contribution (hopefully of many)! Without people like you submitting PRs we couldn't run this project. You rock, @JBYoshi! |
Could this be causing https://github.com/orgs/Homebrew/discussions/4498? |
This is very likely related. I ran into the same problem when running a standard upgrade of chrome and chrome canary a day ago, but didn't see any reports of it at the time. I'll see if I can dig some relevant logs back out. |
I've merged #15399 which will improve the errors a bit (the stack trace will actually be useful now), but yeah will need to track down the source. Apparently the issues might be Ventura-specific. I'm running Monterey at the moment. |
I'm running the beta, let me know if I can test something |
On the Ventura, it is not possible to upgrade the application of cash normally |
Any updates on the issue, it happen for me today |
I think these issues might have to do with the new "App Management" permissions in macOS Ventura. More info here: Homebrew/homebrew-cask#147383 (comment) |
brew style
with your changes locally?brew typecheck
with your changes locally?brew tests
with your changes locally?When updating casks, Homebrew deletes the old version of the application before moving the new one in its place. This causes macOS to think that the application was uninstalled, and so it may get removed from places like notification settings and Launchpad. This PR changes the move behavior for cask directories so the app directory itself is retained during the upgrade, while the contents are replaced.
Fixes Homebrew/homebrew-cask#102721.