Install the mounted project's pinned tools at provision time - #13
Merged
Conversation
#12 made mise read the project's mise.toml; this installs what it asks for. mise auto-installs a missing tool the first time a shim runs it (auto_install defaults to true), so the versions were never permanently absent -- the problem is when they arrive. Left alone, the download lands on whoever first types `ruby`, minutes after orbx reported the machine ready, with nothing on the provisioning log they were watching. An agent driving `orbx run` cannot tell that from a hang, and the first person to hit it in practice just ran `mise install` by hand, which is precisely the step automated here. The project path is discovered rather than passed in: this template never learns it, since orbx::mount_target only rewrites paths under $HOME and a project outside it keeps an absolute path the template cannot guess. OrbStack surfaces every host share as a virtiofs mount, so the mount table is exactly the set of directories that came from the host. That same table is how the trust gap noted in #12 could later be closed, but this change deliberately leaves trust alone. Reads the project, never writes it. `mise install` resolves versions into ~/.local/share/mise and touches the repo only when lockfiles are enabled, which they are not by default. The mount is the user's real working tree, so it has to come back clean. Verified on a fresh machine pinning ruby 4.0.5, node 24.16.0 and yarn 1.22.22: the provisioning log records the step, `mise ls` reports all three installed with no shim ever invoked and no manual install, an interactive shell warns about nothing, and the host directory is byte-identical afterwards.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #12, which made mise actually read the mounted project's
mise.toml. This installs what that config asks for.Problem
A fresh sandbox now greets you with:
The versions are not permanently absent —
auto_installdefaults totrue, so mise fetches a missing tool the first time a shim runs it. The problem is when. Left alone, a multi-minute download lands on whoever first typesruby, minutes afterorbxreported the machine ready, with nothing on the provisioning log they were watching. An agent drivingorbx runcannot distinguish that from a hang. In practice the first person to hit it just ranmise installby hand — precisely the step automated here.Fix
At the end of the mise section of
user-setup.sh:The path is discovered, not passed in. This template never learns the project path —
orbx::mount_targetonly rewrites paths under$HOME, and a project outside it keeps an absolute path the template cannot guess. OrbStack surfaces every host share as a virtiofs mount, so the mount table is exactly the set of directories that came from the host.It reads the project, never writes it.
mise installresolves versions into~/.local/share/miseand touches the repo only when lockfiles are enabled, which they are not by default. The mount is the user's real working tree, so it has to come back clean.Non-fatal and logged, consistent with the rest of
provision.sh.Verification
Fresh machine (
orbx-install-test, since deleted) with a project pinningruby 4.0.5,node 24.16.0,yarn 1.22.22:[user] Installing project tools pinned by /home/tomasz/code/orbx-install-test/mise.toml...mise ls— no shim invoked, no manual installnode 24.16.0,ruby 4.0.5,yarn 1.22.22, all from the project configzsh -icruby -v/node -v/yarn -vcorrect immediatelyshasum— repo untouchedshellcheckclean; 90/90 bats (89 + the new template test). YAML re-parsed to confirm the block reaches the guest intact.Still open
The trust scoping gap from #12 is untouched: a project outside the host's
$HOMEstill falls outsidetrusted_config_paths, and since mise skips an untrusted config, this install step would find nothing to do there either. The mount table used here is exactly the mechanism that would close it — happy to do that as a third PR if wanted.