-
Notifications
You must be signed in to change notification settings - Fork 428
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
BUG: spurious conflict between exact pins #5573
Comments
After @jaimergp recommended replacing parts of the
It's still mega-weird to me that an old build number can ever be considered here. |
This keeps getting weirder and weirder. After replacing all
The output in question looks as follows (removed lines that get filtered away by selectors for other blas implementations) - name: blas
version: "{{ blas_major }}.{{ blas_minor }}"
script: test_blas.sh # [unix]
script: test_blas.bat # [win]
build:
string: {{ blas_impl }}
activate_in_script: True
requirements:
build:
- {{ stdlib("c") }}
- {{ compiler("c") }}
- {{ compiler("fortran") }}
- cmake
- ninja # [win]
- llvm-openmp # [linux and ((blas_impl == "openblas") or (blas_impl == "mkl"))]
host:
# don't pin libblas/libcblas exactly due to issues with exact=True,
# see https://github.com/conda/conda-build/issues/5573
- libblas ={{ version }}={{ build_num }}*_blis # [blas_impl == 'blis']
- libcblas ={{ version }}={{ build_num }}*_blis # [blas_impl == 'blis']
# netlib variants don't have the same build number
- liblapack ={{ version }}=*_netlib # [blas_impl == 'blis']
- liblapacke ={{ version }}=*_netlib # [blas_impl == 'blis']
run:
- blas-devel ={{ version }}={{ build_num }}*_blis # [blas_impl == 'blis']
- libblas ={{ version }}={{ build_num }}*_blis # [blas_impl == 'blis']
- libcblas ={{ version }}={{ build_num }}*_blis # [blas_impl == 'blis']
- liblapack ={{ version }}=*_netlib # [blas_impl == 'blis']
- liblapacke ={{ version }}=*_netlib # [blas_impl == 'blis']
test:
[...] So that error to me makes absolutely no sense whatsoever. However, when I remove the above-mentioned |
Or maybe it's a symptom of #5571. After I removed all the dependencies of
The build string in the last line is corrupted. |
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
blis
only 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 thenetlib
variant 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
/liblapacke
are 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_subpackage
for 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 Config
Conda list
The text was updated successfully, but these errors were encountered: