Replace gunicorn with waitress

[iamjameswalters]

Hi there! 👋️

Just heard @ipmb give a lightning talk on this nifty tool at DjangoCon US. Something that immediately stuck out to me is that it uses gunicorn by default. That presents a problem for Windows users. Fortunately, django-webserver also supports waitress from the Pylons folks, which works on Windows. This PR replaces gunicorn with waitress to give Windows developers a better experience.

Thoughts?

[ehmatthes]

I think you can put OS-specific settings in a pyproject.toml file. So I think you could have something like:

dependencies = [
    "django-environ",
    "whitenoise",
    "django-webserver[gunicorn]",
    "django-webserver[gunicorn]; platform_system != 'Windows'",
    "django-webserver[waitress]; platform_system == 'Windows'",
    "django-alive",
]

[ipmb]

I prefer @ehmatthes recommendation. gunicorn is generally the preferred WSGI server for non-Windows folks.

[iamjameswalters]

Oh, that's excellent @ehmatthes ! I've updated this accordingly.

[ehmatthes]

I don't know enough to be confident about this change. I presume this means if someone is developing on Windows but deploying to a non-Windows host, they'll be using waitress locally and gunicorn on the remote server.

Peter, how does that fit with the overall goals of the project? Should the default be this behavior, or is it better to use the same server locally and on remote? I have no experience with waitress.

[ipmb]

Good point @ehmatthes I hadn't thought about handling different deployment platforms.

@iamjameswalters I assume you're doing local development on Windows. Are you also deploying to Windows machines? If so, could you tell me a little about how you handle a WSGI server there? I've only ever deployed to Linux, so I'd like to understand how people are handling it.

[iamjameswalters]

In my case, I use Linux on my personal machines, but I'm locked into Windows at work, and don't have access to WSL. I deploy to Ubuntu VMs. I'm just using manage.py runserver in local development, and gunicorn when I deploy. We have a development/staging server which is a duplicate of the production environment where I can run tests.

I don't imagine many are deploying to Windows (my IT department did try and have me look at deploying on an IIS server, which I couldn't make heads or tails of, that doesn't seem to be a very Python-friendly environment). But I imagine there still are a number who are developing on Windows, either because they have to use Windows at work like me, or because they are Windows users in their own right.

Is the ultimate goal of this tool to prepare the code itself for deployment? Or to create a deployment environment? If the former, then it seems like there's enough leeway to consider providing for Windows users who are configuring their code for deployment (probably) to a different platform than they're developing on.

In the case of the latter, I guess the question is how consistent should this tool expect a user's development and production environments to be? If the answer is that they should be consistent enough to both be nix, then I suppose the solution is to continue to provide gunicorn. In that case, it might be nice to at least give Windows users a heads up on the README that they're going to need WSL, a VM, or some kind of nix based environment. I could easily see someone with little experience deploying WSGI apps reaching for this as a solution and failing to understand why it didn't work on their machine.

[ehmatthes]

I think most people developing on Windows are deploying to a linux server. I wouldn't worry about supporting anyone deploying to a Windows server until you get a specific request to support that use case.

Do either of you know if gunicorn installs to Windows these days? If it does, I don't think there's any change necessary. People can continue to work locally with the development server, and gunicorn will be used in production. I don't see any need to bring waitress into this project if that's the case. The only issue arises if gunicorn doesn't install on Windows, and people are trying to build a dev environment from this requirements file.

Even if gunicorn doesn't install on Windows, I believe the fix is to add a conditional so gunicorn is only required for non-Windows platforms:

dependencies = [
    "django-environ",
    "whitenoise",
    "django-webserver[gunicorn]; platform_system != 'Windows'",
    "django-alive",
]

This ensures that gunicorn is used on the server, and developers on Windows can continue to use runserver locally.

[ipmb]

I agree @ehmatthes

@iamjameswalters could you see if this works on your Windows machine? pip install gunicorn

If it does, I don't think we need to make any changes. If it doesn't we can block it from installing on Windows (but keep it in the requirements) with Eric's suggestion above.

[iamjameswalters]

Just checked and yes, gunicorn does successfully install on Windows 10.

[ehmatthes]

I was able to install and import gunicorn on Windows as well. I didn't run it, but I wanted to make sure there weren't any issues with a simple import.

[ipmb]

Great, thanks for checking. I think we are good here.

To summarize, gunicorn will not run on Windows, but this project will install fine on Windows machines. For now, we will assume folks are deploying to Linux-like OSes.

If we get good intel about how folks are running Django on Windows in production, we can update accordingly.