mamba brings pypy instead of CPython when creating env #658
Comments
|
I tested it on my local and it works fine for |
|
Well, I also tried with |
|
As a workaround you can write python as: |
|
I reinstalled |
|
I have further information here, after a bit more investigation. The only way that I and @marcelotrevisani managed to make mamba to pick up the CPython version for Python 3.6 was by specifying |
|
@gabrielcnr, could you please report the version of libsolv that you have? |
|
@SylvainCorlay , I've got More specifically: |
|
@gabrielcnr I suppose you're running natively on OSX, right? When testing on Linux, using mamba correctly resolves to CPython. I wonder if this is an issue on the OS X build of libsolv ... that would be interesting :) |
|
Hmm, I tried locally on OS X (intel) and your command also properly takes cpython. What happens if you do not use Now I don't really know any further. |
|
@wolfv let me try here, but I had the same problem originally on Linux (RHEL 7) at work... |
|
I can confirm that I'm seeing this both on Mac and on Linux. Just tried here and the same happened... Do you need more details about my environment? Please let me know and I can provide more info. |
|
@wolfv - If add |
|
Yeah, IMHO conda-forge and main are becoming more and more incompatible. It's like using fedora and Ubuntu packages at the same time. One should at least use strict channel priority, better yet completely remove Main on Linux and OS X. The defaults channel never modified their python packages to be compatible with cpython/pypy |
|
I think that it is time communicating more about using mambaforge / miniforge, rather than miniconda. |
That is right, but, it is because the main don't care about So, it is not being incompatible, the fact that it is doing extensions to support other python implementations, that is a big difference |
|
I have experienced a similar observation in my weekly test-pipeline. Somehow the Python 3.7 tests on macOS and Linux failed. The cause? The install process in an already existing environment updated the Python 3.7 version to the PyPy 3.7 version, see this github-actions log as an example: https://github.com/m-rossi/jupyter-docx-bundler/runs/2486013432?check_suite_focus=true#step:4:128 After adding the workaround
from @marcelotrevisani (thanks!) it works as expected. However it was not necessary before to define the Python for an install process for an already existing environment. |
adriendelsalle
added
the
status::need-triage
|
This will be fixed by openSUSE/libsolv#457 |
|
Can you test this again with the latest libsolv installed? I've pushed this patch to the conda-forge build of libsolv: openSUSE/libsolv#457 |
- work around some weird installation issues that are probably due to the fact that we need to pull GROMACS from bioconda in some instances - (1) For macOS Python 2.7, numkit gets uninstalled: need to keep it explicitly. - (2) For Python 3.9, mamba wants to replace cpython with pypy and that leads to all kinds of problems (similar to what was reported in mamba-org/mamba#658 ). We explicitly request the cpython version of Python 3.9 when installing GROMACS.
I have here what it seems to be related to the issue #81
When using mamba to create an environment, it keeps pulling
pypy, which is not part of the given specs. When using pure conda that does not happen.I tested this on Mac and Linux, and both presented the same behaviour.
Creating an env with:
mamba create -n foobar "cachetools" "dataclasses" "diskcache>=4,<5" "humanize" "matplotlib>=3.1.3,<3.2" "numpy>=1.12.1" "pandas<1" "pydantic " "pytest" "pytest-mock" "pytest-datadir" "python>=3.6.10,<3.7" "python-dateutil" "pytz" "requests-mock>=1.7,<1.8" "ujson" "lxml>=3.8.0" "beautifulsoup4>=4.8 .0,<4.9"Gives:
As you can see from above, the pypy-related packages:
environment
My environment is (truncated below):
@wolfv @SylvainCorlay - I tried to debug/investigate the problem but I confess I got a bit lost and realised that I wouldn't have the time now., so I'm sorry I can't give more details here at the moment. But I was wondering if there could be an easy workaround for this problem? For example, maybe some kind of version constraint hint we can give to instruct the solver to ignore the
*pypy*build strings?The text was updated successfully, but these errors were encountered: