BUG: spurious conflict between exact pins #5573
Labels
type::bug
describes erroneous operation, use severity::* to classify the type
Comments
h-vetinari
added
the
type::bug
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Checklist
What happened?
The feedstock for the blas-metapackage in conda-forge has some peculiarities. One thing that has been a long-standing issue is that
blisonly supports BLAS, not LAPACK, and so to turn it into a full-fledged flavour for our BLAS/LAPACK stack, we need to supplement it with thenetlibvariant from https://github.com/Reference-LAPACK/lapack.However, when we do that in the recipe, this runs into issues, presumably because conda-build merges the variants too eagerly at some point, and then gets confused. The recipe itself is logically sound, e.g.
where
liblapack/liblapackeare skipped forblas_impl == 'blis'.Isuru added a workaround in an ancient commit (conda-forge/blas-feedstock@f9b54a0), with a comment "Building with blis fails due to a conda-build bug" -- I had been trying to figure out for a while what was going on, and finally opened conda-forge/blas-feedstock#115 to be able to raise an issue here.
Interestingly, the PR that gets rid of the work-around sometimes passes (like my most recent push there)! No idea what lucky stars determine this. When it did fail, it looked like
i.e. the variant confusion I mentioned above.
I've now picked the fix into yet another PR (conda-forge/blas-feedstock#130) due to running into #5571 elsewhere. And now I get yet another manifestation of this bug, but one that makes even less sense:
The state of that recipe (h-vetinari/blas-feedstock@986e58d) unambiguously uses the build-number 27 for all the buildstrings in the recipe, and consistently uses exact
pin_subpackagefor all subpackage operations (at least as restricted to blis). So the fact that a previous build number (26) shows up here at all is very surprising and means that the solver somehow would prefer published packages over local ones, despite the fact thatpin_subpackage(..., exact=True)should make impossible.Conda Info
++ conda info active environment : base active env location : /opt/conda shell level : 1 user config file : /home/conda/.condarc populated config files : /opt/conda/.condarc /home/conda/.condarc conda version : 24.11.1 conda-build version : 24.11.2 python version : 3.12.8.final.0 solver : libmamba (default) virtual packages : __archspec=1=broadwell __conda=24.11.1=0 __glibc=2.34=0 __linux=6.5.0=0 __unix=0=0 base environment : /opt/conda (writable) conda av data dir : /opt/conda/etc/conda conda av metadata url : None channel URLs : https://conda.anaconda.org/conda-forge/linux-64 https://conda.anaconda.org/conda-forge/noarch package cache : /home/conda/feedstock_root/build_artifacts/pkg_cache /opt/conda/pkgs envs directories : /opt/conda/envs /home/conda/.conda/envs platform : linux-64 user-agent : conda/24.11.1 requests/2.32.3 CPython/3.12.8 Linux/6.5.0-1025-azure almalinux/9.5 glibc/2.34 solver/libmamba conda-libmamba-solver/24.11.1 libmambapy/2.0.5 UID:GID : 1001:1001 netrc file : None offline mode : FalseConda Config
Conda list
The text was updated successfully, but these errors were encountered: