Why isn't this package `noarch`?

[rgommers]

I am currently unable to upgrade to pythran 0.13.1 on macOS arm64, which led me to look at whether the package exists (it does) and what the problem is (something that should be unrelated, see the end of this issue description).

There's a note here about ABI compatibility that I don't understand: https://github.com/conda-forge/pythran-feedstock/blob/9a2de8382f3ee795c537c4f9ffe94b03db6546b5/recipe/meta.yaml#L43-L50.

The package build does not do any compilation: https://github.com/serge-sans-paille/pythran/blob/e3babfd43030a54f90b588d5e66451175be6b886/setup.py#L60-L108. So why can't this package simply be noarch? It's pure Python, and on PyPI it is py3-none-any: https://pypi.org/project/pythran/0.13.1/#files.

Install error on macOS arm64:

Looking for: ['pythran=0.13.1']

conda-forge/osx-arm64                                       Using cache
conda-forge/noarch                                          Using cache

Pinned packages:
  - python 3.10.*

Encountered problems while solving:
  - nothing provides cctools_osx-arm64 973.0.1 h92b3a8a_0 needed by cctools-973.0.1-ha9384d2_0

[jakirkham]

Can't comment on the particular build choices here without looking into it more

However this could be added to the macOS ARM migrator, to get macOS ARM builds started (independent of how this issue shakes out)

[h-vetinari]

However this could be added to the macOS ARM migrator,

We're building for osx-arm64 here already. I don't know what's happening in this case, however the 973.0.1 *_0 builds of cctools are extremely old (currently we're on build number 15). Apparently they're also broken, which is presumably why the solver cannot find them.

So for some reason, the resolver there gets pushed into trying clang 12 (which is what 973.0.1 *_0 depends on) -- that itself is weird, but I don't know what would cause that.

The package build does not do any compilation. So why can't this package simply be noarch? It's pure Python, and on PyPI it is py3-none-any:

Pythran itself may be pure python, but using it requires a C++ compiler. I think that's the idea behind the dependency at least (and of course, on pypi, pythran couldn't depend on a compiler even if it wanted to).

In any case, I'm fine with removing the compiler here on unix (it just means consumers will have to add it; on windows I'd prefer to leave clang as that's not our default compiler and thus less obvious). With recent improvements around noarch, we might still pull that off even so...

In the meantime, perhaps @saraedum can explain the thinking behind dc16a8acd6bed1a54c93379d44b234759f2c59e2.

CC @serge-sans-paille @isuruf

[rgommers]

I think that's the idea behind the dependency at least

If it needs to be kept on Windows, can it be a runtime dependency? Nothing happens at build time.

[jakirkham]

Related question, should we consider using the c-compiler and cxx-compiler packages as dependencies?