Open JeanChristopheMorinPerso opened 7 months ago
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
really is the odd one out since it causes a bunch of implicit special handling to happen.
Changing noarch: generic
to not do any variant handling would be a breaking change (and python
should be handled like any other dependency in that case [yeah, the old build string customization still happens, unfortunately...]).
Since conda-build
is a bit peculiar with its implicit "variant handling happens if it's a bare build dependency and also has entries in conda_build_config.yaml
", you'd have to workaround this if you want to suppress that variant handling by adding some version/build specification instead of just the bare package name.
E.g., in your case, you'd want something like - python >="sensible lower bound"
instead of just - python
in the requirements.
Checklist
What happened?
When using
noarch: generic
in a recipe that has multiple outputs and that depends on python, ifpython
is found in added tohost
, then conda-build will no generate a generic noarch variant.For example, let's take this recipe:
If I run
conda build <feedstock> --output
, it will print(notice how packages would go in
noarch
but are still python version specific).Now, if we take the same recipe and remove
python
from host:and run
conda build --output
again, I get:I was expecting the first case to only generate one variant (a fully generic variant).
Conda Info
Conda Config
Conda list
Additional Context
No response