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:

pythran-feedstock/recipe/meta.yaml

Lines 43 to 50 in 9a2de83

	# To ensure ABI compatibility, we install the same version of the C++
	# compiler that was used when building. This is probably not necessary and
	# could be replaced with something like
	# {{ cxx_compiler }}_{{ target_platform }}
	- {{ compiler('cxx') }} # [not win]
	- clang # [win]
	- clangxx # [win]
	- python

.

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 dc16a8a.

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.