Remove universal2 wheel and add arm64

[niclaurenti]

universal2 wheels seems to be broken for arm64 MacOS.
Trying to use arm64

[niclaurenti]

@alecandido the problem of the fiatlux wheels is probably related to the fact the macos-latest is still version 12, while most people are using version 13 or 14. I was having the same issue with adani and when I changed macos-latest -> macos-14 it fixed the wheel

[alecandido]

@alecandido the problem of the fiatlux wheels is probably related to the fact the macos-latest is still version 12, while most people are using version 13 or 14. I was having the same issue with adani and when I changed macos-latest -> macos-14 it fixed the wheel

Ah, but then you should specify the version you want, I'm adding it.

[niclaurenti]

btw, I think that the fortran action is useless in the build_wheel part since it is building the wheel in a container that cannot that will not have access to that fortran installation

[alecandido]

btw, I think that the fortran action is useless in the build_wheel part since it is building the wheel in a container that cannot that will not have access to that fortran installation

It depends: the wheel is built in a manylinux container if the host is Linux, but otherwise directly on the host.

https://github.com/pypa/cibuildwheel?tab=readme-ov-file#how-it-works

[alecandido]

However, it is true that in principle you don't have to build twice: you could just build the wheels, then download the artifact and test that, instead of installing from source with pip.

[niclaurenti]

However, it is true that in principle you don't have to build twice: you could just build the wheels, then download the artifact and test that, instead of installing from source with pip.

This is what I'm doing :)

[alecandido]

This is what I'm doing :)

Not the workflow. I'll show you what I mean.

[niclaurenti]

I downloaded and installed the wheel but import fiatlux is failing with

ImportError: dlopen(/Users/niccololaurenti/projects/test_adani/venv/lib/python3.11/site-packages/fiatlux/_core.cpython-311-darwin.so, 0x0002): symbol not found in flat namespace '_f2sf_'

as before

[alecandido]

I downloaded and installed the wheel but import fiatlux is failing with

ImportError: dlopen(/Users/niccololaurenti/projects/test_adani/venv/lib/python3.11/site-packages/fiatlux/_core.cpython-311-darwin.so, 0x0002): symbol not found in flat namespace '_f2sf_'

as before

Which is your gfortran version?

[niclaurenti]

I downloaded and installed the wheel but import fiatlux is failing with

ImportError: dlopen(/Users/niccololaurenti/projects/test_adani/venv/lib/python3.11/site-packages/fiatlux/_core.cpython-311-darwin.so, 0x0002): symbol not found in flat namespace '_f2sf_'

as before

Which is your gfortran version?

> gfortran --version
GNU Fortran (Homebrew GCC 13.2.0) 13.2.0

[alecandido]

@alecandido the problem of the fiatlux wheels is probably related to the fact the macos-latest is still version 12, while most people are using version 13 or 14. I was having the same issue with adani and when I changed macos-latest -> macos-14 it fixed the wheel

I actually wonder how did you test with the CI wheels, since they failed both times.

> gfortran --version
GNU Fortran (Homebrew GCC 13.2.0) 13.2.0

Then, it seems not to be related to the gfortran version, because now the CI is also using gfortran==13.x.y, that should be compatible with yours.

Try again changing the macos version, but then I don't know why this should help...
(but do it, it's not because I don't know that it won't help)

[alecandido]

Now we're left with floats...

E       assert 0.019275559436024287 == 0.01927555943602428

...

[niclaurenti]

Now we're left with floats...

E       assert 0.019275559436024287 == 0.01927555943602428

...

Well, I think we can modify the test to make it pass...

[alecandido]

Well, I think we can modify the test to make it pass...

The problem was that it was different on Linux and Mac (by 1 in the last digit, of course). They are using some different implementation of float algebra, or they have a somewhat different precision...
(though it's pretty strange)

However, I guess the sense of the comparison was approximate equality, so now it should pass.

Actually, the default relative tolerance is even too high, I can lower it a lot.

[alecandido]

✅ welcome back!

[alecandido]

I completed some other minor updates, and tested the wheels.

Whenever tests are passing, it could be merged.

[alecandido]

Apparently the upload action refuses to implicitly overwrite files, and I believe this was happening before.

I allowed it to overwrite again, but if anyone wants to understand which files are duplicated (most likely the dist info), and avoid it, feel free (it would be for sure a more elegant solution).

[alecandido]

Ok, I was forced to read the docs myself...

https://github.com/actions/upload-artifact?tab=readme-ov-file#not-uploading-to-the-same-artifact
https://github.com/actions/download-artifact?tab=readme-ov-file#download-all-artifacts