Note: In the 1.7.6 release of App Engine, a significant update to the Python Development Server was introduced. This page explains the differences between the old and new versions of the development server for those familiar with the original. You can find more information on the new Development Server in our documentation.
- The New Python Development Server
- Running the Old Development Web Server
The New Python Development Server
The Development Server was upgraded in the 1.7.6 release of App Engine in March of 2013. The following is a list of major changes that accompanies this release:
- Python 2.5 applications are no longer supported in
dev_appserver. To run Python 2.5 applications, use the old version, which will be included as part of the SDK until July 2013.
- Support for shortened flags (e.g.
--port) has been removed.
- The default URL of the local Development Console is no longer in the
_ah/adminsubdirectory, but port
- You can now browse the contents of your local Blobstore by navigating to the Blobstore Viewer in your local Development Console.
- The default solution for storing data in new projects is the High-Replication Datastore, instead of the deprecated Master/Slave Datastore.
- SQLite is now used as the backend for your local Datastore stub. Running an app in the new Development Server for the first time will automatically migrate any existing Datastore files into the SQLite format, in much the same way as if this were being done manually in the old Development Server.
- The following flags have been added, removed, or renamed:
--addresshas been renamed to
--admin_hosthas been added
--admin_porthas been added
--debugis now enabled by specifying
--allow_skipped_fileshas been removed
--auth_domainhas been removed
--backendshas been removed, as it is now always enabled
--clear_datastoremust now be set to
--datastore_consistency_policy=consistenthas been added, specifying that the application will use the deprecated Master/Slave Datastore
--debug_importshas been removed
--default_partitionhas been removed
--disable_static_cachinghas been removed, as caching has been disabled
--disable_task_runninghas been removed
--enable_task_runninghas been added
--high_replicationhas been removed, as the High-Replication Datastore is now the default
--history_pathhas been removed
--login_urlhas been removed
--multiprocess_min_porthas been removed
--persist_logshas been removed, as the logs now will always persist
--port_sqlite_datahas been removed, as old Datastore files are automatically converted into SQLite files when the application is run
--storage_pathhas been added
--task_retry_secondshas been removed
--use_sqlitehas been removed, as SQLite is now always the Datastore file format
Running the Old Development Server
This section covers the old version of the Development Server, which was superseded in the 1.7.6 release of the App Engine SDK in March of 2013. While most developers should be able to use the updated Development Server, we have provided a legacy copy of the original Development Server in the SDK for those who are not yet ready to upgrade.
Once you have a directory for your application and an app.yaml configuration file, you can start the development web server with the
The web server listens on port 8080 by default. You can visit the application at this URL: http://localhost:8080/
To change which port the web server uses, use the
old_dev_appserver.py --port=9999 myapp
To stop the web server: With Windows, press Control-Break in your command prompt window. With Mac OS X or Unix, press Control-C.
While it is running, the web server watches for changes you make to your files, and reloads them if needed. For most kinds of changes, you can simply edit files, then reload the web page in your browser. Under certain circumstances, such as if the application does dynamic imports, you may need to restart the web server to reset module import caching.
Be sure to run
old_dev_appserver.py using Python 2.5. It will run under Python 2.4, but there are differences between Python 2.4 and 2.5 that may affect your application, such as handling of Unicode strings.
Accessing Application IDs in the Development Web Server
If you need to access your App ID, for example to spoof an email address, use the get_application_id() function. To get the hostname of the running app, use the get_default_version_hostname() function.
Warning! Do not get the App ID from the environment variable. The development server simulates the production App Engine service. One way in which it does this is to prepend a string (
dev~) to the
APPLICATION_ID environment variable, which is similar to the string prepended in production for applications using the High Replication Datastore. You can modify this behavior with the --default_partition flag, choosing a value of
"" to match the master-slave option in production. Google recommends always getting the application ID using the get_application_id() method, and never using the
APPLICATION_ID environment variable.
Using the Datastore
The development web server simulates the App Engine datastore using a file on your computer. This file persists between invocations of the web server, so data you store will still be available the next time you run the web server.
To clear the local datastore for an application, use the
--clear_datastore option when you start the web server:
old_dev_appserver.py --clear_datastore myapp
The web server prints the location of the datastore file it is using to the terminal when it starts up. You can make a copy of the file, then restore them later to reset the datastore to a known state. Be sure to restart the web server after replacing the datastore file.
To change the location used for the datastore file, use the
old_dev_appserver.py --datastore_path=/tmp/myapp_datastore myapp
When your application performs a query on the datastore, the development web server checks that the query is supported by the application's
index.yaml file. If the query requires that its index be mentioned in the file, the server generates one and adds it to the file. You may want to edit this file if your application may attempt queries that are not exercised by your tests.
index.yaml is generated from every query made since the datastore file was created or last cleared. The query history is stored in a separate file. To change the location of the history file, use the
--history_path option similarly to the
Simulating the High Replication Datastore Consistency Model
You can configure the local datastore to simulate the consistency model of the High Replication Datastore. This will give you a good idea how an application configured to use the High Replication Datastore will operate in production.
To enable the High Replication consistency model, use the
Switching to SQLite for Your Local Datastore
If you store a lot of data in your datastore, you can improve performance and startup times by switching the backend for your local datastore stub to SQLite.
Note: Switching between SQLite and regular datastore backends will erase your local datastore.
To switch to SQLite, use the
Converting Your Local Datastore to SQLite Format
old_dev_appserver.py --use_sqlite --port_sqlite_dataWhile the development web server is running, create a backup of the SQLite version of the Datastore file.
cp /tmp/dev_appserver.datastore /tmp/dev_appserver.datastore.sqliteOnce the development web server is stopped, replace the default file.
mv /tmp/dev_appserver.datastore.sqlite /tmp/dev_appserver.datastoreNext time, you can start the development web server with SQLite enabled.
Specifying the Automatic ID Allocation Policy
You can configure how the local datastore assigns automatic entity IDs. The following automatic ID allocation policies are supported in the development server:
sequential: IDs are assigned from the sequence of consecutive integers.
scattered: IDs are assigned from a non-repeating sequence of approximately uniformly distributed integers.
Note: Both these ID policies differ from the production datastore behavior. Your app should make no assumptions about the sequence of automatic IDs assigned in production.
In the file-backed local datastore, the automatic IDs of all entities are drawn from a single ID sequence. In the SQLite-backed local datastore and the production datastore, a separate ID sequence is maintained for each entity group.
The default policy in the local datastore is
To specify the automatic ID assignment policy, use the
Note: The default local test configuration uses the
sequential policy, but will change to
scattered in a future release. You may wish to run your tests with the
scattered policy to prepare for this.
The development web server simulates Google Accounts with its own sign-in and sign-out pages. While running under the development web server,
the users.create_login_url and users.create_logout_url
functions return URLs for
/_ah/logout on the local server.
The development sign-in page includes a form where you can enter an email address. Your session uses whatever email address you enter as the active user.
To have the application believe that the logged-in user is an administrator, check the checkbox on the form.
The development web server can send email for calls to the App Engine mail service. To enable email support, the web server must be given options that specify a mail server to use. The web server can use an SMTP server, or it can use a local installation of Sendmail.
To enable mail support with an SMTP server, use the
--smtp_password options with the appropriate values.
old_dev_appserver.py --smtp_host=smtp.example.com --smtp_port=25 \ --smtp_user=ajohnson --smtp_password=k1tt3ns myapp
To enable mail support with Sendmail, use the
--enable_sendmail option. The web server will use the
sendmail command to send email messages, with your installation's default configuration.
old_dev_appserver.py --enable_sendmail myapp
If mail is not enabled with either SMTP or Sendmail, then attempts to send email from the application will do nothing, and appear successful in the application.
Using URL Fetch
When your application uses the URL fetch API to make an HTTP request, the development web server makes the request directly from your computer. The behavior may differ from when your application runs on App Engine if you use a proxy server for accessing websites.
old_dev_appserver.py can only serve one request at a time. If your application makes URL fetch requests to itself while processing a request, these requests will fail when using the development web server. The new Development Server (dev_appserver.py) can serve multiple requests in parallel.
The Development Console
The development web server includes a console web application. With the console, you can browse the local datastore, and interact with the application by submitting Python code to a web form.
To access the console, visit the URL
http://localhost:8080/_ah/admin on your server.
The Interactive Console
The Interactive Console allows developers to enter arbitrary Python code into a web form and execute it inside their app's environment.
To access the Interactive Console, go to the Development Console for your application, then click the Interactive Console link on the left navigation. A form with a single text area will display. Enter any arbitrary Python code you like in the text area, then submit the form to execute it.
The Interactive Console has the same access to the application's environment and services as a .py file inside the application itself. Be careful, because this means writes to your data store will be executed for real!
The Interactive Console is disabled by default when the Development Server is run on a non-default address using the --address command line argument. This is to prevent users from accidentally allowing anyone from remotely executing arbitrary Python code on their computer. Users can bypass this behaviour and re-enable the Interactive Console by running the Development Server with the --enable_console command line argument.
old_dev_appserver.py command supports the following command-line arguments:
The path to use for the local datastore data file. The server creates this file if it does not exist.
How the local datastore assigns automatic IDs. Options are
scattered. The default is
The path to use for the local datastore history file. The server uses the query history file to generate entries for
Prints verbose debugging messages to the console while running.
Prints a helpful message then quits.
The relative URL to use for the Users sign-in page. Default is
The port number to use for the server. Default is
The host address to use for the server. You may need to set this to be able to access the development server from another computer on your network. An address of
0.0.0.0allows both localhost access and hostname access. Default is
Clears the datastore data and history files before starting the web server.
By default, development server logs are stored in memory only. This option turns on disk storage of logs to make them available across development server restarts. The logs are stored by default at
/tmp/dev_appserver.logsand are accessible to the logservice.fetch() functionality. If you wish to specify your own location and/or log file name, use the
--logs_pathoption instead of
By default, development server logs are stored in memory only. This option turns on disk storage of logs at the location specified by LOGS_FILE, making the logs available across server restarts to the logservice.fetch() functionality. For example,
devappserver.py --logs_path=/home/logs/boglogs bog
Disables automatic generation of entries in the
index.yamlfile. Instead, when the application makes a query that requires that its index be defined in the file and the index definition is not found, an exception will be raised, similar to what would happen when running on App Engine.
The hostname of the SMTP server to use for sending email messages.
The port number of the SMTP server to use for sending email messages.
The username to use with the SMTP server for sending email messages.
The password to use with the SMTP server for sending email messages.
Uses the local computer's Sendmail installation for sending email messages.
Prints debugging messages related to importing modules, including search paths and errors.
Specifies the partition to use. The default partition is
dev, but you can change it to any string, or
"". The development server adds the name of the prefix followed by a
dev~) to the application ID stored in the environment variable.