feat(live-runner): env-var fallback for register_runner provisioning fields

[rickstaa]

Draft / showcase for discussion — follows up on the dynamic-pricing thread in #20.

Why

@j0sh —I noted hello-world "feels a bit strange since it relies on the app to create the argument and forward it," and that pricing belongs with the runner (deployment), not in go-livepeer. This shows what "provisioning is deploy config, out of app code" looks like in the SDK.

What

register_runner provisioning fields fall back to LIVEPEER_* env vars when omitted; an explicit argument always wins.

Field	Env var
orchestrator_url / secret / runner_url	LIVEPEER_ORCHESTRATOR_URL / _ORCH_SECRET / _RUNNER_URL
price_per_unit / pixels_per_unit / price_unit	LIVEPEER_PRICE_PER_UNIT / _PIXELS_PER_UNIT / _PRICE_UNIT
capacity	LIVEPEER_CAPACITY

App identity/behavior (app, mode, callbacks) stays in code.

# before: app forwards operator config
await register_runner(args.orchestrator, secret=args.orchSecret, runner_url=args.runner_url,
                      app="livepeer-sample/hello-world", price_per_unit=args.price)
# after: operator sets env at deploy time
await register_runner(app="livepeer-sample/hello-world")

Not a trust change — dynamic still reports the price either way; env vs arg only moves where the operator sets it. Static remains the orch-owned path.

+27/−7, one file, inline (matches the existing CUDA_VISIBLE_DEVICES read).

Open questions

1. Env var names / LIVEPEER_* prefix ok?
2. Scope — full provisioning set (connection + auth + pricing + capacity); too much?
3. Update the example apps to drop the forwarding if this lands?

🤖 Generated with Claude Code

https://claude.ai/code/session_01Ue3DyejYHXX5HYmjxtJZbg

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 2789a00a-b2e8-4cc7-a4e7-012fabb1c458

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch rs/register-runner-env-defaults

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[j0sh]

Env var fallback is a good idea at the application layer. Since this is a library I'm a little hesitant about injecting implicit / hidden state that may clash with the existing runtime environment. From what I can gather, library configuration via env vars is not really an encouraged practice either.

If we ship a "runner executable" that shells out to some command then it would be fine to have env vars for that. For this library call though, I'm not so sure.

[rickstaa]

Env var fallback is a good idea at the application layer. Since this is a library I'm a little hesitant about injecting implicit / hidden state that may clash with the existing runtime environment. From what I can gather, library configuration via env vars is not really an encouraged practice either.

If we ship a "runner executable" that shells out to some command then it would be fine to have env vars for that. For this library call though, I'm not so sure.

Hey @j0sh I agree, we don't need to deal with this right now. This was just me doing some prototyping. Will clsoe for now.