8000 Don't run update on casks with `:latest` when the artifacts haven't changed · Issue #11513 · Homebrew/brew · GitHub
[go: up one dir, main page]

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

Don't run update on casks with :latest when the artifacts haven't changed #11513

Closed
Logicer16 opened this issue Jun 9, 2021 · 9 comments · Fixed by #13275
Closed

Don't run update on casks with :latest when the artifacts haven't changed #11513

Logicer16 opened this issue Jun 9, 2021 · 9 comments · Fixed by #13275
Labels
cask Homebrew Cask features New features help wanted We want help addressing this outdated PR was locked due to age

Comments

@Logicer16
Copy link
Logicer16 commented Jun 9, 2021

Provide a detailed description of the proposed feature

When running brew upgrade --greedy, if the artifacts (i.e. files to install) for a cask using version :latest has not changed since the last successful install. An example of how this might be done is to compare the hash of the artifacts before and after the download and only installing if they don't match.

What is the motivation for the feature?

Installing casks that use version :latest each time brew upgrade --greedy when the artifacts is unchanged is unnecessary, time consuming, resource consuming, as well as potentially interrupting the user's workflow if they relaunch the application, thinking there's new updates.

How will the feature be relevant to at least 90% of Homebrew users?

Prevent issues stated in "motivation"

What alternatives to the feature have been considered?

  • Installing casks that use version :latest each time brew upgrade --greedy when the artifacts is unchanged - see "motivation"
  • Checking each individual application's website if a new version is released and then updating only those who have a new release - absurdly inconvenient
@Logicer16 Logicer16 added the features New features label Jun 9, 2021
@MikeMcQuaid MikeMcQuaid added the cask Homebrew Cask label Jun 9, 2021
@MikeMcQuaid
Copy link
Member

Why are you using --greedy, out of interest?

@Logicer16
Copy link
Author

For all of my apps that use auto_updates, it is considerably more convenient to update all of them at once rather than checking each application for an update, by effect, making it more practical for me to check for new updates more often. Also, it updates all my casks that use version :latest instead of updating each individually, i.e:

  • Checking each individual application's website if a new version is released and then updating only those who have a new release - absurdly inconvenient

@MikeMcQuaid MikeMcQuaid added the help wanted We want help addressing this label Jun 9, 2021
@MikeMcQuaid
Copy link
Member

Gotcha, thanks. Yes, this seems like desirable behaviour then.

@bevanjkay
Copy link
Member
bevanjkay commented Jun 29, 2021

@Logicer16 In the meantime this is the command I use to run a greedy upgrade on my casks -
brew outdated --cask --greedy --verbose | grep -v "(latest)" | sed -E "s|[^A-z0-9-]\(.*\).*\n||" | xargs brew upgrade --cask

I would recommend adding --dry-run on the end to make sure it will work in your environment first

@Logicer16
Copy link
Author

@bevanjkay Your command works for updating casks using auto_updates true, though the point of this issue is that, if a cask uses version :latest and the installer (i.e. the file specified by url) hasn't been modified (see the specific clause: "when the installer hasn't changed"), it is unnecessary to run the installer again. One of reasons I use --greedy is because I want brew to update my version :latest casks, though updating when it isn't necessary is disrupting to my workflow.

@bevanjkay
Copy link
Member

@Logicer16 sorry, you are correct I misread your issue. I'll have a further dig. The PR I did submit will be useful for my use case anyway.

@Logicer16 Logicer16 changed the title Don't run update casks with :latest when the installer hasn't changed Don't run update on casks with :latest when the installer hasn't changed Jul 10, 2021
@MikeMcQuaid
Copy link
Member

@bevanjkay any more thoughts here?

@apainintheneck
Copy link
Contributor

I've been looking at this recently and I thought I'd add my 2 cents.

The idea of checking the installer was a good one but probably won't work. There are a bunch of different artifacts used to install new casks and those don't necessarily come with a single installer that can be easily compared to the new one. So I think that idea is out.

The simplest idea I've been able to come up with would be to just store some file metadata associated with the original downloaded file, the one associated with the url stanza, and then use that information to check and see if the cask needs to be updated. This wouldn't be terribly difficult but would require storing that information somewhere like the config.json file in the metadata/ folder. Though that's probably not a great place to put it since it really has nothing to do with the configuration of the application. The only data you'd really need to make a pretty accurate guess about whether or not the binary changed would be maybe file size and a hash of some sort.

@Logicer16 Logicer16 changed the title Don't run update on casks with :latest when the installer hasn't changed Don't run update on casks with :latest when the artifacts hasn't changed May 7, 2022
@Logicer16 Logicer16 changed the title Don't run update on casks with :latest when the artifacts hasn't changed Don't run update on casks with :latest when the artifacts haven't changed May 7, 2022
@Logicer16
Copy link
Author

@apainintheneck I agree with what you're saying.

Installer probably wasn't the best term. Most artifact stanzas are just files for brew to install. I've change my description to use "artifacts" instead to match what the docs call them.

As the url stanza can only occur once and and only downloads one file (or compressed archive), it would be best to compare that file.

Seen as brew already uses sha256 hashes, that can be used to check if there's any changes. As for storing it, it could be kept either individually, probably in a file seperate from config.json inside their .metadata/ folder, or all together, in a single file along with their corresponding cask name, probably in a csv, json, or similar format.

@github-actions github-actions bot added the outdated PR was locked due to age label Jun 18, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
cask Homebrew Cask features New features help wanted We want help addressing this outdated PR was locked due to age
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants
0