Easiest way to determine pure python sdists?

Packaging
,
1

I’m working on a project that needs to, given an sdist, build a wheel for all supported platforms.

Naturally, I reached for cibuildwheel, however it intentionally flops on pure python packages.

So now I just natively try and build the wheel and if it isn’t pure I’ll use cibuildwheel. But this is inelegant, since both success and failure of building the wheel are valuable signals implying “not pure”.

I poked around the Python packaging guide and the build docs and the pyproject-hooks docs but nothing is screaming at me.

Anyone got ideas?

2

I don’t think there’s a clean way to solve this.

I think the best you could do is use the prepare_metadata_for_build_wheel hook, when available, to figure out if the wheel is pure. This avoids going through the whole build process, but since it’s an optional hook, it won’t be available on all backends. When it’s not available, you have to resort to the same thing you are doing right now.

3

I’m afraid I don’t have a good suggestion, only a word of warning: there are some packages that are “pure Python” conditionally — e.g. they build binary wheels for CPython, but pure Python wheels for PyPy. Sometimes it also happens per Python version, operating system and possibly other conditions. No clue how cibuildwheel handles that.

4

There are some other (long) threads in this category[1] that are trying to suss out a way to specify pure-Python sdists.

  1. and I’m probably missing other threads atm ↩︎

5

I don’t see how it’s inelegant:

  1. Attempt build with cibuildwheel just for the current platform.
  2. If it fails, package is clearly broken, so abort.
  3. If it succeeds and the wheel tag ends with none-any, it’s pure, so we’re finished.
  4. If not, run cibuildwheel for other platforms of interest.

The edge-case packages that generate a pure-Python package for the current platform but also have platform-specific ones for other platforms are never going to be obvious in any automated way. So you probably also want to have an easily updatable list of platform overrides to always build for certain packages (presumably you’ll get the pure package for a range of platforms, which means you don’t want to rebuild all of them).

Sometimes, the most practical and elegant solution is to do the simplest thing that works and have a manual escape hatch.

1 Like
6

I’d actually prefer this (I’ve thought about inverting my paradigm), but cibuildwheel errors when it built a pure wheel. So I’m still in the camp of “delineating failure” which doesn’t feel good.

And yeah, I didn’t say it earlier but I’m not concerned about edge cases. I’ll just note those up front and let people decide if the trade-offs I’ve made are worth it to them or not.

1 Like
7

Oh, that sounds like something they ought to allow. Maybe request an option(/env variable) to allow this?

1 Like
8

Could you describe the error? I actually tried it on one of my pure Python libraries, but I couldn’t get past it trying to download and install old Pythons that I know where already installed and on my $PATH, even with various CIBW_* env settings.

9

I’ll let code describe it :grin:

2 Likes
10

From looking at closed issues, it looks like this has already been discussed a few times and cibuildwheel doesn’t plan to support this.

That being said, I think I will just do the cibuildwheel thing and ignore errors.