CEP 43: Conditional dependencies

[jaimergp]

Checklist for submitter

• I am submitting a new CEP: Conditional dependencies.
  • I am using the CEP template by creating a copy cep-0000.md named cep-XXXX.md in the root level.
• I am submitting modifications to CEP XX.
  • The PR title reflects the CEP I'm modifying: CEP XX: Amend XYZ.
  • I updated the "Updated" date.
  • I added the link of this PR to the Discussions row.
  • I added or extended the ## Changelog section right above the final "Copyright" section with an item that uses syntax YYYY-MM-DD: Brief explanation of changes.
• Something else: (add your description here).

Checklist for CEP approvals

• The vote period has ended and the vote has passed the necessary quorum and approval thresholds.
• A new CEP number has been minted. Usually, this is ${greatest-number-in-main} + 1.
• The cep-XXXX.md file has been renamed accordingly.
• The # CEP XXXX - header has been edited accordingly.
• The CEP status in the table has been changed to approved.
• The last modification date in the table has been updated accordingly.
• The table in the README has been updated with the new CEP entry.
• The pre-commit checks are passing.

Comes from #111

[jaimergp]

Dear @conda/steering-council,

The vote for this CEP has started. It will be open for two weeks, until May 11th, 2026, 23:59 Anywhere on Earth. This time period has been chosen to make it eligible for time-out rules. As an Enhancement Proposal vote, it requires 60% affirmative votes to pass.

To vote, please mark the relevant checkbox under your username:

• Uwe Korn (@xhochy)
  • yes
  • no
  • abstain
• Marius van Niekerk (@mariusvniekerk)
  • yes
  • no
  • abstain
• Cheng H. Lee (@chenghlee)
  • yes
  • no
  • abstain
• Filipe Fernandes (@ocefpaf)
  • yes
  • no
  • abstain
• Marcelo Duarte Trevisani (@marcelotrevisani)
  • yes
  • no
  • abstain
• Michael Sarahan (@msarahan)
  • yes
  • no
  • abstain
• Marcel Bargull (@mbargull)
  • yes
  • no
  • abstain
• John Kirkham (@jakirkham)
  • yes
  • no
  • abstain
• Jannis Leidel (@jezdez)
  • yes
  • no
  • abstain
• Wolf Vollprecht (@wolfv)
  • yes
  • no
  • abstain
• Jaime Rodríguez-Guerra (@jaimergp)
  • yes
  • no
  • abstain
• Bas Zalmstra (@baszalmstra)
  • yes
  • no
  • abstain
• Hind Montassif (@Hind-M)
  • yes
  • no
  • abstain
• Pavel Zwerschke (@pavelzw)
  • yes
  • no
  • abstain

[jezdez]

@chenghlee your scope-restriction concern from #111 (comment) didn't carry over when this CEP got split out. That thread is still unresolved (baszalmstra asked for concrete ambiguous cases, and jaimergp's follow-up on whether {name}{operator}{version} covers forms like python>=3,<4 is open too). Since voting is happening this week, could you re-raise or close it out on this PR?

[wolfv]

We asked Cheng about examples and he didn't reply :( We think the parser works fine, and we have tests for a number of edge cases.

[baszalmstra]

@jezdez I'm sorry my comment read passive-aggressive, it was not meant that way! We have already written a parser for this that works by quoting and escaping values. We didn't run into any difficult cases. I was asking about edge cases @chenghlee had in mind because I was curious whether there are difficult cases we missed. Since we didn't receive any during the RFC period, we felt it was fine to call a vote regardless.

[chenghlee]

Sorry; got caught up in other things. I'm okay with my comment on the previous CEP being unresolved; it's mostly that strictly speaking, the current square bracket notation supports ridiculous (but semantically meaningless) things like [and=or foo="(123|4)" and 1], but having thought about it, I think the proper fix is to clamp down on allowable expressions in square brackets than to block this CEP.

[jezdez]

@jaimergp I have concerns about this vote being called if the thread above wasn't closed, you even asked about it?

[jaimergp]

It's a minor clarification, I'd say.

[wolfv]

Mid voting period reminder, @msarahan @marcelotrevisani @jakirkham @mariusvniekerk @chenghlee @pavelzw

[wolfv]

@mbargull @jakirkham last reminder to vote!

[benmoss]

I think the examples in this CEP are confusing, we aren't expecting users installing packages to really be specifying conditional dependencies, are we? I think the target audience for this feature would be package authors if I understand correctly.

I guess the framing here is that the same MatchSpec is used by both user types, but I'm not sure if that's by necessity or just incidental.

[jaimergp]

Vote results

🗳️ The votes are in! Here is the tally for this @conda/steering-council vote. Thanks to everyone who participated.

🎉 Result: PASSED

Summary

Metric	Value	Threshold	Status
Quorum (participation)	13/14 (92.8%)	≥ 9 voters	✅
Approval (yes / yes+no)	12/12 (100.00%)	≥ 60%	✅

Abstentions count toward quorum but are excluded from the approval fraction.

Tally

• ✅ Yes: 12 (100.00% of decisive)
• ❌ No: 0 (0.00% of decisive)
• 🤷 Abstain: 1
• 💤 Not voted: 1
• ⚠️ Invalid: 0

[jaimergp]

@benmoss, yes and no. I expect way more users on the packaging side (authoring recipes) then on the CLI (typing conda create ...), but I do see a use case for environment.yml specs instead of, for example, having separate files per OS for a CI pipeline.