Open zbentley opened 5 months ago
Thank you for this feature request. This is something I would like to get prioritized.
Thanks for the build system fix @donoghuc! Any chance that artifacts built with that fix will land in the public artifact store any time soon?
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:
This causes two sets of problems:
bolt
runs slower than it normally would on MacOS due to the automatic translation of its x8664 binary code (or rather, the translation ofruby
and associated libs' code) to ARM code via [Rosetta](https://en.wikipedia.org/wiki/Rosetta(software)).bolt apply
to 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 bootstrapspuppet-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 whenpuppet apply
is invoked by x86bolt
.Describe the Solution You Would Like
Installers for the bolt .dmg should be published to
downloads.puppet.com
for thearm64
architecture wherever possible, and the formula for thepuppetlabs/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.