azure CI Run docker build step for win and linux fails: python version mismatch during Configure conda

[dlaehnemann]

Bug:

@conda-forge/staged-recipes It seems like there is a newly occurring error that causes the win and linux builds to fail (but not the osx ones) on a number of recipes. I for example see this consistently coming up in the following PRs:

• package inline-snapshot #27023
• Add the plus_sync package plus its dependencies #27022
• feat: add new r-nanoparquet recipe #27021

This only started during the day, I was debugging a different problem earlier and the linux build in the last mentioned PR was running through. Here's the error and backtrace that comes up in all of these cases now (with a bit of leading context):

The following NEW packages will be INSTALLED:

  conda-env          conda-forge/noarch::conda-env-2.6.0-1 
  conda-forge-ci-se~ conda-forge/linux-64::conda-forge-ci-setup-4.7.0-py310h7a2d8a0_100 
  conda-forge-metad~ conda-forge/noarch::conda-forge-metadata-0.8.1-pyhd8ed1ab_0 
  conda-forge-pinni~ conda-forge/noarch::conda-forge-pinning-2024.07.18.05.06.15-hd8ed1ab_0 
  conda-oci-mirror   conda-forge/noarch::conda-oci-mirror-0.1.0-pyhd8ed1ab_0 
  decorator          conda-forge/noarch::decorator-5.1.1-pyhd8ed1ab_0 
  deprecated         conda-forge/noarch::deprecated-1.2.14-pyh1a96a4e_0 
  exceptiongroup     conda-forge/noarch::exceptiongroup-1.2.2-pyhd8ed1ab_0 
  iniconfig          conda-forge/noarch::iniconfig-2.0.0-pyhd8ed1ab_0 
  jq                 conda-forge/linux-64::jq-1.7.1-hd590300_0 
  networkx           conda-forge/noarch::networkx-2.4-py_1 
  oniguruma          conda-forge/linux-64::oniguruma-6.9.9-hd590300_0 
  oras-py            conda-forge/noarch::oras-py-0.1.14-pyhd8ed1ab_0 
  pytest             conda-forge/noarch::pytest-8.2.2-pyhd8ed1ab_0 
  rattler-build      conda-forge/linux-64::rattler-build-0.18.1-h72610f6_0 
  rattler-build-con~ conda-forge/noarch::rattler-build-conda-compat-0.1.2-pyhd8ed1ab_0 
  ruamel_yaml        conda-forge/linux-64::ruamel_yaml-0.15.80-py310h2372a71_1009 
  shyaml             conda-forge/noarch::shyaml-0.6.2-pyhd3deb0d_0 
  typing-extensions  conda-forge/noarch::typing-extensions-4.12.2-hd8ed1ab_0 
  typing_extensions  conda-forge/noarch::typing_extensions-4.12.2-pyha770c72_0 
  wrapt              conda-forge/linux-64::wrapt-1.16.0-py310h2372a71_0 

The following packages will be UPDATED:

  conda-libmamba-so~                    24.1.0-pyhd8ed1ab_0 --> 24.7.0-pyhd8ed1ab_0 
  openssl                                  3.3.1-h4ab18f5_1 --> 3.3.1-h4bc722e_2 


Preparing transaction: ...working... done
Verifying transaction: ...working... done
Executing transaction: ...working... done
+ setup_conda_rc /home/conda/staged-recipes /home/conda/staged-recipes-copy/recipes /home/conda/staged-recipes-copy/.ci_support/linux64.yaml
Traceback (most recent call last):
  File "/opt/conda/bin/setup_conda_rc", line 7, in <module>
    from conda_forge_ci_setup.build_utils import setup_conda_rc
  File "/opt/conda/lib/python3.10/site-packages/conda_forge_ci_setup/build_utils.py", line 15, in <module>
    from conda_forge_ci_setup.upload_or_check_non_existence import retry_upload_or_check
  File "/opt/conda/lib/python3.10/site-packages/conda_forge_ci_setup/upload_or_check_non_existence.py", line 18, in <module>
    import rattler_build_conda_compat.render
  File "/opt/conda/lib/python3.10/site-packages/rattler_build_conda_compat/render.py", line 23, in <module>
    from rattler_build_conda_compat.loader import parse_recipe_config_file
  File "/opt/conda/lib/python3.10/site-packages/rattler_build_conda_compat/loader.py", line 4, in <module>
    from typing import TYPE_CHECKING, Any, Iterator, Self
ImportError: cannot import name 'Self' from 'typing' (/opt/conda/lib/python3.10/typing.py)

So the issue here is that typing.Self was only added in python 3.11, but ehre miniforge is using pythong 3.10 somehow. So I am assuming something in the miniforge stack changed in the meantime. Maybe this is related to the planned python version upgrade over there (although nothing happened there in the past days / hours):
conda-forge/miniforge#603

Maybe some preparation for this upgrade already gets pulled in somewhere, and then clashes with the above PR not yet being merged?

But I am also not sure where exactly this happens over here, either. Probably here (for win, at least):

staged-recipes/.azure-pipelines/azure-pipelines-win.yml

Line 19 in 7a09bbe

url = 'https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Windows-x86_64.exe'

But I hope someone familiar with infrastructure here can get to the bottom of this quicker than me...

[isuruf]

Duplicate of conda-forge/status#183

[dlaehnemann]

Many thanks for catching and cross-linking this one, hadn't found it. So it looks like there will be a proper fix via rattler soon!