`MatchSpec` parsing error with `~=` version operator

[jaimergp]

Troubleshooting docs

• My problem is not solved in the Troubleshooting docs

Anaconda default channels

• I do NOT use the Anaconda default channels (pkgs/* etc.)

How did you install Mamba?

Mambaforge or latest Miniforge

Search tried in issue tracker

~=

Latest version of Mamba

• My problem is not solved with the latest version

Tried in Conda?

I do not have this problem with Conda, just with Mamba

Describe your issue

Comes from conda/conda-libmamba-solver#581.

>>> from libmambapy.specs import MatchSpec as LibmambaMatchSpec
>>> LibmambaMatchSpec.parse("python[version='~=3.11.0',build=*_cpython]")
libmambapy.bindings.specs.ParseError: Error parsing MatchSpec "python[version='>=3.11.0',3.11.*": Parentheses mismatch in "python[version='>=3.11.0',3.11.*"."

Also, the output for this workaround is weird (note the build string containing the 3.11 mark). Maybe it's just the str-conversion, but it doesn't look right:

>>> spec = LibmambaMatchSpec.parse('python~=3.11.0=*_cpython')
>>> print(spec)
python[version=">=3.11.0",build="*_cpython,3.11.*"]
#                                         ^^^^^^^

This can be seen in the mamba CLI handling too:

$ mamba create -n py311 "python[version='~=3.11.0',build=*_cpython]"

conda-forge/noarch                                          Using cache
conda-forge/linux-aarch64                           14.8MB @  11.7MB/s  1.2s
critical libmamba Error parsing MatchSpec "python[version='>=3.11.0',3.11.*": Parentheses mismatch in "python[version='>=3.11.0',3.11.*"."

$ mamba create -n py311 "python~=3.11.0=*_cpython"
conda-forge/linux-aarch64                                   Using cache
conda-forge/noarch                                          Using cache


Transaction

  Prefix: /opt/conda/envs/py311

  Updating specs:

   - python[version=">=3.11.0",build="*_cpython,3.11.*"]

...

mamba info / micromamba info

libmamba version : 2.0.4
          mamba version : 2.0.4
           curl version : libcurl/8.10.1 OpenSSL/3.4.0 zlib/1.3.1 zstd/1.5.6 libssh2/1.11.1 nghttp2/1.58.0
     libarchive version : libarchive 3.7.4 zlib/1.2.13 liblzma/5.2.6 bz2lib/1.0.8 liblz4/1.9.3 libzstd/1.5.6
       envs directories : /opt/conda/envs
          package cache : /opt/conda/pkgs
                          /root/.mamba/pkgs
            environment : base (active)
           env location : /opt/conda
      user config files : /root/.mambarc
 populated config files : /opt/conda/.condarc
       virtual packages : __unix=0=0
                          __linux=5.15.49=0
                          __glibc=2.31=0
                          __archspec=1=aarch64
               channels : https://conda.anaconda.org/conda-forge/linux-aarch64
                          https://conda.anaconda.org/conda-forge/noarch
       base environment : /opt/conda
               platform : linux-aarch64

Logs

$ mamba create -v -n py311 "python[version='~=3.11.0',build=*_cpython]"
info     libmamba Searching index cache file for repo 'conda-forge/linux-aarch64'
conda-forge/linux-aarch64                                   Using cache
info     libmamba Searching index cache file for repo 'conda-forge/noarch'
conda-forge/noarch                                          Using cache
info     libmamba Attempting to read libsolv solv file "/opt/conda/pkgs/cache/ce3661c2.solv" for repo https://conda.anaconda.org/conda-forge/linux-aarch64
info     libmamba Expecting solv metadata : {"etag":"\"89ea9a3df5c8beef8942b812fd4c6642\"","mod":"Mon, 02 Dec 2024 16:53:37 GMT","tool_version":"2.0_0.7.30","url":"https://conda.anaconda.org/conda-forge/linux-aarch64"}
info     libmamba Loaded solv metadata : {"etag":"\"89ea9a3df5c8beef8942b812fd4c6642\"","mod":"Mon, 02 Dec 2024 16:53:37 GMT","tool_version":"2.0_0.7.30","url":"https://conda.anaconda.org/conda-forge/linux-aarch64"}
info     libmamba Metadata from solv are valid, loading successful
info     libmamba Attempting to read libsolv solv file "/opt/conda/pkgs/cache/eb045dd1.solv" for repo https://conda.anaconda.org/conda-forge/noarch
info     libmamba Expecting solv metadata : {"etag":"\"d63a0874be13ede39ed01acf8f4f6600\"","mod":"Mon, 02 Dec 2024 16:53:50 GMT","tool_version":"2.0_0.7.30","url":"https://conda.anaconda.org/conda-forge/noarch"}
info     libmamba Loaded solv metadata : {"etag":"\"d63a0874be13ede39ed01acf8f4f6600\"","mod":"Mon, 02 Dec 2024 16:53:50 GMT","tool_version":"2.0_0.7.30","url":"https://conda.anaconda.org/conda-forge/noarch"}
info     libmamba Metadata from solv are valid, loading successful
info     libmamba Loading site packages
critical libmamba Error parsing MatchSpec "python[version='>=3.11.0',3.11.*": Parentheses mismatch in "python[version='>=3.11.0',3.11.*"."

environment.yml

N/A

~/.condarc

N/A

[jjerphan]

Thank you for the report.

A priori and without looking in the internals yet, we might need to extend the solution of #3483 to support such a MatchSpec.

[jjerphan]

I think conda/ceps#82 should be prioritized otherwise we are just going to end-up with a lot of plenty small fixes here and there.

[jjerphan]

~= is not formally part of the MatchSpec's specification, and we do not want to support all the deviations from this specification.

As mentioned in rapidsai/ci-imgs#214, the specification can be reformulated as this for now:

python>=3.11,<3.12.0a0=*_cpython

[jaimergp]

~= is not formally part of the MatchSpec's specification, and we do not want to support all the deviations from this specification.

The MatchSpec class docstring is not the specification, unfortunately. There will be a CEP, but until then, the reference implementation is still conda, I'm afraid. ~= was introduced in 2019, in conda 4.6.0, following https://peps.python.org/pep-0440/#compatible-release. It cannot be used in meta.yaml's and the resulting repodata (because older conda versions would break when parsing it), but it is indeed a valid CLI input.

I don't see it as a deviation of the "specification", but an intrinsic part of it. The problem right now is that this input is accepted without errors, but mishandled internally in a way that creates invalid specs.

libmambapy 1.5.11 parses it without workarounds:

>>> from libmambapy import MatchSpec
>>> s = MatchSpec("python~=3.11.0=*_cpython")
>>> s.conda_build_form()
'python ~=3.11.0 *_cpython'

[jjerphan]

For posterity: the support of MatchSpec containing ~= is implemented but was not matching compatible releases.

#3483 rectified that as a hot fix before the release of mamba 2.0 to handle most cases by rewriting them under an equivalent form, but this is a wrong approach.

The right approach is to revert #3483 and to correct implementations using VersionPredicate::compatible_with.