pythonazure-pipelinescondapytablesconda-forge

"[lib] requires [dep], which is not installed" when running PR tests on conda-forge feedstock, despite explicit call in grayskull-generated meta.yaml


I'm trying to upgrade the conda-forge version of xagg to the latest version (v0.3.0). The built-in Azure Pipelines tests that run when I set up a PR of the feedstock into the conda-forge repository however fail, with the error:

import: 'xagg'
import: 'xagg'
+ pip check
xagg 0.3.0 requires pytables, which is not installed.

(the full log is here)

The odd thing is that pytables is explicitly mentioned in the meta.yaml (which was generated through grayskull and is listed in the PR changes here), and, at least according to the test log, was correctly installed into the test docker environment:

The following NEW packages will be INSTALLED:

[snip]

pytables:                  3.7.0-py310hf5df6ce_0             conda-forge

[snip]

DEBUG:urllib3.connectionpool:https://conda.anaconda.org:443 "GET /conda-forge/linux-64/pytables-3.7.0-py310hf5df6ce_0.tar.bz2 HTTP/1.1" 200 4914957

[snip]

Preparing transaction: ...working... done
Verifying transaction: ...working... done
Executing transaction: ...working... done

Does anyone have any advice on how to troubleshoot this? The suggestions I've seen so far are to explicitly list the dependency in the meta.yaml, which I have.

I believe this may be a similar issue to this question, though for an optional package, not a built-in one.

Grateful for any help!


Solution

  • The Conda recipe looks fine. It's actually the upstream package that was broken, as indicated by the failure of pip check.

    Namely, pip check ensures that the packages listed as dependencies in the setup.py are all installed. However, the v3.0.0 release lists a pytables package, which is not a valid PyPI package. Instead, this should have been simply tables.

    Perhaps, this confusion arose because in the Conda ecosystem the Python package tables goes by the name pytables. This is simply part of the issue with having a generic package manager - packages across language ecosystems have namespace collisions, and therefore get renamed with a prefix or some other modifier (e.g., all CRAN packages have r- prefixed). So, in the Conda recipe one indicates the Conda package name (pytables), but pip check will verify that this actually makes the tables module available.