Unbreak the linux python pin; bound xtensor (partial cloud-build fix)

[Nicolas Palpacuer (NickPPC)]

Summary

viam module reload / viam module build have been failing for this module since at least January 2026, and local builds via bin/setup.sh are broken too. This PR fixes one cause outright and adds a stopgap for a second. It does not fully restore cloud builds — see Known gap.

GitHub Actions is unaffected by either cause, which is why this went unnoticed: CI never calls bin/setup.sh.

Changes

• bin/setup.sh: Install unversioned python3 / python3-venv on linux instead of python3.11 / python3.11-venv, and replace the stale canon-only comment with the reason the version must not be pinned.
• conanfile.py: Bound the transitive xtensor range to [>=0.24.3 <0.27] for this module's own dependency graph.

1. python3.11 does not exist on the build image — FIXED

bin/setup.sh pinned python3.11, but the Viam cloud build image is Debian bullseye, which has no such package:

Hit:1 http://deb.debian.org/debian bullseye InRelease
+ sudo apt install -y cmake python3.11 python3.11-venv wget
E: Unable to locate package python3.11
Exited with code exit status 100

The script's own comment explained the drift — "NOTE: this is written under the assumption that it will be built in canon". Canon has python3.11; the cloud builder does not. Safe to unpin: conan needs Python >= 3.6, bullseye ships 3.9, and the venv below is already created with whatever python3 resolves to.

Verified in the cloud build log:

+ sudo apt install -y cmake python3 python3-venv wget
Setting up python3-venv (3.9.2-3) ...

2. Unbounded xtensor range resolves to a C++20-only version — STOPGAP

We pin viam-cpp-sdk/0.20.1, whose recipe requests an unbounded xtensor/[>=0.24.3] at cppstd >= 17. That now resolves to 0.27.1, which itself requires C++20:

xtensor/0.27.1: Invalid: Current cppstd (17) is lower than the required C++ standard (20).

This is already fixed upstream. viam-cpp-sdk added the matching upper bound in #650, first released in releases/v0.37.0:

# v0.20.1 (what we pin) — bounded only at cppstd <= 14
if valid_max_cppstd(self, 14, False):
    return 'xtensor/[>=0.24.3 <0.26.0]'
return 'xtensor/[>=0.24.3]'          # cppstd 17 lands here -> 0.27.1 -> C++20 -> fails

# v0.37.0+ — bounded at cppstd <= 17 too
if valid_max_cppstd(self, 17, False):
    return 'xtensor/[>=0.24.3 <0.27.0]'

So the durable fix is bumping the SDK pin past v0.37.0, which is what chore/upgrade-viam-deps is trying to do (currently blocked on a separate API migration — the newer SDK removed viam/sdk/resource/reconfigurable.hpp). This override is a stopgap for as long as we stay on 0.20.1, and the comment in conanfile.py says to delete it when the pin moves.

Known gap — cloud builds still fail

The override does not fix the cloud build, because that is not where the build dies. bin/setup.sh clones the SDK and builds it first:

Running setup: bin/setup.sh
  + pushd tmp_cpp_sdk/viam-cpp-sdk
  + conan create . --build=missing -s:a compiler.cppstd=17
  Exporting package recipe: /root/project/tmp_cpp_sdk/viam-cpp-sdk/conanfile.py

That builds the SDK's recipe, so this repo's conanfile.py is never consulted and the unbounded range still wins:

xtensor/[>=0.24.3]: xtensor/0.27.1     <- not the bounded range
Exited with code exit status 6

The override is still needed for this module's own conan create step, which fails the same way without it — it is just not sufficient on its own. Constraining the SDK build too would mean injecting [replace_requires] into the conan profile from bin/setup.sh, which writes to the developer's global conan config; that seemed worse than landing the SDK bump.

Testing

• bash -n bin/setup.sh and ast.parse on conanfile.py both pass.
• Cause 1 verified end-to-end in the cloud build log (quoted above).
• Cause 2 verified only at local graph resolution for this module's recipe:

  xtensor/[>=0.24.3]: ['xtensor/[>=0.24.3 <0.27]']  ->  xtensor/0.25.0
  

• No completed end-to-end build. Three cloud builds run: the first died on cause 1, the second and third on cause 2 at the SDK step.

For reviewers

• Reasonable to reject cause 2's stopgap and just prioritise chore/upgrade-viam-deps instead — that removes the need for it entirely. Cause 1's fix stands on its own either way.
• I first suspected the missing conan remote add viamconan --index 0 that CI has and setup.sh lacks. Real divergence, but not the cause — version ranges resolve to the newest across all enabled remotes, so adding it still selects 0.27.1. Left alone deliberately.
• Long-standing, not new:

  1459795d... linux/amd64 Failed reload-3bbcbb9c...  2026-01-13
  9f999c24... linux/amd64 Failed reload-3bbcbb9c...  2026-01-13
  047b7197... linux/amd64 Failed reload-ed0bf65a...  2026-07-28
  

Claude Code Prompts Used

• "Can you hot reload this module to the Viam machine part ed0bf65a-8d6e-435f-be1c-5921ac742089 ?"
• "ys, open the PR for viam-cpp-sdk"

🤖 Generated with Claude Code