Discrepancy creating a MatchSpec from package strings (sometimes "==" gets stripped)

[bsyouness]

Checklist

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

What happened?

In the source code here, the behavior of generating a MatchSpec object from a string dictates that if the string passed in doesn't have a build and the first two characters are "==", then the version should be stripped of "==". I read the comments above that snippet of code and I don't understand why that would be the case. This leads to this very confusing behavior:

In [23]: MatchSpec("awscli==2.15.37").get("version")
Out[23]: '2.15.37'

In [24]: MatchSpec("awscli==2.15.37=wghq").get("version")
Out[24]: '==2.15.37'

I would expect the two to be consistent. We have hardcoded behavior to make the two consistent for now but were hoping for an explanation or a code change.

Conda Info

No response

Conda Config

No response

Conda list

No response

Additional Context

No response

[travishathaway]

Hi @bsyouness,

Thanks for reporting this. I think this may be related to this previously opened pull request:

• fix MatchSpec roundtrip parsing #9980

This is another issue that also might be experiencing the same issue:

• name=version=build syntax expands to name==version=build, causing PackageNotFound errors conda-incubator/setup-miniconda#286

I unfortunately cannot offer an explanation about the exact behavior of MatchSpec in this case. My gut tells me you may be on to something though and have identified a bug. I will bring this up with more maintainers to see if this is something we want to address.

I have labeled this with severity::3 major; broken functionality with a workaround which indicates that you currently have a workaround for the issue.

[jaimergp]

We are currently analyzing this behaviour in this CEP too, feedback welcome.

[jaimergp]

I would expect the two to be consistent. We have hardcoded behavior to make the two consistent for now but were hoping for an explanation or a code change.

The key there is the presence of the build string, which must be using a different parsing logic because this syntax is an old one conda used to use, but still relevant in conda-build. I agree the discrepancy is odd and should be rectified.