Idea: enforcing 32-bit vs 64-bit support in setuptools

Packaging
1

Disclaimer: coming from [FR] requiring 32-bit or 64-bit Python in setuptools.setup · Issue #3746 · pypa/setuptools · GitHub

setuptools.setup has the python_requires kwarg to require a certain version range of Python.

I think it would be good to add processor_type or something similar to enforce Python being 32-bit, 64-bit, etc.

I work in the manufacturing space, where we have to support old stuff that requires 32-bit. It seems packages are dropping support for 32-bit, and it’s breaking my installs (examples here and here).

It would be cool if setuptools supported some metadata that filters packages collected to 32-bit or 64-bit support. This idea was independently brought up by someone else here.

I was thinking from a technical perspective - the package somehow indicating in its data that it’s not supporting 32 bits (in its metadata).
That way it wouldn’t be picked up by pip in first place.

Thank you for your consideration!

2

Both of the examples you cite are examples of packages dropping building of 32-bit wheels, causing the installer to fall back to a source build, which fails. Neither of these are examples of cases where the package actually dropped 32-bit support, so it’s not clear that this feature request would actually accomplish what you want?

3 Likes
3

Indeed, why don’t you just use pip install --prefer-binary?

FWIW, there is discussion about making --only-binary :all: the default (which is even stronger than --prefer-binary) on Speculative: --only-binary by default? · Issue #9140 · pypa/pip · GitHub

3 Likes
4

Thanks all for the responses!

examples of packages dropping building of 32-bit wheels, causing the installer to fall back to a source build, which fails

I follow what you’re saying here, and when it falls back onto source build, it fails as zlib is not available on Windows.

I think this proposal is not about denying pip from looking at wheels via --only-binary :all: (that’s more of a workaround), what I am posing is somehow enabling pip to automatically detect that Pillow>=10 and contourpy>=1.1 don’t have 32-bit Windows wheels and also can’t be source built on 32-bit Windows.

So it would be adding metadata such that pip can automatically discern:

  1. Pillow version 9: has 32-bit wheels, would work
  2. Pillow version 10: doesn’t have 32-bit wheels, source build is not supported on Windows, so don’t use this version
  3. Okay, resolver will use Pillow version 9

Does that make sense?

Update: @jeanas I agree with your comment here on better error messages. I think what I am posing here is adding some mechanism so pip’s resolver can filter versions where installs won’t succeed (no wheels + source build would fail).

As I type this out, I am realizing this request may be infeasible.

5

I understand what you are saying, but the problem is that source build is supported! You just don’t have the required dependencies installed.

6 Likes
6

Yup. Plus, it’s quite infeasible to detect whether the build could fail beforehand, since there are zillions of reasons that could happen.

1 Like
7

This is probably only distantly related, but there are times that I feel as a package maintainer that I am unaware to signal to a user directly that my package is not supported on their platform, but the ability/responsibility is at my dependencies needing to provide correct markers when they add my project as a requirement. I wish I can do something similar that marks my project as only installable in certain environments.

3 Likes
8

I wish I can do something similar that marks my project as only installable in certain environments.

I totally agree with what you’re saying @uranusjr.

This request is a possible solution, enabling end-users (people installing Pillow) to go from this:

matplotlib
# Manually pinning indirect dependency for win32 machines
Pillow<10 ; sys_platform=='win32'

Through new metadata, pip handles it all, so end-users can just have:

matplotlib

And behind the scenes, pip discerned for Pillow:

  • win32: ver 10 has no wheels + source build will fail, falls back on ver 9 which has wheels
  • Other OS: ver 10 will work

Anyways, we can let this idea die out, and thank you all for participating! :smile: