Cannot solve cmdstan=2.33.1=hc24a2e5_0 (linux) from osx-arm64

[JeanChristopheMorinPerso]

Hello, I'm trying to emulate CONDA_OVERRIDE_GLIBC=2.17 conda install -n test cmdstan=2.33.1=hc24a2e5_0 --subdir linux-64 with rattler and the solver doesn't seem to be able to resolve. I'm not too sure what's going on here.

>>> import asyncio
>>> import rattler
>>> virtual_packages = [
...     rattler.GenericVirtualPackage(rattler.PackageName("__glibc"), rattler.Version("2.17"), "0"),
...     rattler.GenericVirtualPackage(rattler.PackageName("__archspec"), rattler.Version("1"), "x86_64"),
...     rattler.GenericVirtualPackage(rattler.PackageName("__unix"), rattler.Version("0"), "0"),
...     rattler.GenericVirtualPackage(rattler.PackageName("__linux"), rattler.Version("0"), "0"),
... ]
>>> asyncio.run(rattler.solve([rattler.Channel("main")], ["cmdstan=2.33.1=hc24a2e5_0"], platforms=["linux-64", "noarch"], virtual_packages=virtual_packages))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/jcmorin/miniconda/envs/test/lib/python3.12/asyncio/runners.py", line 194, in run
    return runner.run(main)
           ^^^^^^^^^^^^^^^^
  File "/Users/jcmorin/miniconda/envs/test/lib/python3.12/asyncio/runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/jcmorin/miniconda/envs/test/lib/python3.12/asyncio/base_events.py", line 687, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "/Users/jcmorin/miniconda/envs/test/lib/python3.12/site-packages/rattler/solver/solver.py", line 81, in solve
    for solved_package in await py_solve(
                          ^^^^^^^^^^^^^^^
exceptions.SolverException: Cannot solve the request because of: cmdstan ==2.33.1 hc24a2e5_0 cannot be installed because there are no viable options:
└─ cmdstan 2.33.1 would require
   └─ gxx_linux-64 11.2.0.*, which cannot be installed because there are no viable options:
      └─ gxx_linux-64 11.2.0 would require
         └─ binutils_linux-64 ==2.38.0 hc2dff05_0, which cannot be installed because there are no viable options:
            └─ binutils_linux-64 2.38.0 would require
               └─ binutils_impl_linux-64 2.38.0.*, for which no candidates were found.

Am I doing something wrong or am I missing something?

Thanks!

[wolfv]

Just did a little test, and this line also fails:

asyncio.run(rattler.solve([rattler.Channel("main")], ["binutils_impl_linux-64=2.38.0.*"], platforms=["linux-64", "noarch"], virtual_packages=virtual_packages))

I'll do some more testing.

[wolfv]

So it seems like you might have found a bug 🎉 ! - micromamba (and probably conda?) do select 2.38 when asking for 2.38.0 which makes sense.

We should fix that in rattler.

Thanks!

[baszalmstra]

Thanks for the thorough tests!

I think I have a fix for this in #686

[JeanChristopheMorinPerso]

I'm having a similar problem with pytorch, more precisely

• pytorch=2.2.0=cpu_py38hdc00b08_0
• pytorch=2.2.0=cpu_py312hb9e5694_0
• pytorch=2.2.0=cpu_py310hdc00b08_0
• pytorch=2.2.0=cpu_py311h6d93b4c_0
• pytorch=2.2.0=cpu_py39hdc00b08_0

where I get

Failed to resolve pytorch=2.2.0=cpu_py38hdc00b08_0 (0.0691 secs): Cannot solve the request because of: pytorch ==2.2.0 cpu_py38hdc00b08_0 cannot be installed because there are no viable options:
└─ pytorch 2.2.0 would require
   └─ mkl 2023.* .*, for which no candidates were found.

Could this be the same problem?

[wolfv]

For the MKL issue I found the line. It says: mkl 2023.*.* in the dependencies.

I think that's not really valid - if you would want to express the constraint like that, IMO it should be a regex.

Maybe we should strip everything after the first starts_with operator.

[wolfv]

Excerpt from the repodata.

[baszalmstra]

Yeah I think its actually still a bug. It looks like mkl 2023.*.* is parsed as mkl[version="2023.*", build=".*"]. I think it should become mkl[version="2023.*"].

[baszalmstra]

#688 should fix the issue with mkl

[baszalmstra]

cargo run -- create --dry-run --platform linux-64 pytorch=2.2.0=cpu_py38hdc00b08_0 -c main --virtual-package __glibc=2.17=0 --virtual-package __archspec=1=x86_64 --virtual-package __unix=0=0 --virtual-package __linux=0=0

Shows that this is indeed solvable with #688

[JeanChristopheMorinPerso]

Thank you for the fixes!

[baszalmstra]

You're welcome, I appreciate the thorough tests! I just set in motion the release of py-rattler 0.6.1 which should include these fixes.

[JeanChristopheMorinPerso]

Just tested and it seems to be working for both cases! Thanks again!