Improve python dependency management for our examples

[abey79]

Managing dependencies for our growing list of example is increasingly painful, eg. #5859

One way about it would be to pin everything in the requirements.txt. This is some drawbacks:

• Updating pins is a painful, manual process, especially to handle incompatibilities between individual dependencies...
• ...yet we must do it on a regular basis, if only to support newer version of Python every year.
• Our approach of "merging" all of our examples' requirements.txt files makes the dependency compatibility problem even worse.
• Even with the perfect pins, this still doesn't give us a lock file, so things can still break via updates to transitive dependencies.

When/how do/should examples run?

• Developer working on a single example
• Developer running all examples for testing purposes
• User wanting to try an example
• CI building .rrds for in-app examples
• CI testing our examples against all supported Python version

Some things to consider

Who do we optimize for? Use developers or potential users that may want to run an example?

High-level wants:

• Ability to run example with arbitrary (supported) Python version and Rerun either built from source, installed with local wheels, or installed with PyPI wheels
• All deps cached on CI
• Lockfile for all python deps (preferably one, or one per example)
• Very easy for us developers to use and maintain
  • I don't have to have different shells for running examples and pixi scripts
• Fast (installing deps, locally and on CI)

Less important wants:

• Easy for users to run and contribute examples
• Pythonic

Support conflicting dependencies per example?

• If yes
  • Per example dependency definition
  • Per example lock file
  • Per example isolated environment
  • Will probably be slower to install all deps
• If no (strongly leaning towards this)
  • Requires us to make the examples use the same version of each dependency (like we do for Rust)
  • Move complex examples outside of the repository (Move complex examples to own repositories #5661)
  • Probably a lot less work for us?
  • Need to fix existing examples first

Splitting examples python from rest of dev process?

I think it makes sense to treat our scripts/*.py helpers differently from our examples/python. That is, they can use different tooling if it makes sense.

Other

• Easy for external users to run and write examples

  • "Pythonic" (aka. compatible with pip, PEP 517, etc.) - or good docs
  • Probably needs a per-example requirements/pyproject file

• Handle well at least the following two configuration:

  • dev environment where rerun-sdk should be installed from the workplace
  • user checking out example and running against a "regular" install of rerun (e.g. with pipx, etc.)

• Plays nice with pixi (I can call pixi commands and python stuff from the same shell without changing venv)

• pixi run all-examples should work (maybe re_build_examples handles it?)

[emilk]

We should consider doing this first in order to check we don't break things:

• CI: systematic testing of SDK and examples on all supported (major) Python version #2445

[teh-cmc]

My proposal would be to add one task per python (and C++? and C? and whichever comes next?) example in the root pixi.toml file, using pixi's various task/environment related features to deal with conflicting dependencies, should any arise.

The supported way to run these examples would be git clone rerun; pip install pixi; pixi run example.

For python users that don't want to go through this for whatever reason, we could have a simple automated task that extracts the pypi dependencies from pixi.toml and dumps them as a requirements.txt/pyproject.toml for each example.

This means a single tool, a single lock-file, and the ability to easily cache everything on CI.

[abey79]

So, for "normal" Python user:

pipx install pixi
pixi run extract-normally-expected-python-files-for some_example
cd examples/python/some_example
# then do whatever with the newly created requirement/pyproject files

This is a significant regression on the workflow, on the altar of:

• "using a single tool"
• caching (which there are other ways to do the same, e.g. by migrating from pip to uv in CI: https://github.com/astral-sh/uv?tab=readme-ov-file#dependency-caching, Add support for caching uv actions/setup-python#818)

[abey79]

for some reason, pixi refuses to install mediapipe:

❯ pixi run py-ex-human-pose-tracking
⠚ updating lock-file   [00:00:01] [━━━━━━━━━━━━━━━╾────────────────────────]    6/16                                                                                                              
  ⠤ py-ex-human-pose-tracking: 00:00:01] resolving conda
  ⠲ py-ex-human-pose-tracking: 00:00:00] resolving conda
  ⠖ py-ex-human-pose-tracking: 00:00:01] resolving conda
  ⠤ py-ex-human-pose-tracking: 00:00:01] resolving conda                                                                                                                                           × failed to solve the pypi requirements of 'py-ex-human-pose-tracking' 'osx-64'
  ├─▶ failed to resolve pypi dependencies
  ╰─▶ Because mediapipe==0.10.9 is unusable because no wheels are available with a matching Python ABI and you require mediapipe==0.10.9, we can conclude that the requirements are
      unsatisfiable.

The error is clearly wrong as the package exist in that version on pypi (albeit in unversal2, not aarch64).

Edit: I sorted it out, required weird work-arounds.

[teh-cmc]

So, for "normal" Python user:

pipx install pixi
pixi run extract-normally-expected-python-files-for some_example
cd examples/python/some_example
# then do whatever with the newly created requirement/pyproject files

No, we would just commit those requirement files.

The path is either:

cd examples/python/urdf_thing
poetry main.py  # uses autogenerated requirements

or:

pip install pixi
pixi run urdf_thing

[abey79]

cd examples/python/urdf_thing
poetry main.py  # uses autogenerated requirements

That is just not how it works 🤔 Anyway, very hard to discuss these thing without actually prototyping the thing and getting our priorities straight.