Bundle IDs seem to uniquely identify an app (unlike app names, but like app IDs).
mas commands should accept bundle IDs anywhere app IDs are currently accepted (command-line arguments, Brewfile).
Bundle IDs are more descriptive of the app than app IDs, so if you copy & paste the wrong bundle ID or have a typo in one, it's much more obvious.
The App Store lookup web endpoint (https://itunes.apple.com/lookup) supports using bundleId instead of id, and the apps listed in CKSoftwareMap.shared() can be looked up via bundle ID instead of via app ID, so there shouldn't really be any problems supporting bundle IDs.
If everyone agrees that bundle IDs should be allowed to be used as much as possible, I can investigate all the code to ensure there are no places where app IDs are much better or the only workable option (neither should be the case).
Should we also switch to displaying bundle IDs instead of app IDs in output?
This would be implemented by changing all current app ID command-line arguments from being read as integers to being read as Strings. If the String can be parsed as a UInt64, it will be considered an app ID. Otherwise, it will be considered a bundle ID. I assume that no bundle IDs are unsigned integers, so there shouldn't be any naming collisions. Any optional arguments would have their default value set to an empty string as a marker.
For some reason, mas upgrade can accept either app IDs or app names (it's the only command that accepts both). Since app IDs aren't guaranteed to be unique, it's not that great to accept them. I would propose changing text values here to also be bundle IDs. No one should really have to match based on app name. Moreover, we can have tab completion search through installed app names to get a unique app ID or bundle ID.
Bundle IDs seem to uniquely identify an app (unlike app names, but like app IDs).
mascommands should accept bundle IDs anywhere app IDs are currently accepted (command-line arguments,Brewfile).Bundle IDs are more descriptive of the app than app IDs, so if you copy & paste the wrong bundle ID or have a typo in one, it's much more obvious.
The App Store lookup web endpoint (https://itunes.apple.com/lookup) supports using
bundleIdinstead ofid, and the apps listed inCKSoftwareMap.shared()can be looked up via bundle ID instead of via app ID, so there shouldn't really be any problems supporting bundle IDs.If everyone agrees that bundle IDs should be allowed to be used as much as possible, I can investigate all the code to ensure there are no places where app IDs are much better or the only workable option (neither should be the case).
Should we also switch to displaying bundle IDs instead of app IDs in output?
This would be implemented by changing all current app ID command-line arguments from being read as integers to being read as
Strings. If theStringcan be parsed as aUInt64, it will be considered an app ID. Otherwise, it will be considered a bundle ID. I assume that no bundle IDs are unsigned integers, so there shouldn't be any naming collisions. Any optional arguments would have their default value set to an empty string as a marker.For some reason,
mas upgradecan accept either app IDs or app names (it's the only command that accepts both). Since app IDs aren't guaranteed to be unique, it's not that great to accept them. I would propose changing text values here to also be bundle IDs. No one should really have to match based on app name. Moreover, we can have tab completion search through installed app names to get a unique app ID or bundle ID.