Skip to content

fix(ros): avoid pixi lock panics on unmappable ROS dependencies#6290

Open
baszalmstra wants to merge 2 commits into
prefix-dev:mainfrom
baszalmstra:claude/clever-bardeen-7kU6v
Open

fix(ros): avoid pixi lock panics on unmappable ROS dependencies#6290
baszalmstra wants to merge 2 commits into
prefix-dev:mainfrom
baszalmstra:claude/clever-bardeen-7kU6v

Conversation

@baszalmstra
Copy link
Copy Markdown
Contributor

Description

Fixes two crashes where pixi lock would panic while resolving a ROS workspace with the pixi-build-ros backend.

The first happened when a package depended on something that the package map resolved to a special platform-conditional value, which is what the agnocast packages hit. The second happened when a dependency name contained characters that are not valid in a conda package name, such as crypto++.

Both now resolve correctly so the workspace locks. Dependencies that genuinely cannot be mapped to a valid conda package now fail with a clear, actionable error instead of an opaque panic.

Fixes #6288
Fixes #6287

How Has This Been Tested?

Added regression tests covering both previously failing dependencies and the new error path, and ran the backend's test suite.

AI Disclosure

  • This PR contains AI-generated content.
    • I have tested any AI-generated content in my PR.
    • I take responsibility for any AI-generated content in my PR.

Tools: Claude

Checklist:

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have added sufficient tests to cover my changes.

claude added 2 commits June 5, 2026 09:23
…names

The `liblttng-ust-dev` RoboStack mapping used a `${{ "lttng-ust" if linux }}`
selector value that the simple YAML loader stored verbatim and wrapped as a
concrete MatchSpec. The literal `${{` then reached MatchSpec parsing during
`pixi lock` and panicked with `InvalidPackageNameMatcher`. Rewrite that entry
to the platform-dict form the loader already supports, so it resolves to
`lttng-ust` on linux and to nothing elsewhere. This is the single templated
entry in the bundled map, which is the cause of prefix-dev#6288 (agnocast
depends on `liblttng-ust-dev`).

Also add an explicit `crypto++ -> cryptopp` mapping, and guard the resolver:
every resolved spec is now validated as a strict conda MatchSpec, so an
unmapped rosdep whose synthesized `ros-<distro>-<name>` is not a valid conda
name (e.g. one containing `+`) fails with an actionable
InvalidCondaPackageSpec error instead of panicking downstream.

https://claude.ai/code/session_01KeCkAavwYWnLYVGpGmVjNc
Drop the robostack.yaml suggestion from the InvalidCondaPackageSpec help
(users can't edit the bundled map) and point only at
`extra-package-mappings`. Condense the surrounding doc/test comments.

https://claude.ai/code/session_01KeCkAavwYWnLYVGpGmVjNc
@baszalmstra baszalmstra requested a review from ruben-arts June 5, 2026 11:48
@baszalmstra baszalmstra changed the title Claude/clever bardeen 7k u6v fix(ros): avoid pixi lock panics on unmappable ROS dependencies Jun 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

panic when building a ROS package pixi-ros-build can't process crypto++ dependency

2 participants