Discovery: conditional and extra dependency support in libmamba

[danyeaw]

Checklist

• I added a descriptive title
• I searched open requests and couldn't find a duplicate

What is the idea?

In mamba-org/mamba#4089 we requested an enhancement in mamba to support conditional and extra dependencies. We could look in to what it would take to update libmamba and libsolv changes.

Why is this needed?

Understanding how much work it would be and what would need to change can help us lead these enhancements being made while working with the mamba team.

What should happen?

• Prototype changes in mamba
• Meet with the QuantStack team to help prioritize them and discuss how we can work as a team to get them implemented

Additional Context

No response

[danyeaw]

I created a draft PR for just conditional support at mamba-org/mamba#4098 and through that learned the following:

For now we aligned with Rattler's ; if syntax (e.g., typing-extensions; if python <3.10) for consistency, but hopefully we can simplify the parsing syntax based on the bracket syntax currently being discussed.

The main challenge for these changes is that libsolv doesn't natively support conditional dependencies, so we pre-evaluate conditions before adding them to libsolv. This means conditions are evaluated at parse time rather than solver time, which works well for most cases and keeps the implementation straightforward.

Separating parsing from evaluation made the code easier to test and maintain. We implemented a fast path for simple platform conditions (__unix, __win, etc.) that can be evaluated immediately, while complex conditions require evaluating against all packages in the pool (optimized by filtering by name first).

We deliberately chose not to support conditional dependencies in the legacy libsolv parser since the Mamba parser is the default and supporting it would require external libsolv C library updates.

From a code structure perspective, we created a process_conditional_matchspec helper function to encapsulate evaluation logic, used templates to avoid duplication, and extracted platform information once per package.

We solved the circular dependency between MatchSpec and MatchSpecCondition using std::shared_ptr, and implemented a variant-based design with a recursive descent parser for nested AND/OR conditions.

Extras and flags support are still TODO as part of the full CEP proposal, however, they should be smaller extensions to what we demonstrated in the first PR.