OnDemand (and, potentially,) optional_installs button label/text customization

[Allister Banks]

Hey friends/romans/denizens of earth,
I’m inspired by seeing Greg apparently being almost open to the idea of accepting clanker’s (aka LLM’s) potential help landing new features to Munki. I’ve long wanted to fulfill something Greg actually discussed back in 2015(!) when introducing OnDemand items, which is that currently the implementation piggy-backs on optional_installs (and apparently predated localization entirely) and therefore shows two (localized) button states only: all-caps ‘INSTALL’ or ‘INSTALLING’, which isn’t all that appropriate/applicable for what OnDemand items ‘commonly’ do. (I’m not going to claim I’ve used a _bunch_ of OnDemand things or that we rely on all that many, or all that heavily in our environment, but we’re weird - from the community, the most comprehensive-ish collection I’m aware of on GitHub is one I saw once by our precursor.ca esquire friend, and a lot of that appeared to be ‘flush font caches’ and other ‘real, but maybe don’t let people flick it ALL THE TIME’-type tasks.)

So! I went and spilt some tokens and found that it’s a surprisingly small scope of 6 functions across 3 files to deliver this feature WITH localization supported, and… as it ‘rides on top’ of optional_installs… we COULD also use this to customize the button labels/status for the folks who’d be interested in that as well! (Say you want to use “Get” for all your labels to mimic the macOS App Store, or you consider some installs to be completed when the item is “Cached”, or other admittedly ‘strained’ and perhaps unlikely scenarios.)
At this point of my (par for the course) longwinded email, let me call out/summarize where I am before I get to where I’m going with this:
• I’d hope it’s understandable/perhaps accepted that OnDemand can/could/should allow this customization support, so it’s worth investigating/potentially letting me implement
• …and per the tone of recent conversations, it’s probably desirable to not try to ‘hard-code’ new knobs and bake this in and replace defaults and require localization updates, since that’s both opinionated and would need not-insignificant coordination across the current ~11 supported languages
Ok, now moving on to the two big questions I’ve bulleted below:
• Do we _want_ to allow the scope to expand to optional_installs?
Similarly with OnDemand, my environment offers barely anything optionally (- more often the workflow is our server targets via tags, users request things, Okta push groups dynamically cause users machines to get them tags, voilà enforced install/MDM push/santa config/osquery pack, etc). But! The tokens flow freely for me (so farlol) and I’m in the code with them thar clankers and willing to QA/support this feature for the foreseeable future, so I can do this change big-bang-ish once and be fine with owning this feature for both moving parts.

Now on to the implementation design discussion, since a semi-confident decision before I mock up UX/send the PR with the code changes would make things land/get documented in the wiki (if all goes well) smoother, I’d think:
• If we want to forego allowing customized labels for optional_installs, should the keys be ‘junk drawer’, tossed in at the root, or instead should they be in a dedicated dict?
After working on a design for how knobs (to go all the way supporting optional_installs label customization as well) added to the pkginfo would look/work, the clanker and I landed on the naming “action_labels” and having it be a ‘namespace’/dict, which kindof gives the new keys to customize (and therefore support localizing, accordingly) simple, in a complete set (with the almost Apple-ish too-self-evident) names “install”, “ installing”, “installed”, “remove”, “removing”, and “update” (or with e.g. `_text` suffixes or something). If we instead went ‘flat’ with just string values at the root without a containing dict/‘namespace’, we’d use more explicit-ish, spelled-out mouthfuls like “install_button_label” etc. - not the worst choice (as long as there’s some convention/naming we feel confident enough about to agree on), there’s no precedent for indenting an additional level in the already-indented per-NSLocale localized_strings, presumably because there isn’t too much considered related/grouped that localization works on or is applicable for (I think). It’s just the type of threshold that if we DON’T go beyond the two ‘INSTALL’ and ‘INSTALLING’ 2 state-only, OnDemand-specific customizations it doesn’t really fit/make sense to have that indent level/containing ‘action_labels” dict for four others.

So decision-flowchart-wise, this is where I’d like all yers input - if we don’t feel the need for more than customizability of the two button labels/keys to support OnDemand, can I just get that code done/QA’d/sent with applicable/verbose ones and we kick potential niceties down the road for future revision? Or go all the way, and ADDITIONALLY, as part of doing so indent/namespace the keys, even if the customization at play in a pkginfo end up just having those 2 OnDemands (simpler/less-obvious-named) keys for the majority of the usage of this feature (set)?
Thank you for your input/consideration!
Allister