libmamba traceback when using a pin file on an existing env that used build_string #286
Comments
wuillaum
added
the
type::bug
|
Thanks for such a detailed report and even a reproducer! I'll take a look today and open a PR if necessary. Looks like the |
|
After some experiments, you can fix it by making sure the pins do not use double equals, but single equals. The parsing is a bit clunky at Summary of attempts: from conda.models.match_spec import MatchSpec as M
# left side is your CLI arg, right side is the spec in the pinned file
M("scipy=1.7.3=py37hd18d958_0").match(M("scipy =1.7.3")) # works
M("scipy=1.7.3=py37hd18d958_0").match(M("scipy 1.7.3")) # fails
M("scipy=1.7.3=py37hd18d958_0").match(M("scipy=1.7.3")) # works
M("scipy=1.7.3=py37hd18d958_0").match(M("scipy==1.7.3")) # fails
M("scipy=1.7.3=py37hd18d958_0").match(M("scipy ==1.7.3")) # fails
M("scipy=1.7.3=py37hd18d958_0").match(M("scipy 1.7.3 *")) # fails
M("scipy=1.7.3=py37hd18d958_0").match(M("scipy=1.7.3=*")) # fails
M("scipy=1.7.3=py37hd18d958_0").match(M("scipy[version=1.7.3]")) # fails
M("scipy=1.7.3=py37hd18d958_0").match(M("scipy[version=1.7.3,build=*]")) # fails🤷 The reason why |
|
I looked into it a bit a more and turns out that |
|
Opened #289 |
|
Thank you for the quick response @jaimergp! It's pretty wild that the double equal fails because that's the only example I could find in the conda docs 😅 I tried using the single equals and added the following line to the Dockerfile but unfortunately it looks like conda completely ignores the pin file and goes ahead with the update. The doc example seems pretty straightforward 😕 |
|
I spoke a bit too fast and while the logic of our code in conda-libmamba-solver looked solid, the underlying implementation was faulty. We were running into weird corners of MatchSpec parsing, yes, but we shouldn't be calling |
|
Thank you all for the incredibly quick turnaround on this issue, and for addressing all of my concerns! I can't believe how fast this change got into I look forward to using |
Checklist
What happened?
Libmamba fails to resolve an environment when the env was originally created with build strings, and has since had a pin file inserted.
Below is the stack trace encountered (apologies... it's big)
Conda Info
Conda list
Additional Context
I've created a Dockerfile which recreates this issue easily and reliably.
There are 2 dependent files,
pinnedandrequirements.txtpinned:
requirements.txt
Dockerfile
Simply run
docker build .to experience the traceback yourself :)Please let me know if there's anything else I can do to help! (I apologize in advance if this is the wrong repo for this issue, please let me know if you need me to recreate this somewhere else)
The text was updated successfully, but these errors were encountered: