run Pylons

Creating a Pylons Project

Now that you’ve seen a quick overview of all the Pylons components, it’s time to create your first Pylons project.

Let’s get started by using Paste’s paster create command to automatically generate a Pylons project directory structure for you. You are completely free to create all the files and directories yourself if you prefer, but the Pylons project template provides a useful starting point that most people prefer to use.
Caution: In Pylons terminology, there are two different types of template, and it is important not to get confused between the two. View templates are text files that contain a mixture of Python and HTML and are used to generate HTML fragments to return to the browser as the view component of the MVC architecture. Any template written with Mako is a view template. Project templates are sets of files and directories that are used by the paster create command to generate a complete project directory structure to use as a basis for a new Pylons application.

Create a new project named HelloWorld based on the Pylons default project template with this command:

$ paster create --template=pylons HelloWorld

Serving a Pylons Application

Now that you have a sample project application, it is a good idea to run it with a web server to see what the default project provides; however, before you can serve the Pylons application you’ve just created, you need to learn about configuration files.
Configuration Files

Configuration files enable you to set up the same Pylons application on different servers with different settings and for different purposes without having to change the source code for the project.

The project template you have used creates two configuration files for you in the HelloWorld directory, one named development.ini and one named test.ini. The development.ini file contains settings to run the Pylons application in a development environment such as your local workstation, whereas the test.ini file contains the settings you want to use when testing the application. You create a new configuration file called production.ini when you are ready to serve the application file in production.

Change in development.ini host and port 

From :  

host = 127.0.0.1

port = 5000

To :

host = 213.155.190.141

port = 5222


Let’s discuss the options available:

debug
This can be true or false. If true, the Pylons interactive debugger is enabled to allow you to track down problems, as you’ll learn about in the next chapter. You should always disable the interactive debugger in production environments by setting debug to false.

email_to, smtp_server, error_email_from
These options specify where error reports should be sent if the interactive debugger is disabled, but they could potentially be used by third-party components too since they are specified in the [DEFAULT] section and are therefore available to all components using the configuration file.

host, port
These specify the IP address and port the server should listen on for requests. Only the server uses them.

full_stack
You can set this to false to disable Pylons interactive debugging, error report support, and error documents support, but you’ll usually leave this set to true.

cache_dir
This is the directory where components can store information on the filesystem. Session information from Beaker and cached view templates from Mako are stored in this directory. You can manually override where Beaker stores its session information with the beaker.cache.data_dir and beaker.session.data_dir options, but you won’t usually need to do so.

beaker.session.key
This should be something unique to your application so that other applications using Beaker can’t access your application’s data.

beaker.session.secret
This is a random string of letters and numbers used to make the cookie value representing the session harder to guess to reduce the risk of a malicious user trying to gain access to someone else’s session information. You should always change this to something other than somesecret if you are using Pylons session functionality.

The Paste HTTP Server

To run your application for development purposes, it is recommended you use the Paste HTTP server from the Paste package that was installed as one of Pylons’ dependencies. The Paste HTTP server does for Pylons applications what Apache does for PHP and other languages; it listens for HTTP requests and dispatches them to the running application, returning the result via HTTP to the user’s browser.

The Paste HTTP server has two features that make it more suitable for Pylons development than most web servers:
It can be made to automatically reload when you change the source code.
It understands the configuration files used by Pylons, so they can be used directly. As you’ll see in Chapter 19, other servers require the assistance of the Paste Deploy package to turn a Pylons config file into an application.

You can start the server with your development configuration with this command:

$ cd HelloWorld
$ paster serve --reload development.ini
Starting subprocess with file monitor
Starting server in PID 17586.
serving on 213.155.190.141:5222 view at http://213.155.190.141:5222