mamba-org/boa

boa 0.11 WORKS vs boa 0.14 DOES NOT given the following recipe

Opened this issue · 2 comments

alexshagiev commented 
# root
requirements:
  host:
    - python =>3.10
   run:
    - python =>3.10
    - other_pkg ==3.0.0
#other_pkg
requirements:
    - python =>3.10
   run:
    - python =>3.10
    - pexpect
    - tabulate
    - pandas

boa 0.11 completes the build successfully by installing python 3.10
boa 0.14 fails with error

Mamba failed to solve:
 - python >=3.10
 - other_pkg ==3.0.0
 - python_api 3.11.* *_cp311
 
with channels:

The reported errors are:
- enchountered problems while solving:
-     - package python_abi-3.11-2_cp311 requires python 3.11.* but none of the providers can be installed
wolfv commented

Hi @alexshagiev thanks for filing this issue.
I think I have an idea on what happens.

We've more properly integrated "run_exports" support into boa in later releases.

So what happens is that there are "run-exports" applied from your host requirements to the run requirements. For example, python has a run_exports.json that specifies that whenever you have python 3.X in host, python_abi 3.X.* will be added to your run dependencies.

Now since you have only python in your host dependencies, the solver chooses the highest permissible version (3.11). This implicitly exports / adds the python_abi-3.11-2_cp311 to the run dependencies.

However, during solving maybe one of the additional dependencies (like pexpect or pandas) is not actually available for python 3.11 and then the resolution fails.

OK, I just realized that python actually does need special handling and they have a special run_exports (noarch) here: https://github.com/conda-forge/python-feedstock/blob/21038d707640da7b5da152a5239e199c720f0574/recipe/meta.yaml#L130-L134 that apparently removes the version specifier which might be missing in boa. I'll fix that!

wolfv commented

OK, I checked in the source code of boa and it does seem like it should be correctly handled:

boa/boa/core/recipe_output.py

Lines 483 to 507 in c0fdcc3

if env == "build":
for rex in collected_run_exports:
if not self.noarch:
for r in rex.get("strong", []):
append_or_replace("host", r)
append_or_replace("run", r)
for r in rex.get("weak", []):
append_or_replace("host", r)
for r in rex.get("strong_constrains", []):
append_or_replace("run_constrained", r)
if env == "host":
for rex in collected_run_exports:
if not self.noarch:
for r in rex.get("strong", []):
append_or_replace("run", r)
for r in rex.get("weak", []):
append_or_replace("run", r)
for r in rex.get("strong_constrains", []):
append_or_replace("run_constrained", r)
for r in rex.get("weak_constrains", []):
append_or_replace("run_constrained", r)
else:
for r in rex.get("noarch", []):
append_or_replace("run", r)

So either you are trying to build a noarch package without the

build:
  noarch: python
# ...

in your recipe or there is some other bug in mamba. Can you share a more complete recipe?

If you want to be explicit about your Python version (when it is not a noarch package), then you should create a conda_build_config.yml file that has keys such as these: https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/ea0b69c0276fbed957ddca1f521e9e92d9dd4582/recipe/conda_build_config.yaml#L655-L659

python:
  # part of a zip_keys: python, python_impl, numpy
  - 3.8.* *_cpython
  - 3.9.* *_cpython
  - 3.10.* *_cpython

In that case, you should have no version specifier for python in your recipe at all and pass in the pins with -m conda_build_config.yml. That will then create a matrix of builds (three in this case) for each python version. But this is only relevant when noarch does not work (e.g. when you have compiled Python extensions.../