Description
Use Case
The only available MacOS bolt installers in Homebrew are currently x86_64. On an updated MacOS 14 ARM mac, installing bolt makes this clear:
zac@atropos ~ ∴ brew update
Already up-to-date.
zac@atropos ~ ∴ brew install --cask puppetlabs/puppet/puppet-bolt
==> Caveats
Puppet Bolt binaries are installed in /opt/puppetlabs/bolt/bin, which is sourced by an /etc/paths.d entry.
/opt/puppetlabs/bolt/bin may not be included in your current $PATH but should be included in new shells.
==> Downloading https://downloads.puppet.com/mac/puppet-tools/12/x86_64/puppet-bolt-3.27.4-1.osx12.dmg
...
This causes two sets of problems:
- (minor):
boltruns slower than it normally would on MacOS due to the automatic translation of its x86_64 binary code (or rather, the translation ofrubyand associated libs' code) to ARM code via Rosetta. - (major): Code invoked by bolt subprocesses and sub-subprocesses prefers to run as x86 rather than arm64. Specifically, I had an issue (more details here) using
bolt applyto install locally-compiled Rust binaries, resulting in those binaries being built as the wrong architecture, experiencing significant slowdowns, and encountering errors when they in turn needed to spawn processes that assumed the native architecture.
important note: that x86 architecture preference cascades even if immediate bolt subprocesses are ARM. In other words: if Bolt bootstraps puppet-agent using a puppetlabs ARM package, puppet-agent will indeed be installed/run as ARM, but subprocesses of that puppet agent will still try to run as x86 when puppet apply is invoked by x86 bolt.
Describe the Solution You Would Like
Installers for the bolt .dmg should be published to downloads.puppet.com for the arm64 architecture wherever possible, and the formula for the puppetlabs/puppet/puppet-bolt cask should be updated to prefer installers which match the native architecture wherever possible.
Optionally (though this is probably a lot more work), bolt could internally invoke subprocesses on MacOS using the the arch command to force the architecture to match the native architecture if possible.
Describe Alternatives You've Considered
Subcommand authors can definitely use arch to force architecture preference of their own programs. However, I think this is a fairly large burden to place on users, considering that the author of code spawning a misbehaving-in-Rosetta subcommand is often a separate person from the author of whatever sub-sub-process of `bolt that spawns their code. The affected user is then not the person empowered to author a fix, and the invoking user may not know about the issue at all.
Additionally, the failure behavior may just be bad performance, or it may be an extremely non-obvious error (depending on the specific subprocess behavior) that doesn't indicate architecture mismatch as the root cause. In short: Bolt itself is in the highest-leverage position to reduce the incidence of this problem.