cannot switch to openblas, outdated #106
Comments
|
You have some dependency requiring MKL in your environment which makes it impossible to switch to OpenBLAS. |
|
Try creating a new environment and figure out the package that requires MKL and make an issue on that package's feedstock about supporting OpenBLAS too. |
|
I am struggling with the tooling, but I am fairly certain, that the culprit is libopenblas depending on really old libflang 5.0.0, just as my initial post already indicates: from win-64/libopenblas-0.3.24-pthreads_hc140b1d_0.conda {
"arch": "x86_64",
"build": "pthreads_hc140b1d_0",
"build_number": 0,
"constrains": [
"openblas >=0.3.24,<0.3.25.0a0"
],
"depends": [
"libflang >=5.0.0,<6.0.0.a0",
"ucrt >=10.0.20348.0",
"vc >=14.2,<15",
"vc14_runtime >=14.29.30139"
],
"license": "BSD-3-Clause",
"name": "libopenblas",
"platform": "win",
"subdir": "win-64",
"timestamp": 1693789835449,
"version": "0.3.24"
} |
|
Could you please try with a fresh env that just installs Edit: If that works, then can try layering other things on top to find when the issue shows up |
|
That is exactly what I did in my last comment. |
|
It looks like the last comment does some inspection of the environment and packages generally. Not seeing where a fresh environment was created. Maybe I'm missing something Would suggest pulling that into a fresh comment or editing the previous comment to call that out more. In particular am looking for a |
|
|
The difference between the envs in |
It's your assumption that this is the reason for the original problem, and I don't think that's the case. Everything we have for openblas on windows is using libflang 5. From your initial environment: try if you can do without clang/compiler-rt etc. flang now exists in LLVM 17 and having clang 17 might easily lead the solver astray. |
And that is the reason. Why do you do that? Edit: Strike the last statement. We stopped trying to make Slycot work with openblas on Windows a log time ago. |
Because there was no usable newer flang until very recently. But you shouldn't have to concern yourself with flang at all. Just using |
|
Unfortunately that only seems to be true when compiling it inside a feedstock: When I do plain requirements:
build:
- {{ compiler('fortran') }}
- {{ compiler('c') }}
- cmake >=3.14
- make # [linux]
host:
# Always build against NETLIB ('Generic') LAPACK/Blas
# https://conda-forge.org/docs/maintainer/knowledge_base.html#blas
- libblas
- libcblas
- liblapack
- python
- numpy >=1.19,!=1.23.0
- pip
- scikit-build >=0.15
- setuptools >=45
- setuptools_scm >=7
run:
- python {{ PY_VER }}
- {{ pin_compatible('numpy') }} |
|
If you're using our compilers out of our infrastructure, then you're pretty much on your own. In particular, you'll have to at least ensure you do something equivalent to our migrations and global pinning in your local |
|
Sorry, I am very confused here. Are you saying that using the conda/mamba tools with a strict conda-forge channel pinning and adhering to the docs, like https://conda-forge.org/docs/maintainer/knowledge_base.html, is not supported outside of any feedstock CI build? I am pretty sure that I do not pin to vs2017 anwhere. I have posted the requirements of the recipe above. Beyond that there is just this: # build-env.yml
name: build-env
dependencies:
- conda-build
- numpy !=1.23.0And the github actions workflow: - name: Setup Conda
uses: conda-incubator/setup-miniconda@v2
with:
python-version: ${{ matrix.python }}
activate-environment: build-env
environment-file: .github/conda-env/build-env.yml
miniforge-version: latest
miniforge-variant: Mambaforge
channel-priority: strict
auto-update-conda: false
auto-activate-base: false
- name: Conda build
shell: bash -l {0}
run: |
set -e
numpyversion=$(python -c 'import numpy; print(numpy.version.version)')
conda build --python "${{ matrix.python }}" --numpy $numpyversion conda-recipe |
Using packaged artefacts is obviously supported, though the compilers are a different story. Some people do use them, but there are not a lot of guard-rails, and quite a few pitfalls. But you're not just using I don't know what your usecase is for wanting to build your package with conda in your CI - if it's to ensure compatibility with the conda recipe, then this can be done, but is non-trivial. Arrow does so, for example, but what they've done essentially is copy over the build scripts and configuration from the feedstock (including e.g. the There are long-term plans for other people to be able to hook into our build & migration infrastructure, but at the moment that's pretty much the status quo. |
|
Our compilers do see a fair bit of usage on Linux & macOS where they work pretty well The Windows story is a bit rougher since it often requires some kind of Visual Studio install (or in some cases the CLI tools from Visual Studio can work) |
That's true, though so far not explicitly documented as supported. I guess by Hyrum's law we're already "condemned" to support it, unless we really want to put our foot down (which is probably neither necessary nor worth it in this instance). There's an issue to come up with (or at least document) a policy around that. |
Which is ironic, because those platforms have a decent compiler and tooling infrastructure on their own. The strength of conda is to provide that infrastructure to the python world on Windows.
Thank you for this explanation. I was not aware that documentation like https://docs.conda.io/projects/conda-build/en/stable/resources/compiler-tools.html does not 100% apply to conda-forge. We do indeed build Slycot in our CI in order to make sure that users can use Slycot with conda-forge as well as build it on their own. Obviously the current recipe does not do that with 100% correct assumptions. |
Solution to issue cannot be found in the documentation.
Issue
Trying to investigate python-control/Slycot#219, I am unable to install openblas:
vcis available as >= 14.1Installed packages
Environment info
The text was updated successfully, but these errors were encountered: