cask: read bundle version from Info.plist when sensible.

[MikeMcQuaid]

If you're trying to use brew info --json=v2 to get an installed version and figure out if it is outdated: you're going to have a bad time with auto_updates casks because installed_version alone is not enough to get the actually currently installed version of the app.

Instead, in these cases, try to read from Info.plist if there is one and use that version.

While we're here, add a blank? method to Version so we can use it for present? checks (making a null? Version object blank?).

[Bo98]

Looks ok, though there's a mild concern that installed_caskfile might now never be updated and thus brew uninstall may not work correctly.

[MikeMcQuaid]

@Bo98 Good point. I was on the fence between two approaches and you've nudged me into the other one: adding dedicated new fields to the JSON output for this use specifically.

[Bo98]

I agree with that approach - seems simplest overall and keeps existing --greedy-auto-updates behaviour untouched.

In the long term, ideally we'd handle uninstalls better and then be able to merge the two. Maybe there's some opportunity to use GitHub Packages to store versioned info, but that is a much bigger task to tackle and not something for today.

[bevanjkay]

I'm still thinking on this, but there may be some other (rare) edge cases?

Something else is changed in the cask file, like adding a binary, and it isn't updated for the user because it was "auto updated" and linking was then missed because we report the cask as being updated.

[MikeMcQuaid]

I'm still thinking on this, but there may be some other (rare) edge cases?

Something else is changed in the cask file, like adding a binary, and it isn't updated for the user because it was "auto updated" and linking was then missed because we report the cask as being updated.

I don't think any of those would be affected by the current iteration of the PR. The earlier iteration, as @Bo98 mentioned, having installed_caskfile act differently could be detrimental.

I still think there's room to be smarter here (particularly around --greedy) to avoid repeatedly redownloading the same content.

[MikeMcQuaid]

Thanks for review all!

[apainintheneck]

Do we want to include this information in the JSON API? Currently, we're not parsing it in the Cask::CaskLoader::FromAPILoader but we could. I'm not sure how important that is though. I'm also sort of wondering if we want it to be included in the JSON API v3 as well.

• dev-cmd/generate-cask-api: start generating cask internal JSON v3 #16798

[Bo98]

Nah, it's something purely based on local app install state rather than anything in the cask itself.

[apainintheneck]

Ah, okay. That wasn't obvious to me at a glance. I guess it's just another example of something that makes sense as metadata for users but isn't needed in the API which is why v3 is necessary in the first place.