Permalink
Comparing changes
Open a pull request
- 2 commits
- 8 files changed
- 0 commit comments
- 1 contributor
Unified
Split
Showing
with
50 additions
and 38 deletions.
- +3 −2 docs/auth/basic.rst
- +1 −3 docs/automating_development_process/part3.rst
- +4 −2 docs/configuration/whirlwind_tour.rst
- +12 −10 docs/debugging/pydev.rst
- +12 −4 docs/deployment/dotcloud.rst
- +15 −15 docs/deployment/nginx.rst
- +0 −1 docs/pylons/templates.rst
- +3 −1 docs/todo.rst
| @@ -1,5 +1,5 @@ | ||
| Basic Authentication Policy | ||
| %%%%%%%%%%%%%%%%%%%%%%%%%%% | ||
| HTTP Basic Authentication Policy | ||
| %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% | ||
| Here's an implementation of an HTTP basic auth Pyramid authentication policy:: | ||
| @@ -98,3 +98,4 @@ Use it something like:: | ||
| config = Configurator( | ||
| authentication_policy=BasicAuthenticationPolicy(mycheck)) | ||
| @@ -21,8 +21,6 @@ Production: | ||
| PRODUCTION = true | ||
| minify = dist | ||
| ... | ||
| Development: | ||
| .. code-block:: ini | ||
| @@ -32,7 +30,7 @@ Development: | ||
| PRODUCTION = false | ||
| minify = app | ||
| ... | ||
| View callables | ||
| ============== | ||
| @@ -4,7 +4,7 @@ A Whirlwind Tour of Advanced Pyramid Configuration Tactics | ||
| ========================================================== | ||
| Concepts: Configuration, Directives, and Statements | ||
| ----------------------------------------------------- | ||
| ---------------------------------------------------- | ||
| This article attempts to demonstrate some of Pyramid's more advanced | ||
| startup-time configuration features. The stuff below talks about | ||
| @@ -157,7 +157,9 @@ temporarily within ``app.py``:: | ||
| server = make_server('0.0.0.0', 8080, app) | ||
| server.serve_forever() | ||
| When we attempt to run this Pyramid application, we get a traceback:: | ||
| When we attempt to run this Pyramid application, we get a traceback: | ||
| .. code-block:: text | ||
| Traceback (most recent call last): | ||
| File "app.py", line 12, in <module> | ||
| @@ -122,9 +122,11 @@ Running/Debugging Pyramid under Pydev | ||
| We will set up PyDev to run pserve as part of a run or debug configuration. | ||
| First, copy ``pserve.py`` from your virtualenv to a location outside of your | ||
| project library path:: | ||
| project library path: | ||
| cp $WORKON_HOME/proj_venv/bin/pserve.py $WORKSPACE | ||
| .. code-block:: bash | ||
| $ cp $WORKON_HOME/proj_venv/bin/pserve.py $WORKSPACE | ||
| .. note:: | ||
| @@ -136,14 +138,14 @@ configuration, right click on the project and select | ||
| configuration type, and click on the new configuration icon. Add your | ||
| project name (or browse to it), in this case "tutorial". | ||
| Add these values to the *Main* tab:: | ||
| Add these values to the *Main* tab: | ||
| Project: RunPyramid | ||
| Main Module: ${workspace_loc}/pserve.py | ||
| * Project: ``RunPyramid`` | ||
| * Main Module: ``${workspace_loc}/pserve.py`` | ||
| Add these values to the *Arguments* tab:: | ||
| Add these values to the *Arguments* tab: | ||
| Program arguments: ${workspace_loc:tutorial/development.ini} --reload | ||
| * Program arguments: ``${workspace_loc:tutorial/development.ini} --reload`` | ||
| .. note:: | ||
| @@ -154,10 +156,10 @@ Add these values to the *Arguments* tab:: | ||
| without the ``--reload``, and instead of checking "Run" | ||
| in the "Display in favorites menu", check "Debug". | ||
| On the *Common* tab:: | ||
| On the *Common* tab: | ||
| Uncheck "Launch in background" | ||
| In the box labeled "Display in favorites menu", check "Run" | ||
| * Uncheck "Launch in background" | ||
| * In the box labeled "Display in favorites menu", check "Run" | ||
| Hit *Run* (*Debug*) to run (debug) your configuration immediately, | ||
| or *Apply* to create the configuration without running it. | ||
| @@ -10,7 +10,9 @@ Step 0: Install DotCloud | ||
| ======================== | ||
| `Install DotCloud's CLI | ||
| <http://docs.dotcloud.com/firststeps/install/>`_ by running:: | ||
| <http://docs.dotcloud.com/firststeps/install/>`_ by running: | ||
| .. code-block:: bash | ||
| $ pip install dotcloud | ||
| @@ -52,7 +54,9 @@ root directory of your app. Here are some samples for a basic Pyramid app: | ||
| Learn more about the `DotCloud buildfile <http://docs.dotcloud.com/guides/build-file/>`_. | ||
| ``wsgi.py``:: | ||
| ``wsgi.py``: | ||
| .. code-block:: python | ||
| # Your WSGI callable should be named “application”, be located in a | ||
| # "wsgi.py" file, itself located at the top directory of the service. | ||
| @@ -76,7 +80,9 @@ If you specified a database service in your dotcloud.yml, the connection info | ||
| will be made available to your service in a JSON file at | ||
| /home/dotcloud/environment.json. For example, the following code would read | ||
| the environment.json file and add the PostgreSQL URL to the settings of | ||
| your pyramid app:: | ||
| your pyramid app: | ||
| .. code-block:: python | ||
| import json | ||
| @@ -97,7 +103,9 @@ Step 3: Deploy your app | ||
| Now you can deploy your app. Remember to commit your changes if you're | ||
| using Mercurial or Git, then run these commands in the top directory | ||
| of your app:: | ||
| of your app: | ||
| .. code-block:: bash | ||
| $ dotcloud create your_app_name | ||
| $ dotcloud push your_app_name | ||
| @@ -12,7 +12,7 @@ static content as well as acting as a proxy between other applications and the | ||
| outside world. As a proxy, it also has good support for basic load balancing | ||
| between multiple instances of an application. | ||
| :: | ||
| .. code-block:: text | ||
| Client <---> Nginx [0.0.0.0:80] <---> (static files) | ||
| /|\ | ||
| @@ -23,9 +23,11 @@ Our target setup is going to be an Nginx server listening on port 80 and | ||
| load-balancing between 2 pserve processes. It will also serve the static files | ||
| from our project's directory. | ||
| Let's assume a basic project setup:: | ||
| Let's assume a basic project setup: | ||
| /home/example/myapp | ||
| .. code-block:: text | ||
| /home/example/myapp | ||
| | | ||
| |-- env (your virtualenv) | ||
| | | ||
| @@ -46,7 +48,7 @@ Step 1: Configuring Nginx | ||
| Nginx needs to be configured as a proxy for your application. An example | ||
| configuration is shown here: | ||
| .. code-block:: ini | ||
| .. code-block:: nginx | ||
| :linenos: | ||
| # nginx.conf | ||
| @@ -101,7 +103,7 @@ configuration is shown here: | ||
| include /etc/nginx/sites-enabled/*; | ||
| } | ||
| .. code-block:: ini | ||
| .. code-block:: nginx | ||
| :linenos: | ||
| # myapp.conf | ||
| @@ -146,8 +148,8 @@ configuration is shown here: | ||
| .. note:: | ||
| myapp.conf is actually included into the ``http {}`` section of the | ||
| main nginx.conf file. | ||
| ``myapp.conf`` is actually included into the ``http {}`` section of the main | ||
| ``nginx.conf`` file. | ||
| The optional ``listen`` directive, as well as the 2 following lines, | ||
| @@ -158,7 +160,6 @@ the `OpenSSL <http://www.openssl.org/docs/HOWTO/certificates.txt>`_ howto. | ||
| You will also need to update the paths that are shown to match the actual | ||
| path to your SSL certificates. | ||
| The ``upstream`` directive sets up a round-robin load-balancer between two | ||
| processes. The proxy is then configured to pass requests through the balancer | ||
| with the ``proxy_pass`` directive. It's important to investigate the | ||
| @@ -185,7 +186,7 @@ can distinguish between different domains, HTTP vs. HTTPS, and with some | ||
| extra configuration to the ``paste_prefix`` filter it can even handle | ||
| hosting the application under a different URL than ``/``. | ||
| .. code-block:: ini | ||
| .. code-block:: nginx | ||
| :linenos: | ||
| #---------- App Configuration ---------- | ||
| @@ -234,10 +235,7 @@ be proxied to your WSGI application and can be served directly. | ||
| to be public. It will not respect any view permissions you've placed on | ||
| this directory. | ||
| .. code-block:: ini | ||
| :linenos: | ||
| ... | ||
| .. code-block:: nginx | ||
| location / { | ||
| # all of your proxy configuration | ||
| @@ -261,9 +259,11 @@ works for the simplest setups, but for a really robust server, you're going | ||
| to want to automate the startup and shutdown of those processes, as well as | ||
| have some way of managing failures. | ||
| Enter ``supervisord``:: | ||
| Enter ``supervisord``: | ||
| .. code-block:: bash | ||
| pip install supervisor | ||
| $ pip install supervisor | ||
| This is a great program that will manage arbitrary processes, restarting them | ||
| when they fail, providing hooks for sending emails, etc when things change, | ||
| @@ -15,7 +15,6 @@ in the settings: | ||
| .. code-block:: ini | ||
| [app:main] | ||
| ... | ||
| mako.directories = pyramidapp:templates | ||
| This enables relative template paths like ``renderer="/mytemplate.mak"`` and | ||
| @@ -10,7 +10,9 @@ TODO | ||
| - Provide an example of a catchall 500 error view. | ||
| - Redirecting to a URL with Parameters:: | ||
| - Redirecting to a URL with Parameters: | ||
| .. code-block:: irc | ||
| [22:04] <AGreatJewel> How do I redirect to a url and set some GET params? | ||
| some thing like return HTTPFound(location="whatever", params={ params here }) | ||