Mac ARM64 build broken: pyproject.toml lz4 compile uses system python

[Tom Goddard]

The Mac ARM64 build is broken for me (goddard) on euclid.cgl.ucsf.edu

  Building wheel for lz4 (pyproject.toml): finished with status 'error'
  Building wheel for psutil (pyproject.toml): finished with status 'error'

The pip.log file indicates the problem is that it can't find Python.h because it is looking in a system installed location instead of the ChimeraX python install.

2022-09-20T22:34:00,589   gcc -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynami\
c -DNDEBUG -g -fwrapv -O3 -Wall -arch arm64 -arch x86_64 -g -Ilz4libs -I/Library/Frameworks/Python.fra\
mework/Versions/3.9/include/python3.9 -c lz4/_version.c -o build/temp.macosx-10.9-universal2-cpython-3\
9/lz4/_version.o -O3 -Wall -Wundef                                                                     
2022-09-20T22:34:00,610   lz4/_version.c:32:10: fatal error: 'Python.h' file not found                 
2022-09-20T22:34:00,610   #include <Python.h>                                                          
2022-09-20T22:34:00,610            ^~~~~~~~~~                                                          
2022-09-20T22:34:00,615   1 error generated.    

This is on the ChimeraX Mac ARM build machine euclid.cgl.ucsf.edu. The build currently works on the chimera account because the pip log indicates it finds the cached lz4 wheel apparently compiled from before pyproject.toml was used. But on my account (goddard) I don't have that cached wheel.

The install needs to be fixed so it does not attempt to use the system Python.

I'll attach the full make output and pip.log.

[Tom Goddard]

ChimeraX makefile output

[Tom Goddard]

pip log output

[Zach Pearson]

This is a bug in the latest version of setuptools. In general PyPA projects like pip and setuptools try to build packages in an isolated environment. Setuptools recently vendored a new version of distutils that ​broke the machinery that finds header files (distutils issue lined) and ​here's the setuptools PR that broke it.

For psutil, we can get around it by adding --no-build-isolation to our pip install flags in prereqs/pips. Unfortunately for lz4, doing this results in a bug in pip blocking the build: lz4 uses some wonky way of determining the version number using setuptools_scm, so pip can't determine its version:

  WARNING: Requested lz4==4.0.2 from https://files.pythonhosted.org/packages/65/8d/4d913798e17735839c7666e81985bd230f739927d066890b511a78c542d8/lz4-4.0.2.tar.gz (from -r app_requirements.txt (line 27)), but installing version 0.0.0
Discarding https://files.pythonhosted.org/packages/65/8d/4d913798e17735839c7666e81985bd230f739927d066890b511a78c542d8/lz4-4.0.2.tar.gz (from https://pypi.org/simple/lz4/) (requires-python:>=3.7): Requested lz4==4.0.2 from https://files.pythonhosted.org/packages/65/8d/4d913798e17735839c7666e81985bd230f739927d066890b511a78c542d8/lz4-4.0.2.tar.gz (from -r app_requirements.txt (line 27)) has inconsistent version: filename has '4.0.2', but metadata has '0.0.0'
ERROR: Could not find a version that satisfies the requirement lz4==4.0.2 (from versions: 0.1, 0.2, 0.2.1, 0.3.0, 0.3.1, 0.3.2, 0.4.0, 0.5.0, 0.6.0, 0.6.1, 0.7.0, 0.8.1, 0.8.2, 0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.9.4, 0.10.0, 0.10.1, 0.11.1, 0.12.0, 0.13.0, 0.14.0, 0.15.0, 0.16.1, 0.16.2, 0.16.3, 0.16.4, 0.16.5, 0.16.6, 0.17.0, 0.18.0, 0.18.1, 0.18.2, 0.19.1, 0.19.2, 0.20.1, 0.21.1, 0.21.2, 0.21.3, 0.21.5, 0.21.6, 0.22.1, 0.23.1, 0.23.2, 1.0.0, 1.0.1, 1.1.0, 2.0.0, 2.0.1, 2.0.2, 2.1.0, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.1.5, 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.2.1, 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.9, 3.1.10, 4.0.0, 4.0.1, 4.0.2)
ERROR: No matching distribution found for lz4==4.0.2

[Zach Pearson]

Perhaps pip's behavior is not a bug. Building without isolation means, I think, that pip expects requirements to already be satisfied; installing setuptools_scm let me build lz4.

[Zach Pearson]

I added setuptools_scm to build_requirements.txt and added the --no-build-isolation flag to invocations of pip in prereqs/pips/Makefile. Builds from your user should succeed now.

[Tom Goddard]

Thanks. My mac arm build on euclid is now working. I needed this to work on the mac universal build script.

The nightly Mac arm techpreview failed compiling another PyPi package last night, probably for the same reason as reported in this ticket. I have rerun that nightly techpreview build and it worked.

The fix for this problem seems like a work-around and perhaps this ticket should be left open so that it can be taken out when the distutils bug (​https://github.com/pypa/distutils/issues/178) is resolved.

[Zach Pearson]

I agree -- it should be left open for now.

[Zach Pearson]

This ticket should be resolved by cleaning the CONFINCLUDEPY, INCLUDEPY, INCLUDEDIR, and CONFINCLUDEDIR variables of sysconfigdata, which also allowed us to upgrade setuptools.