ci.yml uses conda/micromamba; every sibling toolbox uses plain pip

[petercorke]

Observed 2026-07-29, prompted directly by an opencv5 CI-pin incident (a
conda-forge-specific dependency-drift failure that plain pip installs
wouldn't have hit the same way, since pyproject.toml's own
opencv-python<5.0.0 / opencv-contrib-python<5.0.0 pins would have
been honoured — see the opencv5 migration issue). .github/workflows/ci.yml
is the only one of Peter's toolbox CI configs that uses
mamba-org/setup-micromamba + a hand-maintained create-args package
list. Checked directly:

Repo	CI setup
robotics-toolbox-python	actions/setup-python + pip install .[dev]
bdsim	actions/setup-python + pip install .[dev,bdedit]
spatialmath-python	actions/setup-python + pip install .[dev]
machinevision-toolbox-python	mamba-org/setup-micromamba + create-args package list

This is a genuine outlier. Traced via git log (not guessed): introduced
by Tobias Fischer (a friend of the maintainer) in commits abfe2e4a
("Some platform issues with open3d, install via conda") and 6e0f27ea
("Try change workflow to use micromamba to avoid Python issues on osx"),
May 2024 — a real reason at the time (open3d's historically painful
pip/platform story on macOS), not just a preference. That reason is moot
today: open3d isn't even in ci.yml's current create-args package
list — the dependency that justified conda quietly stopped being part of
the CI environment at some point, and the micromamba infrastructure just
outlived it. No other package in the current list needs conda either —
every one of numpy, pip, pytest, pytest-timeout, pytest-xvfb,
matplotlib-base, setuptools, opencv, scipy, spatialmath-python,
ansitable, wcwidth, tqdm, hatchling is an ordinary PyPI package.

Consequences of the mismatch, beyond one-off annoyance:

• Dependency pins in pyproject.toml (the pip-installable, publishable
  package spec) don't apply to CI at all, since ci.yml never runs pip install . against the conda env's packages the normal way — it
  pre-installs everything via create-args, then does
  pip install .[dev] --no-deps --no-build-isolation (explicitly
  --no-deps, so pip's own resolver never even sees the pins). That's
  exactly how CI silently drifted onto conda-forge's opencv 5.0.0 despite
  pyproject.toml saying <5.0.0.
• Doubles the maintenance surface for CI dependency changes: an
  environment.yml-style create-args list to keep in sync with
  pyproject.toml's dependencies/docs/dev extras by hand, instead
  of one source of truth.
• Inconsistent with every sibling repo, so fixes/conventions worked out
  on RTB/bdsim/SMTB's CI don't transfer here without translation, and
  vice versa.

Second live example, 2026-07-29: PR #24 (feat/tools-extra, adding a
new tool extra to pyproject.toml for optional IPython/pygments
support) failed CI with mvtbtool requires IPython and pygments, which are not installed (No module named 'IPython') — because ci.yml's
create-args package list was never updated to include them. A plain
pip install .[dev,tool]-style CI setup would have picked up the new
extra automatically. Patched directly (added ipython/pygments to
create-args) and merged 2026-07-29 — the underlying architectural gap
was still open at that point.

Third example (pre-existing, not a new incident): pgraph-python is
a real, declared dependency in pyproject.toml's dependencies list,
but was completely absent from ci.yml's create-args — not merely
unpinned, never installed at all. The only file that imports it,
BundleAdjust.py, does so inside a bare except: that silently falls
back when the import fails, so every CI run exercised BundleAdjust's
pgraph-dependent code in "not installed" fallback mode with nothing
surfacing it.

Fix

Normalize to the same actions/setup-python + pip install .[dev]
pattern the other three repos use, dropping mamba-org/setup-micromamba
entirely: replace the micromamba setup step with actions/setup-python,
replace create-args with pip install .[dev] (add pytest-timeout/
pytest-xvfb to the dev extra in pyproject.toml, matching what CI
actually needs), drop --no-deps --no-build-isolation so the resolver
actually enforces pyproject.toml's pins, and replace the Linux-only
libegl conda-forge install with the apt equivalent
(apt-get install -y libegl1 libgl1).

Frame this as a consistency fix (matching every sibling toolbox), not a
critique of the original choice — the open3d-on-macOS problem that
motivated it was real at the time, it just doesn't apply to the CI
environment as it exists today.