Feature request: Sync cask version to the current installed version

[muescha]

where:

• there are auto-update version
• they never in sync with the installed version

what i expect:

• some check command which reads the current version and update the info for brew cask

what i see instead:

• always apps are outdated, also if they updated in app

[ondrejfuhrer]

Hey @muescha ,

Thank you for your suggestion, not not sure if that is easily possible. Do you have a hint how to get (in general) a version of installed software? Theoretically might be possible to get that from Info.plist file, but is that consistently achievable?

[ondrejfuhrer]

Also one issue is that how the installation folder looks like:

/usr/local/Caskroom/{cask}/{version}/

But not something that is not achievable, just re-symlinking to a different folder might work 🤔

[muescha]

i don't know how MacUpdater solved this :(

[ondrejfuhrer]

Hey @muescha , I also don't know how they solved it but also I guess they have much more resources. I've tried to look into this and the problem is that not all casks are installed the same way.

Currently it is fairly "easy" to guess the version - even though there are multiple versions in the Info.plist file within the app, let's say i will "correctly" guess the updated all version. The "problem" here is, that the app doesn't always have a "link" back to the cask.

There are currently two ways:

1. I know what casks are installed so I can go through them
2. "Scan" the whole Applications folder and get all the versions

In both cases I still have the problem that there is no link between them guaranteed (i.e. some casks are installed via .pkg therefore I have no clue what is the app name and where exactly it is installed). I can potentially start rolling out some experimental features in this matter, which means it will only work with some of the apps but right now I really can't guarantee that it will work without any issues and for all apps.

[maxim]

Was just wondering the same thing and found this issue. Perhaps another way to approach it might be to simply hide versions of unmanaged software?

       Cask                                  Current       Latest        A/U    Result    
 1/73  adobe-air                             32.0.0.125    32.0.0.125         [   OK   ]  
 2/73  appcleaner                            Unmanaged     3.5            Y   [  PASS  ]  
 3/73  apptivate                             latest        latest             [   OK   ]  
 4/73  atom                                  Unmanaged     1.52.0         Y   [  PASS  ]  
 5/73  backblaze                             Unmanaged     7.0.2.470      Y   [  PASS  ]  
 6/73  betterzipql                           latest        latest             [   OK   ]  
 7/73  chromedriver                          86.0.4240.22  86.0.4240.22       [   OK   ]  
 8/73  cyberduck                             Unmanaged     7.6.2.33520    Y   [  PASS  ]  
 9/73  docker                                Unmanaged     2.4.0.0        Y   [  PASS  ] 

It just feels a little unsettling to see the incorrect current version, but hiding it seems to restore the peace of mind. 🤔 What are your thoughts?

[ondrejfuhrer]

Hey @maxim , thanks for stopping by 😉 The issue I see with your proposal is how do you know, which are managed and which are not? For example I turn auto-update for the apps off and 99% of the times I update them through brew cu. Other people are using auto update on the apps and then ignoring them on brew cu (i.e don't pass --all argument or pinning them).

So what would be the use case for showing the Unmanaged current version?

[maxim]

Ah makes sense, this wouldn't work then. Trying to see if there's any way to indicate that "current version" is not actually correct in some cases.

[maxim]

My proposal was simply to have brew cu say "if i'm not the one updating the app, then I don't know what version it is" in any way we'd like.

[fdagnat]

Hello,
A very simple first step would be to offer the possibility to the user to tell that he has migrated outside brew. For example:
brew updated [--version version] cask. Without the version, it changes the recorded version to the current latest available and with the version it changes to the specified version.

In my point of view, it would make it easier for the user that sometimes use outside upgrades to keep track of its current state.

[yurikoles]

I think this issue is out of scope of brew cu, which is in the end just a plugin to HBC and not a complete software management solution. To hyperbolize this issue, one may request cu to discover all manually installed software and map them to corresponding casks in order to make them manageable. This is also technically possible, but is practically hard. A paid version of Chocolatey, a pro one, is doing this on Windows.

[ondrejfuhrer]

@fdagnat have to agree here with @yurikoles . Even though it sounds like a "easy task", the way casks are generally managed is complicated. There are installation metadata that we would need to update, symlinks that would need to be fixed, etc. That has a huge potential for breaking if any internal implementation changes.

[shg]

I too think it useful if the versions of auto-updated applications are synced. The current application version can be obtained using AppleScript. Is this not sufficient? This seems to work for most of the apps.

osascript -e 'version of app "Slack"'

[muescha]

Good idea. This works for every app? This script need an "special" app name?

[ondrejfuhrer]

I don't think getting the actual version is a big problem. The main challenge here actually reflect all the necessary changes.

Let's take a signal cask as an example. Currently in version 6.1.0.

That means following:

1. Installation path contains the version:

/usr/local/Caskroom/signal/6.1.0/Signal.app -> /Applications/Signal.app

2. Metadata for the cask contains the version of the cask file itself (and version in the path)

/usr/local/Caskroom/signal/.metadata/6.1.0/20221225203223.651/Casks/signal.rb

> cat signal.rb
───────┬───────────────────────────────────────────────────────────────────────────
       │ File: signal.rb
───────┼───────────────────────────────────────────────────────────────────────────
   1   │ cask "signal" do
   2   │   arch arm: "arm64", intel: "x64"
   3   │
   4   │   version "6.1.0"
   5   │   sha256 arm:   "32f2bcd01dd06dabc3b6ab68857cd6716690daa703912190db65b1af6a002eda",
   6   │          intel: "b1a2ab77c99dce19ec46e207b100cbb45fdc32eff6eb65e61403a09d860f7da1"
   7   │
   8   │   url "https://updates.signal.org/desktop/signal-desktop-mac-#{arch}-#{version}.dmg"
   9   │   name "Signal"
  10   │   desc "Instant messaging application focusing on security"
  11   │   homepage "https://signal.org/"
  12   │
  13   │   livecheck do
  14   │     url "https://updates.signal.org/desktop/latest-mac.yml"
  15   │     strategy :electron_builder
  16   │   end
  17   │
  18   │   auto_updates true
  19   │
  20   │   app "Signal.app"
  21   │
  22   │   zap trash: [
  23   │     "~/Library/Application Support/Signal",
  24   │     "~/Library/Preferences/org.whispersystems.signal-desktop.helper.plist",
  25   │     "~/Library/Preferences/org.whispersystems.signal-desktop.plist",
  26   │     "~/Library/Saved Application State/org.whispersystems.signal-desktop.savedState",
  27   │   ]
  28   │ end
───────┴───────────────────────────────────────────────────────────────────────────

Which means all those paths needs to updated, App re-symlinked, metadata file patched, otherwise the installation itself might break.

And I'm not even sure if it's all the things that need to be updated.
Which means that it's not really feasible to "update" the app based on its auto-updated version.

Yes, we can potentially report different version in the output and have a difference in "undateable" applications, however the application would still be reported as outdated when using standard brew outdated command and would be upgraded when running brew upgrade.

IMO I believe this inconsistency & confusion would not be worth the effort.

Maybe there is a practical solution to this issue that I don't see, if yes, please explain it 🙂

[shg]

I guess the frustration for some users (including me) is that brew cu keeps showing the last homebrew installed versions instead of the actual versions of the auto-update apps. If so, how about the following behavior? This does not require syncing links and metadata files if my understanding is correct

The brew cu gets and displays the current installed versions of the auto-update apps instead of the last homebrew installed versions. Then, in the Result column, it displays OK if those are up-to-date, and OUTDATED if they are not. In the bottom section, "Found outdated apps," auto-update apps are not displayed even if they are OUTDATED. It may be less confusing if the section name is Found updatable apps.

brew cu -a behaves as it does now. Thus the outdated auto-update apps can be force updated.

brew cu -af makes auto-update apps that are already up-to-date on the app side also be subject to FORCED.

[ondrejfuhrer]

I too think it useful if the versions of auto-updated applications are synced. The current application version can be obtained using AppleScript. Is this not sufficient? This seems to work for most of the apps.

osascript -e 'version of app "Slack"'

This won't unfortunately work as the apps don't report the version in the same versioning scheme that brew is using. Example:

> brew info plex
==> plex: 1.60.1.3413,533a7645 (auto_updates)
https://www.plex.tv/
/usr/local/Caskroom/plex/1.60.1.3413,533a7645 (118B)
From: https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/plex.rb
==> Name
Plex
==> Description
Home media player
==> Artifacts
Plex.app (App)
==> Analytics
install: 521 (30 days), 1,600 (90 days), 6,185 (365 days)

However, the osascript reports differently:

> osascript -e 'version of app "plex"'
1.60.1

Therefore we can't really use it with confidence.

[ondrejfuhrer]

I don't think getting the actual version is a big problem.

I might have underestimated this, it actually is a problem because of the comment above - the osascript takes the value from Info.plist which is the only reliable source for that. Meaning that won't also be compatible with the versioning scheme brew is using as that's separated from the version itself - it's more the version string used for downloading the app then the version itself.

[muescha]

The brew cu gets and displays the current installed versions of the auto-update apps instead of the last homebrew installed versions. Then, in the Result column, it displays OK if those are up-to-date, and OUTDATED if they are not. In the bottom section, "Found outdated apps," auto-update apps are not displayed even if they are OUTDATED. It may be less confusing if the section name is Found updatable apps.

thats somehow was my original intention for this issue. to see if there is some action needed also for the autoupdate apps. just now the lines for autoupdate apps are useless because they never show me real data.

i don't need some fixing in the casts receipes and all others - only a information

[muescha]

However, the osascript reports differently:

> osascript -e 'version of app "plex"'
1.60.1

in this case 1.60.1.3413,533a7645 starts with 1.60.1 so it can be equal. Mybe in the case if it is not 100% equal (it also can match for 1.60.11.3413,533a7645 - maybe it is possible to strip down the receipe version to 1.60.11 so we can compare the version up to the 3rd level) but the starting is the same then the value for the column Result if there is an update needed can be "[MAYBE]" and it is up to the user to check if there is an update needed or not

[ondrejfuhrer]

However, the osascript reports differently:

> osascript -e 'version of app "plex"'
1.60.1

in this case 1.60.1.3413,533a7645 starts with 1.60.1 so it can be equal. Mybe in the case if it is not 100% equal (it also can match for 1.60.11.3413,533a7645 - maybe it is possible to strip down the receipe version to 1.60.11 so we can compare the version up to the 3rd level) but the starting is the same then the value for the column Result if there is an update needed can be "[MAYBE]" and it is up to the user to check if there is an update needed or not

I know, but that's just one of the examples. It also happens that the "build number" (or whatever is in the version) is changed but the version itself doesn't. Which means even in that case the startsWith won't work all the time.

We might not be looking for a perfect solution, true, but there are definitely cases where it won't work and we should call that out.

I wonder if that should be some sort of experimental feature enabled only in certain cases 🤔 (i.e. yet another option).

[muescha]

behind an experimental option it would be ok

maybe: with some description that the user should report to an issue here the edge cases of version compare where it should equal

[muescha]

i found also this edge case:

osascript -e 'version of app "jetbrains toolbox.app"'
1.27.2.13801

cask "jetbrains-toolbox" do
  arch arm: "-arm64"

  version "1.27.2,1.27.2.13801"

[jacksongoode]

This would be really cool to implement in some way, even if there are some edge case apps who's auto-updated version can't be discerned.

[alec-c4]

GitHub Recruitment Team

LOL!!! Swindler detected https://who.is/whois/githubtalentcommunity.online