You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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): bolt runs slower than it normally would on MacOS due to the automatic translation of its x86_64 binary code (or rather, the translation of ruby and 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 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 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.
The text was updated successfully, but these errors were encountered:
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 x86_64 binary code (or rather, the translation ofruby
and associated libs' code) to ARM code via Rosetta.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.
The text was updated successfully, but these errors were encountered: