Using conda tools during a cibuildwheel run on github actions

[andyfaff]

I'm currently using the pypa/cibuildwheel github action to build a wide range of wheels in CI. On macOS it's very complicated to install the requisite compilers (incl. gfortran) to achieve a range of MACOSX_DEPLOYMENT_TARGET, across the two architectures.
The compilers that exist on the github runner images are ok for some matrix entries, but not others. This requires installation of bespoke and repackaged gfortran compilers from a range of places depending on the matrix entry.

What I'd like to do is use the conda-forge compilers package for the entire matrix. conda-forge has all the compilers i need for each of the matrix entries. Otherwise I don't wish to use any conda derived dependency in the build.

In a previous step in the CI configuration I can install conda from a bash shell without issues. I install the conda-forge compilers package into the base environment, and everything seems ok.

However, for the life of me I can't figure out how to activate and use the base conda env in the pypa/cibuildwheel action.
I experimented with activation commands placed in CIBW_BEFORE_ALL and CIBW_BEFORE_BUILD, but the commands in those environment variables are run with bash, they're not sourced. Therefore any activation doesn't stick around for the Building wheel... step.

My questions are:

• is there a way of activating and using a conda environment in the pypa/cibuildwheel action?
• what would be the hazards of using a conda-forge provided compiler for building the wheels?
• does the pypa/cibuildwheel action use ~/.profile/~/.bashrc /~/.bash_profile in its initialisation of the bash shell? (this is where conda environments are properly initiated when a shell is commenced).
• why do the commands in CIBW_BEFORE_ALL and CIBW_BEFORE_BUILD get called via bash $CIBW_BEFORE_ALL rather than source $CIBW_BEFORE_ALL.

[mattip]

There was some previous discussion on #773

[rgommers]

This question is only relevant for gfortran I believe; for C/C++ compilers the default ones in the Docker images or GHA runner images are fine. I think for SciPy we'll want to stay with the currently used gfortran for another year, and after that we will probably have no Fortran code left.

For OpenBLAS the problem won't go away. The Linux gfortran provided by conda-forge can be used without activation, the macOS one not yet. Windows probably also not.