Mamba solving error messages feedback #2078
Comments
|
Does micromamba 1.0.0 already have conflict tree output? If so how do I enable it? |
|
Not yet 😅 I'm writing this issue to put the link in the in the message. |
|
Today I tried to run Notably, we seem to lose the information about python 3.9.* in the tree |
|
We had an issue with Error log |
|
Thanks @johnhany97 for the feedback. |
|
I had a "fun" conflict, and therefore thought to try out the experimental new error messages of micromamba: $ micromamba install qgis libgdal-arrow-parquet conda-forge/linux-64 Using cache critical libmamba Could not solve for environment specs It is a very long error message (although certainly better than the old "nothing provides dateutil needed by qgis-2.16.2-py27_0" which seems completely unrelated :)). General feedback: because libgdal has many builds for a single version, the error message tends to be quite repetitive (repeating the same conflict message for many build numbers). Of course, there might be small differences between those builds that are essential to make something installable or not, so I don't know if that is easy to reduce. Something else I noticed when doing |
|
Using the new error messages seems to result in a segfault sometimes, apologies for the very verbose command here. It seems to fail the first time, then segfault the second time you run it. Using the |
|
Can this be enabled on I am using versions 1.1.0 from conda-forge, so I guess #2143 didn't make it to a release yet, right? |
|
An example of a message of a conflict that did not help me sort out the issue: $ cat ~/.condarc
experimental_sat_error_message: true
$ micromamba create -n testenv "python >=3.8,<3.9" "pytorch::pytorch=1.13.0=py3.8_cuda11.6*" cudatoolkit=11.6 -c pytorch -c conda-forge
__
__ ______ ___ ____ _____ ___ / /_ ____ _
/ / / / __ `__ \/ __ `/ __ `__ \/ __ \/ __ `/
/ /_/ / / / / / / /_/ / / / / / / /_/ / /_/ /
/ .___/_/ /_/ /_/\__,_/_/ /_/ /_/_.___/\__,_/
/_/
pytorch/linux-64 Using cache
pytorch/noarch Using cache
conda-forge/linux-64 Using cache
conda-forge/noarch Using cache
error libmamba Could not solve for environment specs
================== Experimental satisfiability error messages ==================
You are seeing this because you set `experimental_sat_error_message: true`
Use the following issue to share feedback on this experimental feature
https://github.com/mamba-org/mamba/issues/2078
====================================== Legacy messages (old) =======================================
Encountered problems while solving:
- nothing provides cuda 11.6.* needed by pytorch-cuda-11.6-h867d48c_0
The environment can't be solved, aborting the operation
=================================== Experimental messages (new) ====================================
critical libmamba Invalid dependency info: <NULL> |
|
Would it be possible to give the python requirements a higher "weight" in the error message? The example from #2234 has this output with the experimental error message: The real issue here is that the user required python 3.11, but numba is not available for 3.11, so the messages above seem kind of backwards and more complex than needed ("I required python=3.11, why does it say that 3.10 could be installed"). I would have expected a message like "numba is not installable as no option is compatible with requirement python=3.11" |
|
Thank you all for the feedback! @chebee7i @shughes-uk it seems both problems you reported are the same. Sometimes it triggers a segfault, sometime it @jorisvandenbossche unfortunately I could not reproduce the @maxnoe Right now the error are "package agnostic" which means that python is no more important that Numba. I think it is easier to maintain that way. However I have a few ideas on how this could improve. Another problem is the long enumerations of successive packages (also reported by @jorisvandenbossche). We also have some ideas how to compress that more. Finally I am reporting that we are also seeing some suboptimal ouputs with python because the |
I didn't mean to give more weight to python because it's python but because that package in the user given specs has a requirement while there is no requirement on the numba version. |
Ha that's interesting, I didn't think of that! |
|
Trying to upgrade python in an env, I get the following very unhelpful message using mamba 1.4.2: then why don't you ... ? It seems to be that one of the packages is not yet compatible with python 3.11, but it doesn't tell which |
|
@maxnoe what was in your environment? |
|
It's the mambaforge base env with a small number of additional packages: |
|
In the example above, the only package not (yet) available for python 3.11 and thus blocking the update was |
|
Thanks @maxnoe , this type of message arise when there is a conflicts with a package already in the environment. The problem is that the input from libsolv is quite different with packages already in the environment. Right now I can generate a message that says the installed version of |
|
No, I didn't add any flags |
This comment was marked as off-topic.
This comment was marked as off-topic.
AntoinePrv
changed the title
|
Further improvements can be managed in their own issue. |
|
In a Singularity container build: |
|
@SomePersonSomeWhereInTheWorld I think it's a matter of mixing conda-forge and defaults. We strongly recommend against that. |
This is issue is meant to collect feedback on the experimental error messages for statisfiability errors (package conflicts).
You ended up here because you set
experimental_sat_error_messagein your config.We are looking for more example of conflicts in the ecosystem that are not well explained with the current implementation.
Especially edge cases such as:
run_constrainedin conda recipes),__that must be present on the system),We are also gathering feedback on the current form of the messages.
Please also share things that you like as well, so they don't get removed for lack of support.
Please share feedback/example with the latest version of mamba/micromamba and report the version in your message (for history).
The text was updated successfully, but these errors were encountered: