You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have an issue in the conda / mamba world where libsolv sometimes resolves to outdated versions because of some conflicting dependencies.
Specifically, we have the following situation: we try to resolve for two packages, python and jupyterlab.
There are two python package variants, one built against openssl 3.0 and one against openssl 1.1.1o. libsolv correctly prefers the version that is built against openssl 3.0.
However, when trying to find a matching jupyterlab version, a dependency of jupyterlab (cryptography) isn't available for openssl 3.0. This leads to libsolv finding a solution with a much older jupyterlab 2.x.
Instead, it would be good if we'd take the other python variant that is built against openssl 1.1.1 which would also work with the latest jupyterlab.
We can easily force this by asking for a jupyterlab >=3.0.
In mamba, I was planning to workaround this by adding a solver loop where we check for the latest available packages for every explicitly asked for package and try to resolve with those versions. If that fails, resolve as usual.
But now I was wondering if you think this could also be fixed or mitigated in libsolv?
The text was updated successfully, but these errors were encountered:
Hi @mlschroe sorry for the late reply. Unfortunately I don't exactly know how the test system works but I can describe a testcase that shoudl do the trick:
If you create two variants of python with the same version number:
python 3 openssl3
-> depend on openssl 3
python 3 openssl1
-> depend on openssl 1
And two different versions of jupyterlab:
jupyterlab 2
-> depend on openssl 1
jupyterlab 1
-> NO dependency on openssl
And you just make 2 versions of openssl 1 and openssl 3.
Now if you try to install python and jupyterlab, libsolv would select python -> openssl 3 + jupyterlab 1.
Does that make sense?
In mamba / libsolv we do prioritize the python that maximizes the dependency versions (in this case openssl 3). However, for this reason it will also choose an older jupyterlab version.
@banjiuqingshan does the explanation make sense for you as well?
We have an issue in the conda / mamba world where libsolv sometimes resolves to outdated versions because of some conflicting dependencies.
Specifically, we have the following situation: we try to resolve for two packages,
python
andjupyterlab
.There are two python package variants, one built against
openssl 3.0
and one againstopenssl 1.1.1o
.libsolv
correctly prefers the version that is built againstopenssl 3.0
.However, when trying to find a matching
jupyterlab
version, a dependency ofjupyterlab
(cryptography
) isn't available foropenssl 3.0
. This leads tolibsolv
finding a solution with a much olderjupyterlab 2.x
.Instead, it would be good if we'd take the other
python
variant that is built againstopenssl 1.1.1
which would also work with the latestjupyterlab
.We can easily force this by asking for a
jupyterlab >=3.0
.In mamba, I was planning to workaround this by adding a solver loop where we check for the latest available packages for every explicitly asked for package and try to resolve with those versions. If that fails, resolve as usual.
But now I was wondering if you think this could also be fixed or mitigated in
libsolv
?The text was updated successfully, but these errors were encountered: