-
-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot install scikit-learn from conda-forge channel alongside pytorch from the pytorch channel #271
Comments
Hi @anjos, I confirm I can reproduce this issue for
Your analysis is right (LLVM version are forward between major versions, hence the use of
This is quite constraining LLVM 16 (and thus
I guess it is so that PyTorch stays in line with conda-forge's global pinning constrained linked above; you can open an issue on
Unless a really hard constrain explaining the reason for this pin's existence is known, I think that the problem should rather be solved upstream directly than by introducing new build variants of package on conda-forge for llvm 15 (LLVM 17 will soon be used on conda-forge, see conda-forge/conda-forge-pinning-feedstock#4890). Do you know if the rationale behind this pin documented somewhere? |
Right, I forgot that platform constraint (I'm also on osx-arm64). I have not found any rationale for the tight pin on llvm <= 16, but I have not looked deeply into how those packages are built, simply because IDK where are the recipes. I'll do a little digging and report back. |
I do not know of equivalents of the feedstock for the pytorch channel, but the recipes are stored within one of the packages' archive as well, so you can manually download one of the pytorch package and inspect it. |
Thanks. I was thinking about looking for the build repo and then check if this has not been somewhat reported there. Then, I think I'll open an issue and possibly link this one for a discussion and solution. It may indeed be the case that the pin is just too restrictive w/o a strong reason on the upstream side. If that turns out to be absolutely required, then we should go back and push conda-forge's pytorch version to adopt the same strategy, and think about an overall solution that would work so both packages can co-exist. Do you agree with this strategy? |
The restrictive pinning seems to be coming from here. Which, in turn, links to this open issue on the upstream repository: pytorch/pytorch#99625 |
@jjerphan: I went around and linked all relevant issues. I also opened a new issue on the build repositories that eventually dump pytorch packages on the |
Thank you. |
Just to chime in to help out the scikit-learn maintainers.
the pytorch channel, to my knowledge, is designed for compatibility with the You can install scikit-learn with pytorch just fine from conda-forge packages: mamba create --strict-channel-priority --override-channels -c conda-forge -n test --dry-run 'scikit-learn>=1.4' 'pytorch>=2.3'
If you want the latest + latest packages, you can't have pinnings like pytorch put on llvm. I understand that temporarily it is necessary to do so, but in general please try to stick to the the following combination of channels
|
Thanks @hmaarrfk . I think then we can close this one as "wontfix" since it's not really a scikit-learn or a conda-forge issue. |
Solution to issue cannot be found in the documentation.
Issue
There seems to be no way to have these 2 packages installed together:
>=1.4
(from this feedstock)>=2.3
(from pytorch channel)Test command:
The problem seems related to this package's dependency on
llvm-openmp
. The latter is pinned at build time to the build-time version of that package (using>=
), if I understand well (c.f.: #265, conda-forge/openmp-feedstock#126).It so happens pytorch (on the pytorch channel) has introduced a tight requirement on
llvm-openmp
(has to be '<16', starting from version 2.3). This introduces a conflict because most versions of scikit-learn that were built in the past months end-up getting a>=16
runtime constraint.(N.B.: For some reason I do not understand, pytorch from conda-forge channel does not introduce this pin yet. For this reason, version 2.3.0 and 2.3.1 are available from the conda-forge channel and do install correctly. However this does not solve our issues since we need the latest changes in version 2.4.0.)
Concretely, the situation is such that one cannot install later versions of pytorch from the pytorch channel and this package without incurring in resolution problems.
I wonder if a rebuild of this package using
llvm-openmp<16
could be considered, or if another solution could be found to allow co-existence with pytorch@pytorch? (I'm asking this here because this package does not have a strict requirement for llvm-openmp whereas pytorch seems to.)Installed packages
Environment info
The text was updated successfully, but these errors were encountered: