Paul Moore wrote:
> I'm not really familiar with manylinux1, but I'd be concerned if we
> started getting bug reports on pip because we installed a library that
> claimed to be manylinux1 and was failing because it wasn't. (And yes,
> packaging errors like this are a common source of pip bug reports).
>
> It seems to me that it's defeating the purpose of having standards if
> people aren't willing to follow them...
I agree with that. OTOH it seems providing binary wheels is generally a strong
demand from the community. I would be fine with only providing conda packages myself.
The biggest demand seems to be for developer convenience of quick downloads / installs and by people whom have not delved very deep into the gnarly black arts of cross compilation and forwards / backwards compatibility maintenance.
Deployment bandwidth costs and install times are a second tier use, but still a real concern to any parties whom should consider sponsoring any effort going towards solving anything within the scope, as solving their gripes would save them money.
By the way other packages are already doing worse:
https://github.com/tensorflow/tensorflow/issues/8802
Domain specific packages with real industry needs will need to deviate from any standard put forth as the world of the bleeding edge moves faster than the standards can.
What a lot of packages would actually need, is to have per operating system per distro per distro version wheels, but that'd get quite insane quick and put a lot of effort onto the package maintainers or the maintainers of the manylinux-esque build containers.
I'm doubtful that there are many packages that "need" this. People don't do this on Windows or macOS, and those platforms seem to do ok.
Still we should have some way to describe such packages, so tensorflow can at least have be accurate metadata, and for a variety of other use cases (Alpine, arm, conda, etc.).
And even something like that will still spectacularly fall apart on macOS by stuff like building against 3rd party libraries from macports vs. fink vs. homebrew installed into /usr/local/ vs. homebrew installed into $HOME/.homebrew varying between the unsuspecting package maintainer / wheel builder and the end users of the wheel.
This isn't really an issue. Whatever libraries you need should be vendored into the wheel with a tool like 'delocate', and then it doesn't matter what third-party package manager your end users do or don't use.
Oddly enough this seems to be by far the least problematic on Windows.
There's no real difference between Windows/macOS/Linux in terms of binary compatibility. On Windows people are more used to shipping everything with their package, that's all. If you do the same thing on macOS and Linux, it works great.
-n