I thought there was Conda-specific linking magic for that, as in one could choose per environment which linear algebra "backend" to use?

You can also do that without conda with Meson.

I think python-control is the biggest user of Slycot, but it's not the only one. It would be good to have Slycot compatibility in a new package.

Sure that won't be a problem since the number of wrappers are relatively low.

I'm not sure what to think about a new package: it seems like a lot of work, and we have what seems like a good-enough solution, except of course for Windows wheels. On Windows I use mambaforge, so I'm not affected by this short-coming.

Main issue is that pip install for windows is broken and there are no wheels for different architectures that easily. My problem with Slycot is the license to be honest. Other than that there won't be much difference in functionality

We have been using gfortran from MinGW and VS community edition compilers on Windows for generating wheels.

Typically what I do is to wrap things with f2py with a pyf file and generate a python module. You can find the gory details in SciPy meson files. The main issue is to link with OpenBLAS but you can find a precompiled OpenBLAS dll in your Python distro scipy/.libs or numpy/libs folder. It is the same machinery using MKL but I never tried it. The flang parts are typically conda related.

In the meantime, we have translated quite a bit of F77 code scipy/scipy#18566 so my opinion about feasibility of SLICOT translation work is definitely strengthened. Ideally no code should be left in F77 format in this day an age. With sufficient capacity, which is ample in the academia among young researchers, ROI of such work is quite high in case anyone interested. Thus, my attention is mostly porting F77 code to C or Cython. I am investigating whether this is feasible for LAPACK so SLICOT is surely possible. But that is not what you asked so I'll skip the details :) If you are interested here is a much longer diatribe scientific-python/faster-scientific-python-ideas#7

Your hints are very valuable to me, so thank you for the quick reply.

Porting SLICOT from F77 to C is an interesting alternative, but I agree with past-@ilayn 😉

Obviously the unicorn way would have been rewriting all this in anything other than F77 but that is a lot of work that I don't have too much time to spare [...]. So this seems like the second best thing to save things out of GPL licensed Slycot.