Proposal: new stanza, `bundle_id`

[vitorgalvao]

Details:

• Freeform (like name).
• Multiple allowed (like name).
• Allows being interpolated in other stanzas.
• Taken as string when there’s only one, as an array when there are multiple (for clearer interpolation)
• When using brew cask zap, defaults delete bundle_id also automatically happens.
• Position in stanza order right under name.
• Not mandatory (some apps, like CLI-only apps don’t have one, and introducing :unknown and :not_applicable options is both ugly and unneeded).

Advantages:

• Simple interpolation in other stanzas.
• Correctly delete preferences.
• Identify the main app inside a pkg, for automated bumping.

Disadvantages:

• Yet another stanza (like if we didn’t have enough already).

[adidalal]

My vote would be a cautious yes - but let's finish propagating version changes. This will require (likely) another round of batch changes - but one that we can't necessarily easily automate, so I expect uptake to be slow.

That being said, I really like getting zap stanzas "for free", and it also gives us nice interpolation to use in pkgutil.

[alebcay]

Perhaps it should be possible to make bundle_id accept either a single ID as a string (for most cases) or multiple IDs as an array of strings? It would save us from having to implement :multiple.

[vitorgalvao]

This will require (likely) another round of batch changes

Not necessarily. Making it not mandatory ensures we can add them as appropriate. A bit like auto_updates: it’s there, but we don’t need to rush to add it to every cask that needs it, we do so as cases arise.

Perhaps it should be possible to make bundle_id accept either a single ID as a string (for most cases) or multiple IDs as an array of strings? It would save us from having to implement :multiple.

It would also prevent us from easily and clearly using interpolation, which is the whole point. Having it limited to a single instance is a very deliberate limitation of its design. :multiple is meant to clearly state “don’t try to add a bundle ID here, we have reasons to not have one”.

[jawshooah]

It would also prevent us from easily and clearly using interpolation, which is the whole point.

Not necessarily. Consider these two cases:

cask 'foo' do
  ...
  bundle_id 'com.example.foo'
  ...
  zap :delete => "~/Library/Preferences/#{bundle_id}.plist"
end

cask 'foo' do
  ...
  bundle_ids 'com.example.foo', 'com.example.foo.bar'
  ...
  zap :delete => [
                   "~/Library/Preferences/#{bundle_ids[0]}.plist",
                   "~/Library/Preferences/#{bundle_ids[1]}.plist",
                 ]
end

Both seem entirely clear and usable to me.

EDIT: to clarify, bundle_ids could easily be an alias to bundle_id.

[vitorgalvao]

Consider these two cases

That was somewhat what I had in mind when tapping (was on a phone) that answer, and they seemed worse in my mind. One of my concerns was needing bundle_ids[0] for the vast majority of cases, but now I see I misunderstood what @alebcay was saying (which was for it to basically be the best of both worlds when possible).

I’ve updated the proposal.

[jawshooah]

One of my concerns was needing bundle_ids[0] for the vast majority of cases

We could do something like this so you could just use bundle_id most of the time:

def bundle_ids(*args)
  @bundle_ids ||= []
  return @bundle_ids unless args.any?
  @bundle_ids.concat(args)
end

def bundle_id(arg = nil)
  return bundle_ids[0] if arg.nil?
  bundle_ids(arg)
end

[reitermarkus]

Do we need the bundle ID for anything other than uninstalling or zapping? If not, we could just extract all bundle IDs at install time and save them as .metadata.

For app casks, this is easy:

require 'open3'

def plist_buddy(cmd, file)
  out, err, status = Open3.capture3('/usr/libexec/PlistBuddy', '-c', cmd, file)
  status.success? ? out : nil
end

puts ARGV.map(&File.method(:expand_path))
         .map { |path| File.join(path, '**', '*.app', 'Contents', 'Info.plist') }
         .map(&Dir.method(:glob))
         .flatten
         .map { |plist| plist_buddy('Print CFBundleIdentifier', plist) }
         .compact
         .sort
         .uniq

For pkg casks, we would need to use pkgutil to filter the Info.plist files, after that it's the same as for app casks.

[vitorgalvao]

@reitermarkus In the spirit of https://github.com/caskroom/homebrew-cask/issues/13201, I’m wary of that method, and don’t trust it.

Some casks include multiple apps, others have bundle ids but no apps (suites), and I’ve seen enough broken pkgs to know not to trust it.

To fix the issues in HBC (and prevent new ones), we should be dumb first, smart later. Trying to be smart got us in a lot of issues because there are so many edge cases. It’s preferable to have an explicit bundle_id and later on remove it in favour of an automated method if we see it would work, than doing it automatically, have it break on a bunch of cases, and then implement increasingly more workarounds for those.

[reitermarkus]

I just found another use case where a bundle_id stanza would be useful: accessibility_access

I think we can all agree that this is a useful addition.

[reitermarkus]

Alternatively, we could add :bundle_id(s) to existing stanzas, this way we automatically know what we should do with it.

  pkg 'GISLook_GISMeta.pkg',
      bundle_ids: [
                    'ch.bernhardjenny.gislook.pkg',
                    'ch.bernhardjenny.gismeta.pkg',
                  ]

 # uninstall pkgutil: [
 #                      'ch.bernhardjenny.gislook.pkg',
 #                      'ch.bernhardjenny.gismeta.pkg',
 #                    ]

And we could still add them to to a bundle_id(s) array in the order they appear so they can be used for interpolation.

[vitorgalvao]

Extra reason to add bundle_id — more efficient verification of codesigned apps: https://github.com/caskroom/homebrew-cask/pull/33570

[core-code]

i'd be happy to contribute a large (> 3000) dictionary mapping casknames to bundle_ids so that they can be added to the caskfiles automatically. however, bundle-ids change far more frequently than one would like or anticipate given that you loose your preferences if change them. so, i see keeping this stanza up-to-date as an additional maintenance burden. and i thought we'd rather want to move in the opposite direction - having less maintenance work.

so i wonder if @reitermarkus's initial suggestion of extracting and storing the bundle-id automatically isn't the best choice after all - even if there are drawbacks.

that said, if you want to add a bundle-id stanza: 1.) as said above i'd be happy to contribute a large list of bundle-ids 2.) since we keep track of bundleid<->caskame anyway i could also add a file to our server listing these changes. interested contributors could look at this file and send PRs to keep the stanza updated

thinking about it again, couldn't travis warn on submission if the bundle-id of the app doesn't match the stanza? for direct app downloads anyway. i aways thought regarding security it would be best to have a 'code-signature' stanza and have travis warn when its not as expected...

[vitorgalvao]

New advantage: identify the main app inside a pkg, for automated bumping.

[MikeMcQuaid]

Closing this out just because it's been a very long time since this was first opened and there's been no conversation or back references in almost 3 years.