Skip to main content

Quick start

This walkthrough uses the normalized multi-tool provider shipped in testdata/multi-tool-provider. It packages the provider as a local OCI layout, creates a workspace, and runs both the provider alias and a provided command through the workspace shell.

1. Build tinx​

make build

2. Package the example provider​

./bin/tinx release \
	--manifest testdata/multi-tool-provider/tinx.yaml \
	--dist testdata/multi-tool-provider/dist \
	--output testdata/multi-tool-provider/oci

This writes a local OCI layout to testdata/multi-tool-provider/oci/.

3. Create a workspace that uses the local layout​

./bin/tinx init demo -p testdata/multi-tool-provider/oci as echo

The command writes:

  • demo/tinx.yaml
  • demo/tinx.lock
  • demo/.workspace/

4. Inspect the workspace​

./bin/tinx --workspace demo status
./bin/tinx --workspace demo ls
./bin/tinx workspace list
./bin/tinx workspace current

You should see the workspace home, the installed provider, and the tool inventory. Before the first command runs, the tools still show as lazy.

5. Run the provider through the workspace environment​

./bin/tinx --workspace demo exec echo one two
./bin/tinx --workspace demo exec echo-tool alpha beta

The first command triggers lazy materialization of the bundled setup-echo tool and lazy installation of the script-backed echo-tool. In a real provider, both the alias and any provided commands behave like normal entries on PATH.

Re-run the inventory commands to see the transition from lazy to ready:

./bin/tinx --workspace demo status
./bin/tinx --workspace demo ls

6. Start an interactive workspace shell​

./bin/tinx --workspace demo shell

Inside the shell, run the provider directly:

echo three four
echo-tool five six

7. Clean up​

./bin/tinx workspace delete demo

What happened​

  1. tinx release built the required bundle-backed binaries and packed them into an OCI image layout.
  2. tinx init created a workspace manifest and synced the provider into .workspace/.
  3. The workspace shell wrote lazy shims for echo and echo-tool, then the first execution materialized and installed the required tools on demand.

Next, read workspace and runtime shell.