Note that there seems to be relatively new way for users to switch between blas versions: https://conda-forge.org/docs/maintainer/knowledge_base.html#blas

That's only for users getting their packages from conda-forge not for using conda-build locally, though? So rather something for the conda-feedstock package than for the instructions here?

Sure, but it begs the question for me why Slycot wants to try to provide conda build instructions for non-defaults/conda-forge dependencies. Building a compatible set of conda binaries locally has to pull dependencies from somewhere or you have to build the whole stack locally. Mixing the underlying blas/lapack/etc libs with those in conda-forge and defaults is likely asking for trouble.

What is the reason for having these conda build scripts in slycot at this point in time? Doesn't the setup.py that's now powered by scikit build let users do custom installations sufficiently?

Totally agree, that the current mixing is asking for trouble.

The linked article implies that it should not matter against which library the build is linked during compile time, because the implementations should be ABI compatible. Maybe we are overcomplicating things here and if we still want to provide a recipe just give a single default one?

I'm not sure why we maintain these conda-build recipes, especially given the existence of slycot-feedstock.

The recipes in the feedstock are normal conda recipes. I just tested on Ubuntu 20.04. I cloned the feedstock recipe, cd'd into the recipe directory, and did conda build -c conda-forge .. It built successfully and passed the tests. There are some parts of the recipe that are specific to conda forge, e.g. disabling the python 2.7 builds for windows, which a user would have to remove if they wanted to do that build.

OK, but at the top of the recipe is this:

{% set version = "0.3.5.0" %}
{% set sha256 = "cad98d5ea4f0a034cf398c39189f587620a0b03f1d4b71e77cd622a327f13adf" %}

package:
  name: slycot
  version: {{ version }}

source:
  url: https://pypi.io/packages/source/s/slycot/slycot-{{ version }}.tar.gz

which means 0."build 3.5 from PyPI", right? This is appropriate for the feedstock, but doesn't easily let one build other versions.

This is all OK, I just want to be sure I understand.

A user can change the version number and see if it builds, but if you want to make old builds you would likely need to checkout a prior commit in the feedstock recipe corresponding to a previous version. But, that said, keeping old builds working as time passes will get increasingly hard due to updates in conda, conda build, and any dependencies. You'd have to build with old versions of conda and put max versions on the dependencies, etc.

I think the question is more about building a more recent version from the git repository instead of the released 0.3.5 (or hopefully soon 0.4.0). Even then it is just a matter of adjusting the source tag.

Yes, the general practice in conda forge is to point ot "official" releases on PyPi (so that it parallels what pip install does).

Of course, because that is what you want to have in the conda channel.

Now, if a user wants to compile a newer version of Slycot, say because there is a new feature in master or even in a PR that has not been released yet. Can he or she take the conda-forge recipe, use it for the checked out commit in question and install it in his or her environment? Sure. Question is, should we provide instructions for it or?