grpcio fails to install on Windows ARM64

[dlech]

I'm trying to install bumble on a Windows ARM64 system. It fails because the grpcio dependency can't be installed.

There is no binary wheel (grpc/grpc#39362). And building from source fails and is not supported on Windows (grpc/grpc#29073).

So I'm stuck. Probably nothing a non-google-employee can do, but thought I would document it anyway to save others some time.

[barbibulle]

I just tried a fresh install on a Windows 11 / ARM64 machine, it seems to have been able to install all the dependencies, including grpcio without problems:

This is an up-to-date Windows 11, with Python installed from the Windows Store, and running python in a fresh, empty, virtual environment.

What errors are you seeing on your side?

[dlech]

I can see in your screenshot that you installed the win_amd64 wheel. So you must be running the x86_64 version of Python via emulation. This is a valid workaround of course, but ideally, we could use the native ARM64 version of Python.

[barbibulle]

Good point. I had not initially noticed that the default Python installer from the Microsoft App Store installs the amd64 version of the python runtime.
For the native arm64 version, there are a couple other dependencies that don't have binary wheels available (aiohttp, libusb_package, but those seem to at least build Ok from source, though I have not verified the libusb functionality yet).
For grpcio, one option may be to simply not install it, since it isn't needed for anything other than interfacing with the Android Emulator, which, as far as I can tell, isn't currently available as a native windows arm64 binary.
I do agree that ideally we'd have a clean native arm64 install. I'll keep investigating to see if there's anything I can do to help.

[dlech]

It would be nice to have the transport dependencies as "extras" so that users would only need to install dependencies they are actually using (e.g. pip install bumble[serial] would only install pyserial and not pyusb, etc).

That would be a breaking change though for existing users. I suppose there could be multiple packages though, e.g. bumble-core that supports extras for the pro users that want to trim things down to the bare minimum and leave bumble as the package that installs everything and "just works".

[dlech]

If https://peps.python.org/pep-0771/ is accepted, that could be a good way to handle this.

In the meantime, we could use the pattern noted there of bumble[all] to install all extras. Then we wouldn't have to mess with multiple packages. Still would be a breaking change (requiring people to update their dependency requirements spec), but it seems like bumble isn't really stable yet, so perhaps an acceptable option?

[barbibulle]

PEP 771 is indeed a good option for making the installs more modular. It's still fairly recent, so moving to that model now would be too disruptive to existing users. But I'll start experimenting with different configurations to see what level of modularity would make sense, and be ready to switch at some point in the future when we can assume that "most" users would be using compatible install tools

[cody82]

I am also having issues with grpcio although I do not need it for my use case at all:
There are no wheels for this package for Python 3.14t and building takes more than 10 minutes and results in a 500 MB wheel.

Are there any reasons not to make it optional apart from breaking bumble for some users?

[zxzxwu]

I think we are very close with #897. However, having too many optional dep group is still a problem. Or we can just move grpc out to optional dep first?