mpi4py wheels

A full wheelhouse with something like cibuildwheel could help reduce installation issues for standard users. People who need to build against specific MPI libraries can still get the source dists with the --no-binary flag. It would also help during doc (#26) and other CI pipelines.

[dalcinl]

@Helveg If you are targeting novices, would’t it make sense to teach them to start with the Miniforge installer and get everything from conda-forge?

If mpi4py gives grief to novice users, it is most likely because novice users typically make a total mess of their development environments. Look at mpi4py’s CI infrastructure covering mainstream Linux/macOS/Windows, you usually execute a one-liner to install the system MPI, and pip install mpi4py works out of the box.

Anyway, I’m not opposed at all to your suggestion, provided it is implemented the right way. Your mpi4py-mpich and mpi4py-openmpi packages would need to be just a wheel handling the binary installation of the respective full MPI implementation. Most likely, you will have to make these packages relocatable, such that users can install them in any site-packages directory (at least the user one in ~/.local). Handling binary relocation yourself requires a lot of nasty and platform-dependent stuff, ask conda folks . And then you will the cruel reality: wheels do not have any sort of support for post-install script, so forget about using binary editing tools like chrpath on Linux or install_name_tool on macOS. I anticipate that you will fail and waste your time. Although you will learn a lot in the proceses. Of course, I could be wrong. But remember this ain’t my first rodeo.

[dalcinl]

It is not just about the MPI library. Actually running MPI applications usually require some additional MPI runtime (e.g. mpiexec command). Bundling the MPI libraries on mpi4py wheels is IMHO a bad idea.