Investigate Integration test degradation with [email protected]

[schuylermartin45]

As discovered in PR #274, the latest version of rattler-build degrades our compatibility to the point where we no longer pass some integration tests.

It is good to see that this early alert system is working as intended! So we need to go in and figure out what happened and if we need to make any improvements to maintain our current level of compatibility.

[schuylermartin45]

Well there's your problem:

• Passing
• Failing

65 converted recipes no longer pass the dry-run stage.

[schuylermartin45]

I think I've found the culprit: prefix-dev/rattler-build#1271

[schuylermartin45]

The conversion script should default to use .* when the version is ambiguous, but it should also provide a warning.

Here's some example rattler-build output to use for inspiration:

Error: 
  × Failed to parse recipe

Error: 
  × Parsing: an unspecified error occurred.
    ╭─[34:7]
 33 │     - jpeg 9e
 34 │     - zlib 1.2.13
    ·       ─────┬─────
    ·            ╰── This match spec is ambiguous. Do you mean `zlib ==1.2.13` or `zlib 1.2.13.*`?
 35 │     # Optional dependencies
    ╰────

[schuylermartin45]

Welp this just got to be a big PITA:

>>> MatchSpec("foo 1.2.3").version.operator_func
<built-in function eq>
>>> MatchSpec("foo <1.2.3").version.operator_func
<built-in function lt>
>>> MatchSpec("foo ==1.2.3").version.operator_func
<built-in function eq>

CRM relies on Conda's MatchSpec to parse dependencies. It seems instead of being null-able, the operator field is mapped to ==

We used MatchSpec specifically so we didn't have to reinvent the wheel and build a version parser. Oh how the turntables...