'Unregistered SAT variable name' #202
Comments
|
Which versions of conda/ mamba are you using in conjunction with conda-lock? |
|
For complex dependencies like geopandas I would strongly recommend using mamba |
|
The problem is not just Yes, updating Looking closely at the error message to identify the command that failed, we see: The unexpected thing here is So, how and why is conda-lock using a local temp dir as a channel, and what needs to be fixed in the conda-lock implementation to prevent this "Unregistered SAT variable name" within this temp dir? |
|
I have seen this error in various complicated configurations, but never got around to tracking it down. I'm trying to get the CI working again in the context of #240, and this is occurring in the CI pytest runs. |
|
Looking into the source code, from what I can gather, the "virtual package channel" which @gabe-microsoft indicates is being used by conda-lock to inject virtual packages. These mechanisms are completely new to me, so I'm hoping that @mariusvniekerk can shed some light here, and hopefully suggest a way to resolve it. The temp directory contains a subdirectory for each platform: Each subdirectory contains a single linux-64/repodata.json{
"info": {
"subdir": "linux-64"
},
"packages": {
"__archspec-1-x86_64_0.tar.bz2": {
"build": "x86_64_0",
"build_number": 0,
"build_string": "x86_64",
"depends": [],
"name": "__archspec",
"noarch": "",
"subdir": "linux-64",
"timestamp": 1577854800000,
"version": "1"
},
"__cuda-11.4-0.tar.bz2": {
"build": "0",
"build_number": 0,
"build_string": "",
"depends": [],
"name": "__cuda",
"noarch": "",
"subdir": "linux-64",
"timestamp": 1577854800000,
"version": "11.4"
},
"__glibc-2.17-0.tar.bz2": {
"build": "0",
"build_number": 0,
"build_string": "",
"depends": [],
"name": "__glibc",
"noarch": "",
"subdir": "linux-64",
"timestamp": 1577854800000,
"version": "2.17"
},
"__linux-5.10-0.tar.bz2": {
"build": "0",
"build_number": 0,
"build_string": "",
"depends": [],
"name": "__linux",
"noarch": "",
"subdir": "linux-64",
"timestamp": 1577854800000,
"version": "5.10"
},
"__unix-0-0.tar.bz2": {
"build": "0",
"build_number": 0,
"build_string": "",
"depends": [],
"name": "__unix",
"noarch": "",
"subdir": "linux-64",
"timestamp": 1577854800000,
"version": "0"
}
}
}The error message I'm getting is: which corresponds to the last listed virtual package. I'm not sure yet why this is causing conda to choke... |
|
I have spent some time with the debugger tracing what leads up to this error. I think I more-or-less understand what's causing it. Here are my findings: The PackageRecord(**(info := {
'arch': None,
'build': '0',
'build_number': 0,
'build_string': '',
'channel': Channel("tmpologha1x/linux-64"),
'depends': [],
'fn': '__unix-0.0-0.tar.bz2',
'name': '__unix',
'noarch': '',
'platform': None,
'schannel': 'file:///tmp/tmpologha1x',
'subdir': 'linux-64',
'timestamp': 1577854800000,
'url': 'file:///tmp/tmpologha1x/linux-64/__unix-0.0-0.tar.bz2',
'version': '0.0'}))Conda itself injects its own virtual packages named name = "__unix"
PackageRecord(
package_type=PackageType.VIRTUAL_SYSTEM,
name=name,
version=version or '0',
build_string=build_string,
channel='@',
subdir=context.subdir,
md5="12345678901234567890123456789012",
build_number=0,
fn=name,
)Note that the This For whatever reason it seems that the SAT problem is unsatisfiable, and then I end up here calling Now the problem is clear (if you implausibly actually took the time to understand all of the above...) We have filtered out conda-lock's virtual package from the resolver's 😅 We might be able to solve this by adding |
|
I think this is now fixed in |
running 'conda-lock -f environment.yml' on the following yaml fails:
but the following works:
with
conda 4.13.0 py39hca03da5_0
conda-lock 1.0.5 pyhd8ed1ab_1 conda-forge
conda-package-handling 1.8.1 py39h1a28f6b_0
I get the following output
The text was updated successfully, but these errors were encountered: