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?

[rgommers]

Bumped into this again, since it prevents me from setting up an environment for SciPy development with python-freethreading (working around it now by installing pythran from PyPI).

Looking at the answer again, this really doesn't add up. The build goes via a none-any wheel, there is no ABI involved. And there should not be a compiler dependency on any platform. Pythran is fundamentally a transpiler, and when you want to use it with a C++ compiler that can be MinGW just as well as Clang-cl on Windows, hence the hard clang dependency is counterproductive.

For comparison: there is also no compiler dependency for cython: https://github.com/conda-forge/cython-feedstock/blob/main/recipe/meta.yaml.

[rgommers]

The timing of this is a coincidence, but pythran pulling in compilers just broke SciPy's CI job for Intel compilers: https://github.com/scipy/scipy/pull/21950, illustrating the problems of a spurious dependency on compilers. The workaround is to install pythran from PyPI.

[czgdp1807]

I see. Yes. compilers shouldn't be needed for pythran because it works when installed from PyPI.

[isuruf]

With my PR, we don't install the compilers package which installs gxx_linux-64 and other packages that have activation logic. Now, only unactivated compilers are installed. So, it's a different issue than this one.

[rgommers]

Now, only unactivated compilers are installed.

That still matters, Intel compilers actually depend on the system GCC (or Clang) and system lib, and look for it at runtime. Even when not activated, I think it still finds the Conda compilers if installed in the active env. See for example https://github.com/intel/llvm/issues/13303, the workaround is _"use sysroot_linux-64==2.28 conda package"_.