Add website.run() method

[techtonik]

To avoid writing this for every app:

#!/usr/bin/env python
"""
The main script to start website for development,
which also exports WSGI application for production.
"""

from aspen.website import Website

# by WSGI convention, we need to create webapp object
# and by default most WSGI servers look for 'application'
application = Website([])

if __name__ == '__main__':
    from wsgiref.simple_server import make_server
    make_server('', 8000, application).serve_forever()

Do that:

#!/usr/bin/env python
"""
The main script to start website for development,
which also exports WSGI application for production.
"""
from aspen.website import Website

# by WSGI convention, we need to create webapp object
# and by default most WSGI servers look for 'application'
application = Website([])

if __name__ == '__main__':
    application.run()

[chadwhitacre]

Sure, but let's call it rundev to make it clear that it's not for production usage.

[techtonik]

Why it is not suitable for production? I don't see why it can not be used for small sites.

[chadwhitacre]

Well, you said it yourself in the docstring:

The main script to start website for development,
which also exports WSGI application for production.

[techtonik]

Yes, but it is because Gratipay uses deployment through a Heroku defined process. I don't know which server do they prefer and why.

[chadwhitacre]

I don't see why it can not be used for small sites.
I don't know which server do they prefer and why.

The limitation with wsgiref.make_server is that it can only handle one request at a time. If you receive a request that takes one second to fulfill (maybe it does a lot with the database, or it's receiving a big upload), then the website won't be able to serve any other requests during that second. For production, this is acceptable for only hobby or otherwise very-low-traffic applications. How about application.run_with_hobby_server() or run_with_toy_server?

[techtonik]

How about application.run_with_hobby_server() or run_with_toy_server?

Not a chance that I will remember those. Note that Flask provides app.run() method, but it uses more capable WSGI framework as dependency - werzeugh or something. Ok, let it be rundev().

[chadwhitacre]

it uses more capable WSGI framework as dependency - werzeugh or something

werkzeug.serving is also single-threaded and single-process.

rundev

I don't like that website.foo confuses the role of the server with the role of the WSGI application. I would rather see foo(website), like this:

from aspen import publish, Website

website = Website()

if __name__ == '__main__':
    publish(website)

(P.S. Flask doesn't use application. I'm not sure we need to, either)

[techtonik]

werkzeug.serving is also single-threaded and single-process.

Then I see no reasons not to have .run() for convenience. If people would like to optimize the site for performance, they will use appropriate server like gunicorn etc. I thinks that's became pretty obvious in Python world, but could be explained once more in docstring.

I don't like that website.foo confuses the role of the server with the role of the WSGI application.

I also don't like that Website inherits from Configuration instead of encapsulating it.

publish(website)

For me publishing means compile and upload, or release draft to public.

(P.S. Flask doesn't use application. I'm not sure we need to, either)

It names it app, but it is WSGI application.
https://github.com/mitsuhiko/flask/blob/master/flask/app.py#L771

[pjz]

I vote no Website.run() because it moves WSGI-server code into the main core. Python -m aspen is convenient enough.

[chadwhitacre]

I thinks that's became pretty obvious in Python world

Yeah, I can see that.

I also don't like that Website inherits from Configuration instead of encapsulating it.

I agree, but that's a separate issue: reticketed as #444 and added to the roadmap (#357).

I vote no Website.run() because it moves WSGI-server code into the main core. Python -m aspen is convenient enough.

Too late. We already have WSGI-server code in the main core.

For me publishing means compile and upload, or release draft to public.

Here it means "put it on the network." I chose publish over mount. How about just serve?

from aspen import serve, Website

website = Website()

if __name__ == '__main__':
    serve(website)

It names it app, but it is WSGI application.

Right. Website instances are also WSGI applications. ;-)

[pjz]

C'mon, we did this already - down this path lies engines and etc. __main__ is the only WSGI server code we have in the app, and it's just as a convenience. It's where it won't bother anyone who doesn't use it (unlike if it's on the main Website object).

[chadwhitacre]

@pjz Check my implementation in #445. It's not on the main Website object.