Marcel Bargull

AFAICT, this is "working as intended" in that the normal "entry in `requirements/host` induces variant differentiation". Note that `noarch: generic` should mostly behave like the non-`noarch` build. Meaning, `noarch: python`...

I just ran into a similar thing at https://github.com/conda-forge/python-feedstock/pull/656#discussion_r1428500644 . @beckermr suggested to try out setting `PYTHONHASHSEED` to get a reproducer -- and I got lucky to quickly get one...

It could be that the assumption from https://github.com/conda-forge/conda-smithy/blob/v3.30.1/conda_smithy/configure_feedstock.py#L354-L355 fails because we add `top_level_vars` later in https://github.com/conda-forge/conda-smithy/blob/v3.30.1/conda_smithy/configure_feedstock.py#L384 . Meaning, possibly we only have to move the `preserve_top_level_loops` assignment after `all_used_vars` is...

> It could be that the assumption from https://github.com/conda-forge/conda-smithy/blob/v3.30.1/conda_smithy/configure_feedstock.py#L354-L355 fails because we add `top_level_vars` later in https://github.com/conda-forge/conda-smithy/blob/v3.30.1/conda_smithy/configure_feedstock.py#L384 . Meaning, possibly we only have to move the `preserve_top_level_loops` assignment after `all_used_vars`...

@AlbertDeFusco , the CI was probably affected by https://www.githubstatus.com/incidents/x39xrr5m11b3 . Please restart again and push any necessary changes to this branch at will.

I took another look at the CI log and it seems the path to the Conda installation simply changed from `/usr/share/miniconda3` to `/usr/share/miniconda`.

CI failures are unrelated to the changes here (mostly probably just test code needing adjustments to changes in `anaconda-client`) and out of scope for this pull request.

One question upfront: Are there any intended restrictions on `grayskull`'s dependencies or how it operates? If one were to port `conda_build.skeletons.cpan` more or less exactly, we'd need to depend on...

Thanks for doing this! I think having the `::conda` scope is a good and reasonable thing to get this going! In the future we may want to address the external...

N.B.: I have not looked into how the logging code is used with `conda>=4.12` and hence don't know what additional changes are needed besides reverting the `logger.setLevel(NOTSET)`/`handler.setLevel(level)` changes. ... and...