forked from orbit-oss/flask
Merge branch 'master' of github.com:mitsuhiko/flask
This commit is contained in:
commit
f0c089ff6b
2 changed files with 21 additions and 19 deletions
|
|
@ -5,9 +5,10 @@ Configuration Handling
|
|||
|
||||
.. versionadded:: 0.3
|
||||
|
||||
Applications need some kind of configuration. There are different things
|
||||
you might want to change like toggling debug mode, the secret key, and a
|
||||
lot of very similar things.
|
||||
Applications need some kind of configuration. There are different settings
|
||||
you might want to change depending on the application environment like
|
||||
toggling the debug mode, setting the secret key, and other such
|
||||
environment-specific things.
|
||||
|
||||
The way Flask is designed usually requires the configuration to be
|
||||
available when the application starts up. You can hardcode the
|
||||
|
|
@ -31,8 +32,7 @@ can be modified just like any dictionary::
|
|||
app.config['DEBUG'] = True
|
||||
|
||||
Certain configuration values are also forwarded to the
|
||||
:attr:`~flask.Flask` object so that you can read and write them from
|
||||
there::
|
||||
:attr:`~flask.Flask` object so you can read and write them from there::
|
||||
|
||||
app.debug = True
|
||||
|
||||
|
|
@ -147,10 +147,11 @@ The following configuration values are used internally by Flask:
|
|||
Configuring from Files
|
||||
----------------------
|
||||
|
||||
Configuration becomes more useful if you can configure from a file, and
|
||||
ideally that file would be outside of the actual application package so that
|
||||
you can install the package with distribute (:ref:`distribute-deployment`)
|
||||
and still modify that file afterwards.
|
||||
Configuration becomes more useful if you can store it in a separate file,
|
||||
ideally located outside the actual application package. This makes
|
||||
packaging and distributing your application possible via various package
|
||||
handling tools (:ref:`distribute-deployment`) and finally modifying the
|
||||
configuration file afterwards.
|
||||
|
||||
So a common pattern is this::
|
||||
|
||||
|
|
@ -178,12 +179,13 @@ The configuration files themselves are actual Python files. Only values
|
|||
in uppercase are actually stored in the config object later on. So make
|
||||
sure to use uppercase letters for your config keys.
|
||||
|
||||
Here is an example configuration file::
|
||||
Here is an example of a configuration file::
|
||||
|
||||
# Example configuration
|
||||
DEBUG = False
|
||||
SECRET_KEY = '?\xbf,\xb4\x8d\xa3"<\x9c\xb0@\x0f5\xab,w\xee\x8d$0\x13\x8b83'
|
||||
|
||||
Make sure to load the configuration very early on so that extensions have
|
||||
Make sure to load the configuration very early on, so that extensions have
|
||||
the ability to access the configuration when starting up. There are other
|
||||
methods on the config object as well to load from individual files. For a
|
||||
complete reference, read the :class:`~flask.Config` object's
|
||||
|
|
@ -194,9 +196,9 @@ Configuration Best Practices
|
|||
----------------------------
|
||||
|
||||
The downside with the approach mentioned earlier is that it makes testing
|
||||
a little harder. There is no one 100% solution for this problem in
|
||||
general, but there are a couple of things you can do to improve that
|
||||
experience:
|
||||
a little harder. There is no single 100% solution for this problem in
|
||||
general, but there are a couple of things you can keep in mind to improve
|
||||
that experience:
|
||||
|
||||
1. create your application in a function and register blueprints on it.
|
||||
That way you can create multiple instances of your application with
|
||||
|
|
@ -211,10 +213,10 @@ experience:
|
|||
Development / Production
|
||||
------------------------
|
||||
|
||||
Most applications need more than one configuration. There will at least
|
||||
be a separate configuration for a production server and one used during
|
||||
development. The easiest way to handle this is to use a default
|
||||
configuration that is always loaded and part of version control, and a
|
||||
Most applications need more than one configuration. There should be at
|
||||
least separate configurations for the production server and the one used
|
||||
during development. The easiest way to handle this is to use a default
|
||||
configuration that is always loaded and part of the version control, and a
|
||||
separate configuration that overrides the values as necessary as mentioned
|
||||
in the example above::
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Or, if you prefer:
|
|||
|
||||
.. sourcecode:: text
|
||||
|
||||
$ uwsgi -s /tmp/uwsgi.sock myapp:app
|
||||
$ uwsgi -s /tmp/uwsgi.sock -w myapp:app
|
||||
|
||||
Configuring nginx
|
||||
-----------------
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue