5. CREATING A PYRAMID PROJECT
5.10 Modifying Package Structure
It is best practice for your application’s code layout to not stray too much from accepted Pyramid scaffold defaults. If you refrain from changing things very much, other Pyramid coders will be able to more quickly understand your application. However, the code layout choices made for you by a scaffold are in no way magical or required. Despite the choices made for you by any scaffold, you can decide to lay your code out any way you see fit.
For example, the configuration method named add_view() requires you to pass a dotted Python name or a direct object reference as the class or function to be used as a view. By default, the starter scaffold would have you add view functions to the views.py module in your package. However, you might be more comfortable creating a views directory, and adding a single file for each view.
If your project package name was myproject and you wanted to arrange all your views in a Python subpackage within the myproject package named views instead of within a single views.py file, you might:
•Create a views directory inside your myproject package directory (the same directory which holds views.py).
•Move the existing views.py file to a file inside the new views directory named, say, blog.py.
•Create a file within the new views directory named __init__.py (it can be empty, this just tells Python that the views directory is a package.
You can then continue to add view callable functions to the blog.py module, but you can also add other .py files which contain view callable functions to the views directory. As long as you use the @view_config directive to register views in conjuction with config.scan() they will be picked up automatically when the application is restarted.
5.11 Using the Interactive Shell
It is possible to use the pshell command to load a Python interpreter prompt with a similar configuration as would be loaded if you were running your Pyramid application via pserve. This can be a useful debugging tool. See The Interactive Shell for more details.
58
5.12. WHAT IS THIS PSERVE THING
5.12 What Is This pserve Thing
The code generated by an Pyramid scaffold assumes that you will be using the pserve command to start your application while you do development. pserve is a command that reads a PasteDeploy .ini file (e.g. development.ini) and configures a server to serve a Pyramid application based on the data in the file.
pserve is by no means the only way to start up and serve a Pyramid application. As we saw in Creating Your First Pyramid Application, pserve needn’t be invoked at all to run a Pyramid application. The use of pserve to run a Pyramid application is purely conventional based on the output of its scaffolding. But we strongly recommend using while developing your application, because many other convenience introspection commands (such as pviews, prequest, proutes and others) are also implemented in terms of configuration availaibility of this .ini file format. It also configures Pyramid logging and provides the --reload switch for convenient restarting of the server when code changes.
5.13 Using an Alternate WSGI Server
Pyramid scaffolds generate projects which use the Waitress WSGI server. Waitress is a server that is suited for development and light production usage. It’s not the fastest nor the most featureful WSGI server. Instead, its main feature is that it works on all platforms that Pyramid needs to run on, making it a good choice as a default server from the perspective of Pyramid’s developers.
Any WSGI server is capable of running a Pyramid application. But we suggest you stick with the default server for development, and that you wait to investigate other server options until you’re ready to deploy your application to production. Unless for some reason you need to develop on a non-local system, investigating alternate server options is usually a distraction until you’re ready to deploy. But we recommend developing using the default configuration on a local system that you have complete control over; it will provide the best development experience.
One popular production alternative to the default Waitress server is mod_wsgi. You can use mod_wsgi to serve your Pyramid application using the Apache web server rather than any “pure-Python” server like Waitress. It is fast and featureful. See Running a Pyramid Application under mod_wsgi for details.
Another good production alternative is Green Unicorn (aka gunicorn). It’s faster than Waitress and slightly easier to configure than mod_wsgi, although it depends, in its default configuration, on having a buffering HTTP proxy in front of it. It does not, as of this writing, work on Windows.
59
5. CREATING A PYRAMID PROJECT
60