merge c_stdlib_version & MACOSX_DEPLOYMENT_TARGET on osx by h-vetinari · Pull Request #1889 · conda-forge/conda-smithy (original) (raw)

According to that pr we're supposed to add an additional zip of the deployment target.

OK, retesting with that added zip now breaks this PR, for reasons that escape me:

  File "[...]\dev\conda-forge\conda-smithy\conda_smithy\configure_feedstock.py", line 615, in _collapse_subpackage_variants
    used_key_values = conda_build.variants.list_of_dicts_to_dict_of_lists(
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "E:\miniforge\envs\smithy-dev\Lib\site-packages\conda_build\variants.py", line 634, in list_of_dicts_to_dict_of_lists
    values = list(zip(*set(zip(*(squished[key] for key in group)))))
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "E:\miniforge\envs\smithy-dev\Lib\site-packages\conda_build\variants.py", line 634, in <genexpr>
    values = list(zip(*set(zip(*(squished[key] for key in group)))))
                                 ~~~~~~~~^^^^^
KeyError: 'c_stdlib_version'

I've tried debugging this locally, and it seems to be going wrong after _get_used_key_values_by_input_order; by then the used_key_values dict contains basically (trimmed):

{'MACOSX_DEPLOYMENT_TARGET': [],
 'c_compiler': ['clang'],
 'c_compiler_version': ['16'],
 'c_stdlib': ['macosx_deployment_target'],
 'c_stdlib_version': [],
 'cxx_compiler': ['clangxx'],
 'cxx_compiler_version': ['16'],
 'target_platform': ['osx-64'],
 'zip_keys': [('c_stdlib_version', 'MACOSX_DEPLOYMENT_TARGET')]}

In other words, the values for c_stdlib_version/MACOSX_DEPLOYMENT_TARGET are an empty list, which (AFAIU) later gets filtered out, which is why we eventually hit that KeyError.

Looking at the function _get_used_key_values_by_input_order, there's a distinction for handling values that are part of a zip and those that aren't (c_stdlib_version isn't part of the zip for osx as of conda-forge/conda-forge-pinning-feedstock#5672; conda-forge/conda-forge-pinning-feedstock#5669 readds it).

Long story short, we're not robust to (all flavours of) zipping here yet, and I'm not sure exactly what's going wrong.