Distribute wheels to pypi

[mattrobenolt]

Granted, we were always able to generate wheels for OSX and Windows, it's now possible to generate wheels for Linux as well.

This provides the benefits of a faster install and doesn't depend on compilers existing on the target machine to install/run uwsgi.

gevent was the first package to publish "manylinux" wheels: https://pypi.python.org/pypi/gevent and there's a project to facilitate generation: https://github.com/pypa/manylinux

I'm not personally super familiar with this, or what it'd take for uwsgi to support, but I'm willing to help. :)

• Build tool to generate releases
• OSX (Compile properly platform tagged wheel #1219)
• manylinux
• Windows

[xrmx]

Be our guest then! I don't think anyone will oppose to a pull request :) I see some issues though:

• centos 5 is not a good baseline for us since IIRC we use some kernel features not available there and we want to build with that features
• we need to find a configuration that covers most use cases
• we then need to sort out which configurations willl need a --no-binary switch when installing, unless we can still keep the source installation default of course.

[mattrobenolt]

@xrmx GH-1219 is a start. It doesn't do anything fancy, but it fixes generation of platform specific whl files as a first step. So with this, in theory, it'd be possible now to fire up a bunch of virtualenvs to compile against different versions of python and generate all the wheels.

[ushuz]

https://github.com/joerick/cibuildwheel can make building manylinux1 wheel on Travis CI really easy.

---

centos 5 is not a good baseline for us since IIRC we use some kernel features not available there and we want to build with that features

Docker uses the kernel on host machine, instead of the kernel that's available for CentOS 5 distro. So it may not be a problem, but I'm not entirely sure about this, just a thought.

[ipmb]

We've been working on getting wheels published to PyPI (including manylinux) under the pyuwsgi package. https://pypi.org/project/pyuwsgi/

There are currently some pre-releases up there if you'd like to test it out.

pip install --pre pyuwsgi
pyuwsgi --help

If you notice any problems with the packaging, please file an issue at https://github.com/lincolnloop/pyuwsgi-wheels. 👍

[mattrobenolt]

@ipmb You're doing the Lord's work. 🙏

[ipmb]

I think this one is safe to close now. pyuwsgi 2.0.18 has wheels on PyPI.

[mattrobenolt]

But uwsgi itself is not. This was at least my original intent.

[ipmb]

@unbit doesn't want to change the way uwsgi is distributed. pyuwsgi is the exact same code as uwsgi but moves https://github.com/unbit/uwsgi/blob/d1338dfefe3d9a2de466a9a695cb61fdd055a295/setup.pyuwsgi.py to setup.py prior to building to allow for proper Python wheels. You'll get a script called pyuwsgi that you can run just like uwsgi.

I think this is as close as we're going to get :)

[mattrobenolt]

@ipmb just wanted to say I've converted one of my pet projects to use pyuwsgi and it works well. :) strutbox/web@a138526

Thanks for tackling this.

[bsolomon1124]

I'm not sure if I understand the reasoning behind moving this functionality to an entirely different package.

Support for wheels is becoming very widespread thanks to manylinux and the easy of building across a matrix of Python implementations and platforms within CI/CD.

At the risk of starting an argument, it does seem like there are several borderline-misconceptions in this thread.

Namely:

centos 5 is not a good baseline for us since IIRC we use some kernel features not available there and we want to build with that features

What would those be? It's not hinted at in #1376 either. The nature of manylinux1 is that it uses a consistent set of whitelisted libraries. If you have some outside of those, you can use auditwheel or delocate on MacOS to bundle shared libraries with the wheel. I recognize that shared library != kernel features, but am curious as to what those features are.

we then need to sort out which configurations willl need a --no-binary switch when installing, unless we can still keep the source installation default of course.

The very nature of a wheel is that it targets a specific platform because it works there. pip will not arbitrarily install a wheel that doesn't work on a target platform and is very good about only picking "the right" wheel.

[bluetech]

@ipmb First, thanks for providing pyuwsgi!

I was wondering if you might be able to put up Python 3.9 wheels as well? If there's any way I can help with that, I'd be happy to.

[ipmb]

@bluetech tracking Python 3.9 wheels here, lincolnloop/pyuwsgi-wheels#8

[tgross35]

Reiterating what @bsolomon1124 said, it seems like it would make sense to combine uwsgi and pyuwsgi. @unbit is that a possibility you would consider at this point? Wheels are available for at least 90% of python projects now, I don't see any benefit to maintaining two separate PyPy projects. Anybody who for whatever reason needs to build from source can always do so with pip install uwsgi --no-binary :all:, and this will be the case anyway for any platform unsupported by the wheels.

[ChillarAnand]

It has been a while since this request is addressed. Any plans on shipping wheels?

[ipmb]

I would gladly hand over the reigns to https://github.com/lincolnloop/pyuwsgi-wheels with https://cibuildwheel.readthedocs.io/ the process is pretty straightforward.