Add WSGIserver support

[fgallaire]

https://fgallaire.github.io/wsgiserver/

[defnull]

Sorry, but we try to do accept new adapters only if there is a significant demand for it. There are just to many WSGI servers and forks out there to support them all. Since no one commented on this pull request for a while, I'll have to close it. Please feel free to re-open the pull request if the new server adapter matches one of the following conditions:

• The adapter replaces a popular but abandoned project with an actively maintained fork and solves problems/bugs still present in the original project. In this case, you should also add a deprecation warning to the old adapter.
• The adapter introduces a new server implementation. In this case, the project should be mature enough for productive use and be supported by an active community. Python 3 support is required, Python 2 support very welcomed.

[fgallaire]

1. CherryPy adapter is problematic: https://github.com/bottlepy/bottle/pull/685 WSGIserver fix the CherryPy API problem and permit a clean adapter.

2. WSGIserver is a (pure Python, mature and performant) one file project, so it's a perfect fit for Bottle (and other Python microframeworks). As opposite of the 30k lines of code of CherryPy which are quite a gigantic dependance.

[defnull]

I'll reopen for a public discussion.

[N0odlez]

Personally i think this should be added. It makes bottle projects easy to deploy to places like Heroku quickly and easily.

[ghonchesefidi]

I'm using WSGIserver and its fine. Thanks.

[hartwork]

wsgiserver has:

• last release 2016-09-29
• last commit to master on 2018-08-19

Close as obsolete or rebase against latest bottle master to see if recent CI still likes it?

[defnull]

For CI to test it, it would require tests in the first place :)

[hartwork]

It's not in the backend blacklist for testing — I thought/remember it would get minimal testing then. I guess I'm missing something?

[defnull]

The test_server.py tests are extremely limited, they do not really test much, so I do not have much confidence even if they pass.

The topic is tricky. On one hand, I do not want to blindly add more and more adapters as I did in the early days without actual need or testing. We already have multiple adapters for stable pure-python WSGI servers. Why add another? They break, give new users a false sense of simplicity (no real production setup should use the unchanged server adapter that comes with bottle) and only save a couple of lines of setup code. Maybe this feature was a bad idea in the first place. On the other hand, it is nice and handy to have them, and who am I to decide which server implementation is 'worthy' without actually testing them myself? There are a couple of upvotes on this issue, so why not?

So, one way to deal with this is to is to raise the bar. New adapters should be stable, well maintained, widely used, should have a unique feature that the others don't have, and the pull request should have some tests and documentation attached. Sounds good?

[hartwork]

So, one way to deal with this is to is to raise the bar. New adapters should be stable, well maintained, widely used, should have a unique feature that the others don't have, and the pull request should have some tests and documentation attached. Sounds good?

Sounds good to me in general. Are there plans to set these upcoming rules in stone somewhere visible?

"stable" might be hard to evaluate and "widely used" may hinder the adoption of rising stars. Maybe it would also be good to specify what kind of tests and documentation you'd want to see added.

[v-python]

If a bunch of the adapters are old, not necessarily well tested, and not necessarily for now-popular servers, maybe it would make sense to bend the "bottle is one file" rule, and drop all adapters from bottle.py and have a collection of files, each containing one adapter? And somehow indicate what level of testing it gets, or perhaps the last version it was tested against?

While my use of bottle is in a testing environment, I'm curious why you say "(no real production setup should use the unchanged server adapter that comes with bottle)"? Does that apply to any particular server adaptor, or all server adaptors presently included in bottle.py? But if that is true for whatever reason, it lends support for the idea of separating them into add-on files.

It also raises a concern for me, wondering what I should do when I move to a production environment. Which might want to be behind a LiteSpeed server which I don't see in the list of server adaptors.

[hartwork]

@v-python I think by "unchanged" @defnull was refering to leaving the backend choice at its default rather than using any of them without changing their code. @defnull can you clarify?

[defnull]

no real production setup should use the unchanged server adapter that comes with bottle

I exaggerated a bit, but it is important to know and understand the settings a server implementation provides. The defaults are sane most of the time, but in reality, it is often more complicated than 'just use cheroot'. Most server adapters only allow you to define IP and port, nothing more. You have to side-step them for any customization, which shows that server-adapters kind of restricted and maybe too abstract. Most are also extremely simple. Just an import, 1-2 lines of setup, and that's it. It does not feel very pythonic to hide this behind an intransparent 'server adapter' concept.

But while we are at it: For a real productive environment, I'd recommend nginx+uwsgi, which does not play well with bottle server adapters anyway. You would not call bottle.run(), but instead, uwsgi loads your app directly.

[waghanza]

what will be the benefits of this backend, facing cheroot (also pure python) ?

note : cheroot is not documented as a deployment option @defnull