DAH-2553: pip install lium.io fails on Python 3.13/3.14 and weighs 161 MB

[taiberium]

llms-full.txt line 49 tells a caller to run pip install lium.io. On Python 3.13 and 3.14 that command fails, and it always pulls the whole chain stack.

Measured, before and after

	before	after
packages	84	43
site-packages	161 MB	54 MB
Python 3.13 / 3.14	install fails	works

The 3.14 failure, from the released 0.0.28:

× Failed to build `bittensor-drand==2.0.0`
╰─▶ Call to `maturin.build_wheel` failed
    error: failed to get `tle` as a dependency

Nothing in that traceback mentions lium.

This is the SDK audience only. The CLI installs as a standalone binary via curl -fsSL https://lium.io/install.sh | bash and never touches pip.

What changed

Eight dependencies nothing imports are gone. Grepped the whole package: bittensor-cli, plotly, plotille, fuzzywuzzy, python-Levenshtein, netaddr, async-substrate-interface, GitPython and Jinja2 had zero imports.

bittensor moves to a provider extra. It is imported lazily inside functions, in four files, all of them provider commands or lium fund. Renting never touches it, and it is what breaks the install on new Python. The two "not installed" messages now point at pip install "lium.io[provider]", and provider status says when subnet registration reads as unknown because the extra is absent instead of leaving it unexplained.

The binary still bundles it. One binary serves renters and providers, so the build syncs --extra provider. Verified locally: the bundle contains bittensor.

The bare single-file release asset is gone. Kept for the self-update shipped before the onedir switch in 0.0.25. GitHub download counts: 8 in 0.0.25 against 53 for the tarballs, then zero across 0.0.26, 0.0.27 and 0.0.28. install.sh and the current self-update both fetch the tarball, and older builds already get the reinstall prompt added in DAH-2262.

Verification

test/test_renter_install_is_slim.py pins all three properties and fails on main. One existing test asserted the legacy asset was published and was updated, since that behaviour changed on purpose.

Clean venvs on 3.12, 3.13 and 3.14 install and import. On the slim install lium ls returns the live board, ps works, provider node list returns real data, and lium fund exits 2 with the extra hint instead of a traceback. Binary built locally from the changed spec: starts in 0.33 s, --version, ls and provider --help all work.

Full suite: 349 pass, 11 fail — the same 11 fail on untouched main.

Not in this PR

Publishing the lium alias from stubs/. Our own llms.txt and llms-full.txt give the correct install commands, so nobody following the docs guesses the wrong name.

🤖 Generated with Claude Code

[arhangel66]

Request changes — one real bug.
lium fund --alpha on a slim install tells the user to run pip install "lium.io" — the package they already have. Reproduced on the current head in a clean Python 3.13 venv.
_alpha_fund raises LiumError here, while handle_errors escapes Rich markup only for CliFailure. As a result, Rich consumes [provider] and turns the intended pip install "lium.io[provider]" hint into pip install "lium.io".
Please raise CliFailure("provider_extra_missing", ..., EXIT_CONFIGURATION_ERROR) here, matching _legacy_tao_fund. Escaping the LiumError rendering would fix the displayed text too, but would retain the generic JSON error code and exit status.
The branch also needs rebasing onto current main: lium/cli/utils.py conflicts, and the resolution must preserve the new data parameter on CliFailure and pass e.data into _emit_json_error. Please regenerate uv.lock afterward; pyproject.toml will be 0.0.29, while the current lock records lium-io==0.0.28.
The rest of the code review checks out: bittensor is lazily imported in four files, the removed packages have no imports, and existing pip installations retain bittensor after upgrading.

[taiberium]

Good catch, reproduced it on a clean 3.13 venv.

I had escaped only the CliFailure branch, and _alpha_fund raises LiumError, which handle_errors renders on a different one. Every branch escapes now, so no message type can lose its brackets. Both fund paths are pinned by a parametrised test that fails on the previous commit.

Error: TAO funding needs the chain stack. Reason: the chain stack is not installed: pip install "lium.io[provider]"

[taiberium]

All three points done.

Error code, not just the text. _alpha_fund raises CliFailure("provider_extra_missing", ..., EXIT_CONFIGURATION_ERROR) now, matching _legacy_tao_fund. Both paths report the same code and exit 2:

{"error": {"code": "provider_extra_missing", "message": "... pip install \"lium.io[provider]\""}, "ok": false}

I kept the escaping as well, since the other three branches in handle_errors render our own messages too and would lose brackets the same way.

Rebased onto 0.0.29. The utils.py conflict is resolved keeping data on CliFailure and passing e.data into _emit_json_error.

uv.lock regenerated — it records 0.0.29 now, and uv sync --frozen --extra dev --extra provider succeeds.

Verified live on a clean 3.12 venv: both paths, text and --json, exit 2. Suite: 380 pass, the 11 failures also fail on untouched main.