search

jd-boyd / python-lzo

Python bindings for the LZO data compression library
GNU General Public License v2.0
74 stars 41 forks source link

PyPI Wheels for ARM64 Macs? #81

Open nightlark opened 8 months ago

nightlark commented 8 months ago

Recently we were trying to install ubidump on the "new" ARM-based Macs; however, it failed to install due to python-lzo not providing a pre-built binary wheel for macOS, and the source tarball was giving a build error.

I noticed that you have a CI job that was added ~8 months ago that uses cibuildwheel to build a bunch of wheels, including for arm64 macosx -- is there an estimate for when a new release will be made that includes those wheels? Are there any things that need to be done first, that you could use some help with?

jd-boyd commented 8 months ago

I will enable the automated tests running on Mac OS arm, and then we will see from there.

jd-boyd commented 8 months ago

I have tagged v1.16, and am seeing how the workflows related to that go. While the workflows were put in place for 1.15, I don't think I used the workflows for making the release, so it is still new to me.

jd-boyd commented 8 months ago

And it looks like that workflow has issues: https://github.com/jd-boyd/python-lzo/actions/runs/7509707331

AT0myks commented 8 months ago

@nightlark while waiting for the next release you can install wheels from TestPyPI.

@jd-boyd The workflow issues are related to e3fe6ff8aabba12c7ebef1f2350a436cfd0f856b. It's trying to link to the lzo2 system lib but it's not installed. As you can see here there was no issue with the workflows before, even with older Python versions. I think the previous approach where the library is bundled in the wheel is better than linking to it. This way there's no problem when a distribution's lzo package has an incompatible version. Maybe we could add another environment variable like USE_SYSTEM_LZO to give the option of linking to the system's library.

And, as I said in #75 there are a few changes to make (here and on PyPI) before the wheels can be uploaded successfully, because right now it will still try to upload to TestPyPI (it's the reason this run failed). By the way, since this PR was merged there is no need for the other 3 workflows anymore.

Also, b85c6e59bde00262f38b3a6dbbccaef577368f68 won't work because arm64 wheels can be built on x86_64 but not tested, and I don't think GitHub Actions has free arm64 macOS runners.

kgantchev commented 8 months ago

Hi @AT0myks, I'm Kiril Gantchev, the CEO and co-founder of FlyCI. You can also try the FlyCI's M1 and M2 runners for your GitHub workflows.

Our runners are on average of about 2x faster and 2x cheaper than GitHub's. We also have a free tier of 500 mins/month of M1 usage.

Easily replace your M1 runners: 

jobs:
 ci:
-    runs-on: macos-latest
+    runs-on: flyci-macos-large-latest-m1
   steps:
   - name: 👀 Checkout repo
     uses: actions/checkout@v4

Exclusive M2 runners: 

jobs:
  ci:
-    runs-on: macos-latest
+    runs-on: flyci-macos-large-latest-m2
    steps:
      - name: 👀 Checkout repo
        uses: actions/checkout@v4

We'll be happy to have you on board. Our team is always there to help should you have any issues.

AT0myks commented 8 months ago

I'll wait for GitHub to provide their free runners. Cross-compilation is enough for now.