Fix Read the Docs build failure

2025-03-24 20:10:13 -07:00 · 2025-03-24 20:10:13 -07:00 · c0bbfef68d
commit c0bbfef68d
parent 9ce6e72e2c
259 changed files with 48269 additions and 0 deletions
--- a/_build/.buildinfo
+++ b/_build/.buildinfo
@ -0,0 +1,4 @@
+# Sphinx build info version 1
+# This file records the configuration used when building these files. When it is not found, a full rebuild will be done.
+config: 600360abbe6c4808701ab5031e46e0b0
+tags: d77d1c0d9ca2f4c8421862c7c5a0d620
--- a/_build/.doctrees/api.doctree
+++ b/_build/.doctrees/api.doctree
--- a/_build/.doctrees/appcontext.doctree
+++ b/_build/.doctrees/appcontext.doctree
--- a/_build/.doctrees/async-await.doctree
+++ b/_build/.doctrees/async-await.doctree
--- a/_build/.doctrees/blueprints.doctree
+++ b/_build/.doctrees/blueprints.doctree
--- a/_build/.doctrees/changes.doctree
+++ b/_build/.doctrees/changes.doctree
--- a/_build/.doctrees/cli.doctree
+++ b/_build/.doctrees/cli.doctree
--- a/_build/.doctrees/config.doctree
+++ b/_build/.doctrees/config.doctree
--- a/_build/.doctrees/contributing.doctree
+++ b/_build/.doctrees/contributing.doctree
--- a/_build/.doctrees/debugging.doctree
+++ b/_build/.doctrees/debugging.doctree
--- a/_build/.doctrees/deploying/apache-httpd.doctree
+++ b/_build/.doctrees/deploying/apache-httpd.doctree
--- a/_build/.doctrees/deploying/asgi.doctree
+++ b/_build/.doctrees/deploying/asgi.doctree
--- a/_build/.doctrees/deploying/eventlet.doctree
+++ b/_build/.doctrees/deploying/eventlet.doctree
--- a/_build/.doctrees/deploying/gevent.doctree
+++ b/_build/.doctrees/deploying/gevent.doctree
--- a/_build/.doctrees/deploying/gunicorn.doctree
+++ b/_build/.doctrees/deploying/gunicorn.doctree
--- a/_build/.doctrees/deploying/index.doctree
+++ b/_build/.doctrees/deploying/index.doctree
--- a/_build/.doctrees/deploying/mod_wsgi.doctree
+++ b/_build/.doctrees/deploying/mod_wsgi.doctree
--- a/_build/.doctrees/deploying/nginx.doctree
+++ b/_build/.doctrees/deploying/nginx.doctree
--- a/_build/.doctrees/deploying/proxy_fix.doctree
+++ b/_build/.doctrees/deploying/proxy_fix.doctree
--- a/_build/.doctrees/deploying/uwsgi.doctree
+++ b/_build/.doctrees/deploying/uwsgi.doctree
--- a/_build/.doctrees/deploying/waitress.doctree
+++ b/_build/.doctrees/deploying/waitress.doctree
--- a/_build/.doctrees/design.doctree
+++ b/_build/.doctrees/design.doctree
--- a/_build/.doctrees/environment.pickle
+++ b/_build/.doctrees/environment.pickle
--- a/_build/.doctrees/errorhandling.doctree
+++ b/_build/.doctrees/errorhandling.doctree
--- a/_build/.doctrees/extensiondev.doctree
+++ b/_build/.doctrees/extensiondev.doctree
--- a/_build/.doctrees/extensions.doctree
+++ b/_build/.doctrees/extensions.doctree
--- a/_build/.doctrees/index.doctree
+++ b/_build/.doctrees/index.doctree
--- a/_build/.doctrees/installation.doctree
+++ b/_build/.doctrees/installation.doctree
--- a/_build/.doctrees/license.doctree
+++ b/_build/.doctrees/license.doctree
--- a/_build/.doctrees/lifecycle.doctree
+++ b/_build/.doctrees/lifecycle.doctree
--- a/_build/.doctrees/logging.doctree
+++ b/_build/.doctrees/logging.doctree
--- a/_build/.doctrees/patterns/appdispatch.doctree
+++ b/_build/.doctrees/patterns/appdispatch.doctree
--- a/_build/.doctrees/patterns/appfactories.doctree
+++ b/_build/.doctrees/patterns/appfactories.doctree
--- a/_build/.doctrees/patterns/caching.doctree
+++ b/_build/.doctrees/patterns/caching.doctree
--- a/_build/.doctrees/patterns/celery.doctree
+++ b/_build/.doctrees/patterns/celery.doctree
--- a/_build/.doctrees/patterns/deferredcallbacks.doctree
+++ b/_build/.doctrees/patterns/deferredcallbacks.doctree
--- a/_build/.doctrees/patterns/favicon.doctree
+++ b/_build/.doctrees/patterns/favicon.doctree
--- a/_build/.doctrees/patterns/fileuploads.doctree
+++ b/_build/.doctrees/patterns/fileuploads.doctree
--- a/_build/.doctrees/patterns/flashing.doctree
+++ b/_build/.doctrees/patterns/flashing.doctree
--- a/_build/.doctrees/patterns/index.doctree
+++ b/_build/.doctrees/patterns/index.doctree
--- a/_build/.doctrees/patterns/javascript.doctree
+++ b/_build/.doctrees/patterns/javascript.doctree
--- a/_build/.doctrees/patterns/jquery.doctree
+++ b/_build/.doctrees/patterns/jquery.doctree
--- a/_build/.doctrees/patterns/lazyloading.doctree
+++ b/_build/.doctrees/patterns/lazyloading.doctree
--- a/_build/.doctrees/patterns/methodoverrides.doctree
+++ b/_build/.doctrees/patterns/methodoverrides.doctree
--- a/_build/.doctrees/patterns/mongoengine.doctree
+++ b/_build/.doctrees/patterns/mongoengine.doctree
--- a/_build/.doctrees/patterns/packages.doctree
+++ b/_build/.doctrees/patterns/packages.doctree
--- a/_build/.doctrees/patterns/requestchecksum.doctree
+++ b/_build/.doctrees/patterns/requestchecksum.doctree
--- a/_build/.doctrees/patterns/singlepageapplications.doctree
+++ b/_build/.doctrees/patterns/singlepageapplications.doctree
--- a/_build/.doctrees/patterns/sqlalchemy.doctree
+++ b/_build/.doctrees/patterns/sqlalchemy.doctree
--- a/_build/.doctrees/patterns/sqlite3.doctree
+++ b/_build/.doctrees/patterns/sqlite3.doctree
--- a/_build/.doctrees/patterns/streaming.doctree
+++ b/_build/.doctrees/patterns/streaming.doctree
--- a/_build/.doctrees/patterns/subclassing.doctree
+++ b/_build/.doctrees/patterns/subclassing.doctree
--- a/_build/.doctrees/patterns/templateinheritance.doctree
+++ b/_build/.doctrees/patterns/templateinheritance.doctree
--- a/_build/.doctrees/patterns/urlprocessors.doctree
+++ b/_build/.doctrees/patterns/urlprocessors.doctree
--- a/_build/.doctrees/patterns/viewdecorators.doctree
+++ b/_build/.doctrees/patterns/viewdecorators.doctree
--- a/_build/.doctrees/patterns/wtforms.doctree
+++ b/_build/.doctrees/patterns/wtforms.doctree
--- a/_build/.doctrees/quickstart.doctree
+++ b/_build/.doctrees/quickstart.doctree
--- a/_build/.doctrees/reqcontext.doctree
+++ b/_build/.doctrees/reqcontext.doctree
--- a/_build/.doctrees/server.doctree
+++ b/_build/.doctrees/server.doctree
--- a/_build/.doctrees/shell.doctree
+++ b/_build/.doctrees/shell.doctree
--- a/_build/.doctrees/signals.doctree
+++ b/_build/.doctrees/signals.doctree
--- a/_build/.doctrees/templating.doctree
+++ b/_build/.doctrees/templating.doctree
--- a/_build/.doctrees/testing.doctree
+++ b/_build/.doctrees/testing.doctree
--- a/_build/.doctrees/tutorial/blog.doctree
+++ b/_build/.doctrees/tutorial/blog.doctree
--- a/_build/.doctrees/tutorial/database.doctree
+++ b/_build/.doctrees/tutorial/database.doctree
--- a/_build/.doctrees/tutorial/deploy.doctree
+++ b/_build/.doctrees/tutorial/deploy.doctree
--- a/_build/.doctrees/tutorial/factory.doctree
+++ b/_build/.doctrees/tutorial/factory.doctree
--- a/_build/.doctrees/tutorial/index.doctree
+++ b/_build/.doctrees/tutorial/index.doctree
--- a/_build/.doctrees/tutorial/install.doctree
+++ b/_build/.doctrees/tutorial/install.doctree
--- a/_build/.doctrees/tutorial/layout.doctree
+++ b/_build/.doctrees/tutorial/layout.doctree
--- a/_build/.doctrees/tutorial/next.doctree
+++ b/_build/.doctrees/tutorial/next.doctree
--- a/_build/.doctrees/tutorial/static.doctree
+++ b/_build/.doctrees/tutorial/static.doctree
--- a/_build/.doctrees/tutorial/templates.doctree
+++ b/_build/.doctrees/tutorial/templates.doctree
--- a/_build/.doctrees/tutorial/tests.doctree
+++ b/_build/.doctrees/tutorial/tests.doctree
--- a/_build/.doctrees/tutorial/views.doctree
+++ b/_build/.doctrees/tutorial/views.doctree
--- a/_build/.doctrees/views.doctree
+++ b/_build/.doctrees/views.doctree
--- a/_build/.doctrees/web-security.doctree
+++ b/_build/.doctrees/web-security.doctree
--- a/_build/404/index.html
+++ b/_build/404/index.html
@ -0,0 +1,82 @@
+<!DOCTYPE html>
+
+<html lang="en" data-content_root="../">
+  <head>
+    <meta charset="utf-8" />
+    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
+  <meta name="viewport" content="width=device-width, initial-scale=1">
+    <title>Page Not Found &#8212; Flask Documentation (3.1.x)</title>
+    <link rel="stylesheet" type="text/css" href="/_static/pygments.css?v=4f649999" />
+    <link rel="stylesheet" type="text/css" href="/_static/flask.css?v=b87c8d14" />
+    <script src="/_static/documentation_options.js?v=d71c4578"></script>
+    <script src="/_static/doctools.js?v=9bcbadda"></script>
+    <script src="/_static/sphinx_highlight.js?v=dc90522c"></script>
+    <script data-project="flask" data-version="3.1.x" src="/_static/describe_version.js?v=fa7f30d0"></script>
+    <link rel="icon" href="/_static/shortcut-icon.png"/>
+    <link rel="index" title="Index" href="/genindex/" />
+    <link rel="search" title="Search" href="/search/" />
+  </head><body>
+    <div class="related" role="navigation" aria-label="Related">
+      <h3>Navigation</h3>
+      <ul>
+        <li class="right" style="margin-right: 10px">
+          <a href="/genindex/" title="General Index"
+             accesskey="I">index</a></li>
+        <li class="right" >
+          <a href="/py-modindex/" title="Python Module Index"
+             >modules</a> |</li>
+        <li class="nav-item nav-item-0"><a href="#">Flask Documentation (3.1.x)</a> &#187;</li>
+        <li class="nav-item nav-item-this"><a href="">Page Not Found</a></li>
+      </ul>
+    </div>
+
+    <div class="document">
+      <div class="documentwrapper">
+        <div class="bodywrapper">
+          <div class="body" role="main">
+
+  <h1>Page Not Found</h1>
+            <p>
+              The page you requested does not exist. You may have followed a bad
+              link, or the page may have been moved or removed.
+
+
+            <div class="clearer"></div>
+          </div>
+        </div>
+      </div>
+  <span id="sidebar-top"></span>
+      <div class="sphinxsidebar" role="navigation" aria-label="Main">
+        <div class="sphinxsidebarwrapper">
+
+
+            <p class="logo"><a href="#">
+              <img class="logo" src="/_static/flask-vertical.png" alt="Logo of Flask"/>
+            </a></p>
+
+<h3>Navigation</h3>
+<ul>
+  <li><a href="#">Overview</a>
+
+  </li>
+</ul>
+<search id="searchbox" style="display: none" role="search">
+  <h3 id="searchlabel">Quick search</h3>
+    <div class="searchformwrapper">
+    <form class="search" action="/search/" method="get">
+      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
+      <input type="submit" value="Go" />
+    </form>
+    </div>
+</search>
+<script>document.getElementById('searchbox').style.display = "block"</script><div id="ethical-ad-placement"></div>
+        </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="footer" role="contentinfo">
+    &#169; Copyright 2010 Pallets.
+      Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 8.1.3.
+    </div>
+  </body>
+</html>
--- a/_build/_images/debugger.png
+++ b/_build/_images/debugger.png
--- a/_build/_images/flask-horizontal.png
+++ b/_build/_images/flask-horizontal.png
--- a/_build/_images/flaskr_edit.png
+++ b/_build/_images/flaskr_edit.png
--- a/_build/_images/flaskr_index.png
+++ b/_build/_images/flaskr_index.png
--- a/_build/_images/flaskr_login.png
+++ b/_build/_images/flaskr_login.png
--- a/_build/_images/pycharm-run-config.png
+++ b/_build/_images/pycharm-run-config.png
--- a/_build/_sources/api.rst.txt
+++ b/_build/_sources/api.rst.txt
@ -0,0 +1,717 @@
+API
+===
+
+.. module:: flask
+
+This part of the documentation covers all the interfaces of Flask. For
+parts where Flask depends on external libraries, we document the most
+important right here and provide links to the canonical documentation.
+
+
+Application Object
+------------------
+
+.. autoclass:: Flask
+   :members:
+   :inherited-members:
+
+
+Blueprint Objects
+-----------------
+
+.. autoclass:: Blueprint
+   :members:
+   :inherited-members:
+
+Incoming Request Data
+---------------------
+
+.. autoclass:: Request
+    :members:
+    :inherited-members:
+    :exclude-members: json_module
+
+.. attribute:: request
+
+   To access incoming request data, you can use the global `request`
+   object. Flask parses incoming request data for you and gives you
+   access to it through that global object. Internally Flask makes
+   sure that you always get the correct data for the active thread if you
+   are in a multithreaded environment.
+
+   This is a proxy. See :ref:`notes-on-proxies` for more information.
+
+   The request object is an instance of a :class:`~flask.Request`.
+
+
+Response Objects
+----------------
+
+.. autoclass:: flask.Response
+    :members:
+    :inherited-members:
+    :exclude-members: json_module
+
+Sessions
+--------
+
+If you have set :attr:`Flask.secret_key` (or configured it from
+:data:`SECRET_KEY`) you can use sessions in Flask applications. A session makes
+it possible to remember information from one request to another. The way Flask
+does this is by using a signed cookie. The user can look at the session
+contents, but can't modify it unless they know the secret key, so make sure to
+set that to something complex and unguessable.
+
+To access the current session you can use the :class:`session` object:
+
+.. class:: session
+
+   The session object works pretty much like an ordinary dict, with the
+   difference that it keeps track of modifications.
+
+   This is a proxy. See :ref:`notes-on-proxies` for more information.
+
+   The following attributes are interesting:
+
+   .. attribute:: new
+
+      ``True`` if the session is new, ``False`` otherwise.
+
+   .. attribute:: modified
+
+      ``True`` if the session object detected a modification. Be advised
+      that modifications on mutable structures are not picked up
+      automatically, in that situation you have to explicitly set the
+      attribute to ``True`` yourself. Here an example::
+
+          # this change is not picked up because a mutable object (here
+          # a list) is changed.
+          session['objects'].append(42)
+          # so mark it as modified yourself
+          session.modified = True
+
+   .. attribute:: permanent
+
+      If set to ``True`` the session lives for
+      :attr:`~flask.Flask.permanent_session_lifetime` seconds. The
+      default is 31 days. If set to ``False`` (which is the default) the
+      session will be deleted when the user closes the browser.
+
+
+Session Interface
+-----------------
+
+.. versionadded:: 0.8
+
+The session interface provides a simple way to replace the session
+implementation that Flask is using.
+
+.. currentmodule:: flask.sessions
+
+.. autoclass:: SessionInterface
+   :members:
+
+.. autoclass:: SecureCookieSessionInterface
+   :members:
+
+.. autoclass:: SecureCookieSession
+   :members:
+
+.. autoclass:: NullSession
+   :members:
+
+.. autoclass:: SessionMixin
+   :members:
+
+.. admonition:: Notice
+
+    The :data:`PERMANENT_SESSION_LIFETIME` config can be an integer or ``timedelta``.
+    The :attr:`~flask.Flask.permanent_session_lifetime` attribute is always a
+    ``timedelta``.
+
+
+Test Client
+-----------
+
+.. currentmodule:: flask.testing
+
+.. autoclass:: FlaskClient
+   :members:
+
+
+Test CLI Runner
+---------------
+
+.. currentmodule:: flask.testing
+
+.. autoclass:: FlaskCliRunner
+    :members:
+
+
+Application Globals
+-------------------
+
+.. currentmodule:: flask
+
+To share data that is valid for one request only from one function to
+another, a global variable is not good enough because it would break in
+threaded environments. Flask provides you with a special object that
+ensures it is only valid for the active request and that will return
+different values for each request. In a nutshell: it does the right
+thing, like it does for :class:`request` and :class:`session`.
+
+.. data:: g
+
+    A namespace object that can store data during an
+    :doc:`application context </appcontext>`. This is an instance of
+    :attr:`Flask.app_ctx_globals_class`, which defaults to
+    :class:`ctx._AppCtxGlobals`.
+
+    This is a good place to store resources during a request. For
+    example, a ``before_request`` function could load a user object from
+    a session id, then set ``g.user`` to be used in the view function.
+
+    This is a proxy. See :ref:`notes-on-proxies` for more information.
+
+    .. versionchanged:: 0.10
+        Bound to the application context instead of the request context.
+
+.. autoclass:: flask.ctx._AppCtxGlobals
+    :members:
+
+
+Useful Functions and Classes
+----------------------------
+
+.. data:: current_app
+
+    A proxy to the application handling the current request. This is
+    useful to access the application without needing to import it, or if
+    it can't be imported, such as when using the application factory
+    pattern or in blueprints and extensions.
+
+    This is only available when an
+    :doc:`application context </appcontext>` is pushed. This happens
+    automatically during requests and CLI commands. It can be controlled
+    manually with :meth:`~flask.Flask.app_context`.
+
+    This is a proxy. See :ref:`notes-on-proxies` for more information.
+
+.. autofunction:: has_request_context
+
+.. autofunction:: copy_current_request_context
+
+.. autofunction:: has_app_context
+
+.. autofunction:: url_for
+
+.. autofunction:: abort
+
+.. autofunction:: redirect
+
+.. autofunction:: make_response
+
+.. autofunction:: after_this_request
+
+.. autofunction:: send_file
+
+.. autofunction:: send_from_directory
+
+
+Message Flashing
+----------------
+
+.. autofunction:: flash
+
+.. autofunction:: get_flashed_messages
+
+
+JSON Support
+------------
+
+.. module:: flask.json
+
+Flask uses Python's built-in :mod:`json` module for handling JSON by
+default. The JSON implementation can be changed by assigning a different
+provider to :attr:`flask.Flask.json_provider_class` or
+:attr:`flask.Flask.json`. The functions provided by ``flask.json`` will
+use methods on ``app.json`` if an app context is active.
+
+Jinja's ``|tojson`` filter is configured to use the app's JSON provider.
+The filter marks the output with ``|safe``. Use it to render data inside
+HTML ``<script>`` tags.
+
+.. sourcecode:: html+jinja
+
+    <script>
+        const names = {{ names|tojson }};
+        renderChart(names, {{ axis_data|tojson }});
+    </script>
+
+.. autofunction:: jsonify
+
+.. autofunction:: dumps
+
+.. autofunction:: dump
+
+.. autofunction:: loads
+
+.. autofunction:: load
+
+.. autoclass:: flask.json.provider.JSONProvider
+    :members:
+    :member-order: bysource
+
+.. autoclass:: flask.json.provider.DefaultJSONProvider
+    :members:
+    :member-order: bysource
+
+.. automodule:: flask.json.tag
+
+
+Template Rendering
+------------------
+
+.. currentmodule:: flask
+
+.. autofunction:: render_template
+
+.. autofunction:: render_template_string
+
+.. autofunction:: stream_template
+
+.. autofunction:: stream_template_string
+
+.. autofunction:: get_template_attribute
+
+Configuration
+-------------
+
+.. autoclass:: Config
+   :members:
+
+
+Stream Helpers
+--------------
+
+.. autofunction:: stream_with_context
+
+Useful Internals
+----------------
+
+.. autoclass:: flask.ctx.RequestContext
+   :members:
+
+.. data:: flask.globals.request_ctx
+
+    The current :class:`~flask.ctx.RequestContext`. If a request context
+    is not active, accessing attributes on this proxy will raise a
+    ``RuntimeError``.
+
+    This is an internal object that is essential to how Flask handles
+    requests. Accessing this should not be needed in most cases. Most
+    likely you want :data:`request` and :data:`session` instead.
+
+.. autoclass:: flask.ctx.AppContext
+   :members:
+
+.. data:: flask.globals.app_ctx
+
+    The current :class:`~flask.ctx.AppContext`. If an app context is not
+    active, accessing attributes on this proxy will raise a
+    ``RuntimeError``.
+
+    This is an internal object that is essential to how Flask handles
+    requests. Accessing this should not be needed in most cases. Most
+    likely you want :data:`current_app` and :data:`g` instead.
+
+.. autoclass:: flask.blueprints.BlueprintSetupState
+   :members:
+
+.. _core-signals-list:
+
+Signals
+-------
+
+Signals are provided by the `Blinker`_ library. See :doc:`signals` for an introduction.
+
+.. _blinker: https://blinker.readthedocs.io/
+
+.. data:: template_rendered
+
+   This signal is sent when a template was successfully rendered. The
+   signal is invoked with the instance of the template as `template`
+   and the context as dictionary (named `context`).
+
+   Example subscriber::
+
+        def log_template_renders(sender, template, context, **extra):
+            sender.logger.debug('Rendering template "%s" with context %s',
+                                template.name or 'string template',
+                                context)
+
+        from flask import template_rendered
+        template_rendered.connect(log_template_renders, app)
+
+.. data:: flask.before_render_template
+   :noindex:
+
+   This signal is sent before template rendering process. The
+   signal is invoked with the instance of the template as `template`
+   and the context as dictionary (named `context`).
+
+   Example subscriber::
+
+        def log_template_renders(sender, template, context, **extra):
+            sender.logger.debug('Rendering template "%s" with context %s',
+                                template.name or 'string template',
+                                context)
+
+        from flask import before_render_template
+        before_render_template.connect(log_template_renders, app)
+
+.. data:: request_started
+
+   This signal is sent when the request context is set up, before
+   any request processing happens. Because the request context is already
+   bound, the subscriber can access the request with the standard global
+   proxies such as :class:`~flask.request`.
+
+   Example subscriber::
+
+        def log_request(sender, **extra):
+            sender.logger.debug('Request context is set up')
+
+        from flask import request_started
+        request_started.connect(log_request, app)
+
+.. data:: request_finished
+
+   This signal is sent right before the response is sent to the client.
+   It is passed the response to be sent named `response`.
+
+   Example subscriber::
+
+        def log_response(sender, response, **extra):
+            sender.logger.debug('Request context is about to close down. '
+                                'Response: %s', response)
+
+        from flask import request_finished
+        request_finished.connect(log_response, app)
+
+.. data:: got_request_exception
+
+    This signal is sent when an unhandled exception happens during
+    request processing, including when debugging. The exception is
+    passed to the subscriber as ``exception``.
+
+    This signal is not sent for
+    :exc:`~werkzeug.exceptions.HTTPException`, or other exceptions that
+    have error handlers registered, unless the exception was raised from
+    an error handler.
+
+    This example shows how to do some extra logging if a theoretical
+    ``SecurityException`` was raised:
+
+    .. code-block:: python
+
+        from flask import got_request_exception
+
+        def log_security_exception(sender, exception, **extra):
+            if not isinstance(exception, SecurityException):
+                return
+
+            security_logger.exception(
+                f"SecurityException at {request.url!r}",
+                exc_info=exception,
+            )
+
+        got_request_exception.connect(log_security_exception, app)
+
+.. data:: request_tearing_down
+
+   This signal is sent when the request is tearing down. This is always
+   called, even if an exception is caused. Currently functions listening
+   to this signal are called after the regular teardown handlers, but this
+   is not something you can rely on.
+
+   Example subscriber::
+
+        def close_db_connection(sender, **extra):
+            session.close()
+
+        from flask import request_tearing_down
+        request_tearing_down.connect(close_db_connection, app)
+
+   As of Flask 0.9, this will also be passed an `exc` keyword argument
+   that has a reference to the exception that caused the teardown if
+   there was one.
+
+.. data:: appcontext_tearing_down
+
+   This signal is sent when the app context is tearing down. This is always
+   called, even if an exception is caused. Currently functions listening
+   to this signal are called after the regular teardown handlers, but this
+   is not something you can rely on.
+
+   Example subscriber::
+
+        def close_db_connection(sender, **extra):
+            session.close()
+
+        from flask import appcontext_tearing_down
+        appcontext_tearing_down.connect(close_db_connection, app)
+
+   This will also be passed an `exc` keyword argument that has a reference
+   to the exception that caused the teardown if there was one.
+
+.. data:: appcontext_pushed
+
+   This signal is sent when an application context is pushed. The sender
+   is the application. This is usually useful for unittests in order to
+   temporarily hook in information. For instance it can be used to
+   set a resource early onto the `g` object.
+
+   Example usage::
+
+        from contextlib import contextmanager
+        from flask import appcontext_pushed
+
+        @contextmanager
+        def user_set(app, user):
+            def handler(sender, **kwargs):
+                g.user = user
+            with appcontext_pushed.connected_to(handler, app):
+                yield
+
+   And in the testcode::
+
+        def test_user_me(self):
+            with user_set(app, 'john'):
+                c = app.test_client()
+                resp = c.get('/users/me')
+                assert resp.data == 'username=john'
+
+   .. versionadded:: 0.10
+
+.. data:: appcontext_popped
+
+   This signal is sent when an application context is popped. The sender
+   is the application. This usually falls in line with the
+   :data:`appcontext_tearing_down` signal.
+
+   .. versionadded:: 0.10
+
+.. data:: message_flashed
+
+   This signal is sent when the application is flashing a message. The
+   messages is sent as `message` keyword argument and the category as
+   `category`.
+
+   Example subscriber::
+
+        recorded = []
+        def record(sender, message, category, **extra):
+            recorded.append((message, category))
+
+        from flask import message_flashed
+        message_flashed.connect(record, app)
+
+   .. versionadded:: 0.10
+
+
+Class-Based Views
+-----------------
+
+.. versionadded:: 0.7
+
+.. currentmodule:: None
+
+.. autoclass:: flask.views.View
+   :members:
+
+.. autoclass:: flask.views.MethodView
+   :members:
+
+.. _url-route-registrations:
+
+URL Route Registrations
+-----------------------
+
+Generally there are three ways to define rules for the routing system:
+
+1.  You can use the :meth:`flask.Flask.route` decorator.
+2.  You can use the :meth:`flask.Flask.add_url_rule` function.
+3.  You can directly access the underlying Werkzeug routing system
+    which is exposed as :attr:`flask.Flask.url_map`.
+
+Variable parts in the route can be specified with angular brackets
+(``/user/<username>``). By default a variable part in the URL accepts any
+string without a slash however a different converter can be specified as
+well by using ``<converter:name>``.
+
+Variable parts are passed to the view function as keyword arguments.
+
+The following converters are available:
+
+=========== ===============================================
+`string`    accepts any text without a slash (the default)
+`int`       accepts integers
+`float`     like `int` but for floating point values
+`path`      like the default but also accepts slashes
+`any`       matches one of the items provided
+`uuid`      accepts UUID strings
+=========== ===============================================
+
+Custom converters can be defined using :attr:`flask.Flask.url_map`.
+
+Here are some examples::
+
+    @app.route('/')
+    def index():
+        pass
+
+    @app.route('/<username>')
+    def show_user(username):
+        pass
+
+    @app.route('/post/<int:post_id>')
+    def show_post(post_id):
+        pass
+
+An important detail to keep in mind is how Flask deals with trailing
+slashes. The idea is to keep each URL unique so the following rules
+apply:
+
+1. If a rule ends with a slash and is requested without a slash by the
+   user, the user is automatically redirected to the same page with a
+   trailing slash attached.
+2. If a rule does not end with a trailing slash and the user requests the
+   page with a trailing slash, a 404 not found is raised.
+
+This is consistent with how web servers deal with static files. This
+also makes it possible to use relative link targets safely.
+
+You can also define multiple rules for the same function. They have to be
+unique however. Defaults can also be specified. Here for example is a
+definition for a URL that accepts an optional page::
+
+    @app.route('/users/', defaults={'page': 1})
+    @app.route('/users/page/<int:page>')
+    def show_users(page):
+        pass
+
+This specifies that ``/users/`` will be the URL for page one and
+``/users/page/N`` will be the URL for page ``N``.
+
+If a URL contains a default value, it will be redirected to its simpler
+form with a 301 redirect. In the above example, ``/users/page/1`` will
+be redirected to ``/users/``. If your route handles ``GET`` and ``POST``
+requests, make sure the default route only handles ``GET``, as redirects
+can't preserve form data. ::
+
+   @app.route('/region/', defaults={'id': 1})
+   @app.route('/region/<int:id>', methods=['GET', 'POST'])
+   def region(id):
+      pass
+
+Here are the parameters that :meth:`~flask.Flask.route` and
+:meth:`~flask.Flask.add_url_rule` accept. The only difference is that
+with the route parameter the view function is defined with the decorator
+instead of the `view_func` parameter.
+
+=============== ==========================================================
+`rule`          the URL rule as string
+`endpoint`      the endpoint for the registered URL rule. Flask itself
+                assumes that the name of the view function is the name
+                of the endpoint if not explicitly stated.
+`view_func`     the function to call when serving a request to the
+                provided endpoint. If this is not provided one can
+                specify the function later by storing it in the
+                :attr:`~flask.Flask.view_functions` dictionary with the
+                endpoint as key.
+`defaults`      A dictionary with defaults for this rule. See the
+                example above for how defaults work.
+`subdomain`     specifies the rule for the subdomain in case subdomain
+                matching is in use. If not specified the default
+                subdomain is assumed.
+`**options`     the options to be forwarded to the underlying
+                :class:`~werkzeug.routing.Rule` object. A change to
+                Werkzeug is handling of method options. methods is a list
+                of methods this rule should be limited to (``GET``, ``POST``
+                etc.). By default a rule just listens for ``GET`` (and
+                implicitly ``HEAD``). Starting with Flask 0.6, ``OPTIONS`` is
+                implicitly added and handled by the standard request
+                handling. They have to be specified as keyword arguments.
+=============== ==========================================================
+
+
+View Function Options
+---------------------
+
+For internal usage the view functions can have some attributes attached to
+customize behavior the view function would normally not have control over.
+The following attributes can be provided optionally to either override
+some defaults to :meth:`~flask.Flask.add_url_rule` or general behavior:
+
+-   `__name__`: The name of a function is by default used as endpoint. If
+    endpoint is provided explicitly this value is used. Additionally this
+    will be prefixed with the name of the blueprint by default which
+    cannot be customized from the function itself.
+
+-   `methods`: If methods are not provided when the URL rule is added,
+    Flask will look on the view function object itself if a `methods`
+    attribute exists. If it does, it will pull the information for the
+    methods from there.
+
+-   `provide_automatic_options`: if this attribute is set Flask will
+    either force enable or disable the automatic implementation of the
+    HTTP ``OPTIONS`` response. This can be useful when working with
+    decorators that want to customize the ``OPTIONS`` response on a per-view
+    basis.
+
+-   `required_methods`: if this attribute is set, Flask will always add
+    these methods when registering a URL rule even if the methods were
+    explicitly overridden in the ``route()`` call.
+
+Full example::
+
+    def index():
+        if request.method == 'OPTIONS':
+            # custom options handling here
+            ...
+        return 'Hello World!'
+    index.provide_automatic_options = False
+    index.methods = ['GET', 'OPTIONS']
+
+    app.add_url_rule('/', index)
+
+.. versionadded:: 0.8
+   The `provide_automatic_options` functionality was added.
+
+Command Line Interface
+----------------------
+
+.. currentmodule:: flask.cli
+
+.. autoclass:: FlaskGroup
+   :members:
+
+.. autoclass:: AppGroup
+   :members:
+
+.. autoclass:: ScriptInfo
+   :members:
+
+.. autofunction:: load_dotenv
+
+.. autofunction:: with_appcontext
+
+.. autofunction:: pass_script_info
+
+   Marks a function so that an instance of :class:`ScriptInfo` is passed
+   as first argument to the click callback.
+
+.. autodata:: run_command
+
+.. autodata:: shell_command
--- a/_build/_sources/appcontext.rst.txt
+++ b/_build/_sources/appcontext.rst.txt
@ -0,0 +1,147 @@
+.. currentmodule:: flask
+
+The Application Context
+=======================
+
+The application context keeps track of the application-level data during
+a request, CLI command, or other activity. Rather than passing the
+application around to each function, the :data:`current_app` and
+:data:`g` proxies are accessed instead.
+
+This is similar to :doc:`/reqcontext`, which keeps track of
+request-level data during a request. A corresponding application context
+is pushed when a request context is pushed.
+
+Purpose of the Context
+----------------------
+
+The :class:`Flask` application object has attributes, such as
+:attr:`~Flask.config`, that are useful to access within views and
+:doc:`CLI commands </cli>`. However, importing the ``app`` instance
+within the modules in your project is prone to circular import issues.
+When using the :doc:`app factory pattern </patterns/appfactories>` or
+writing reusable :doc:`blueprints </blueprints>` or
+:doc:`extensions </extensions>` there won't be an ``app`` instance to
+import at all.
+
+Flask solves this issue with the *application context*. Rather than
+referring to an ``app`` directly, you use the :data:`current_app`
+proxy, which points to the application handling the current activity.
+
+Flask automatically *pushes* an application context when handling a
+request. View functions, error handlers, and other functions that run
+during a request will have access to :data:`current_app`.
+
+Flask will also automatically push an app context when running CLI
+commands registered with :attr:`Flask.cli` using ``@app.cli.command()``.
+
+
+Lifetime of the Context
+-----------------------
+
+The application context is created and destroyed as necessary. When a
+Flask application begins handling a request, it pushes an application
+context and a :doc:`request context </reqcontext>`. When the request
+ends it pops the request context then the application context.
+Typically, an application context will have the same lifetime as a
+request.
+
+See :doc:`/reqcontext` for more information about how the contexts work
+and the full life cycle of a request.
+
+
+Manually Push a Context
+-----------------------
+
+If you try to access :data:`current_app`, or anything that uses it,
+outside an application context, you'll get this error message:
+
+.. code-block:: pytb
+
+    RuntimeError: Working outside of application context.
+
+    This typically means that you attempted to use functionality that
+    needed to interface with the current application object in some way.
+    To solve this, set up an application context with app.app_context().
+
+If you see that error while configuring your application, such as when
+initializing an extension, you can push a context manually since you
+have direct access to the ``app``. Use :meth:`~Flask.app_context` in a
+``with`` block, and everything that runs in the block will have access
+to :data:`current_app`. ::
+
+    def create_app():
+        app = Flask(__name__)
+
+        with app.app_context():
+            init_db()
+
+        return app
+
+If you see that error somewhere else in your code not related to
+configuring the application, it most likely indicates that you should
+move that code into a view function or CLI command.
+
+
+Storing Data
+------------
+
+The application context is a good place to store common data during a
+request or CLI command. Flask provides the :data:`g object <g>` for this
+purpose. It is a simple namespace object that has the same lifetime as
+an application context.
+
+.. note::
+    The ``g`` name stands for "global", but that is referring to the
+    data being global *within a context*. The data on ``g`` is lost
+    after the context ends, and it is not an appropriate place to store
+    data between requests. Use the :data:`session` or a database to
+    store data across requests.
+
+A common use for :data:`g` is to manage resources during a request.
+
+1.  ``get_X()`` creates resource ``X`` if it does not exist, caching it
+    as ``g.X``.
+2.  ``teardown_X()`` closes or otherwise deallocates the resource if it
+    exists. It is registered as a :meth:`~Flask.teardown_appcontext`
+    handler.
+
+For example, you can manage a database connection using this pattern::
+
+    from flask import g
+
+    def get_db():
+        if 'db' not in g:
+            g.db = connect_to_database()
+
+        return g.db
+
+    @app.teardown_appcontext
+    def teardown_db(exception):
+        db = g.pop('db', None)
+
+        if db is not None:
+            db.close()
+
+During a request, every call to ``get_db()`` will return the same
+connection, and it will be closed automatically at the end of the
+request.
+
+You can use :class:`~werkzeug.local.LocalProxy` to make a new context
+local from ``get_db()``::
+
+    from werkzeug.local import LocalProxy
+    db = LocalProxy(get_db)
+
+Accessing ``db`` will call ``get_db`` internally, in the same way that
+:data:`current_app` works.
+
+
+Events and Signals
+------------------
+
+The application will call functions registered with :meth:`~Flask.teardown_appcontext`
+when the application context is popped.
+
+The following signals are sent: :data:`appcontext_pushed`,
+:data:`appcontext_tearing_down`, and :data:`appcontext_popped`.
--- a/_build/_sources/async-await.rst.txt
+++ b/_build/_sources/async-await.rst.txt
@ -0,0 +1,125 @@
+.. _async_await:
+
+Using ``async`` and ``await``
+=============================
+
+.. versionadded:: 2.0
+
+Routes, error handlers, before request, after request, and teardown
+functions can all be coroutine functions if Flask is installed with the
+``async`` extra (``pip install flask[async]``). This allows views to be
+defined with ``async def`` and use ``await``.
+
+.. code-block:: python
+
+    @app.route("/get-data")
+    async def get_data():
+        data = await async_db_query(...)
+        return jsonify(data)
+
+Pluggable class-based views also support handlers that are implemented as
+coroutines. This applies to the :meth:`~flask.views.View.dispatch_request`
+method in views that inherit from the :class:`flask.views.View` class, as
+well as all the HTTP method handlers in views that inherit from the
+:class:`flask.views.MethodView` class.
+
+.. admonition:: Using ``async`` with greenlet
+
+    When using gevent or eventlet to serve an application or patch the
+    runtime, greenlet>=1.0 is required. When using PyPy, PyPy>=7.3.7 is
+    required.
+
+
+Performance
+-----------
+
+Async functions require an event loop to run. Flask, as a WSGI
+application, uses one worker to handle one request/response cycle.
+When a request comes in to an async view, Flask will start an event loop
+in a thread, run the view function there, then return the result.
+
+Each request still ties up one worker, even for async views. The upside
+is that you can run async code within a view, for example to make
+multiple concurrent database queries, HTTP requests to an external API,
+etc. However, the number of requests your application can handle at one
+time will remain the same.
+
+**Async is not inherently faster than sync code.** Async is beneficial
+when performing concurrent IO-bound tasks, but will probably not improve
+CPU-bound tasks. Traditional Flask views will still be appropriate for
+most use cases, but Flask's async support enables writing and using
+code that wasn't possible natively before.
+
+
+Background tasks
+----------------
+
+Async functions will run in an event loop until they complete, at
+which stage the event loop will stop. This means any additional
+spawned tasks that haven't completed when the async function completes
+will be cancelled. Therefore you cannot spawn background tasks, for
+example via ``asyncio.create_task``.
+
+If you wish to use background tasks it is best to use a task queue to
+trigger background work, rather than spawn tasks in a view
+function. With that in mind you can spawn asyncio tasks by serving
+Flask with an ASGI server and utilising the asgiref WsgiToAsgi adapter
+as described in :doc:`deploying/asgi`. This works as the adapter creates
+an event loop that runs continually.
+
+
+When to use Quart instead
+-------------------------
+
+Flask's async support is less performant than async-first frameworks due
+to the way it is implemented. If you have a mainly async codebase it
+would make sense to consider `Quart`_. Quart is a reimplementation of
+Flask based on the `ASGI`_ standard instead of WSGI. This allows it to
+handle many concurrent requests, long running requests, and websockets
+without requiring multiple worker processes or threads.
+
+It has also already been possible to run Flask with Gevent or Eventlet
+to get many of the benefits of async request handling. These libraries
+patch low-level Python functions to accomplish this, whereas ``async``/
+``await`` and ASGI use standard, modern Python capabilities. Deciding
+whether you should use Flask, Quart, or something else is ultimately up
+to understanding the specific needs of your project.
+
+.. _Quart: https://github.com/pallets/quart
+.. _ASGI: https://asgi.readthedocs.io/en/latest/
+
+
+Extensions
+----------
+
+Flask extensions predating Flask's async support do not expect async views.
+If they provide decorators to add functionality to views, those will probably
+not work with async views because they will not await the function or be
+awaitable. Other functions they provide will not be awaitable either and
+will probably be blocking if called within an async view.
+
+Extension authors can support async functions by utilising the
+:meth:`flask.Flask.ensure_sync` method. For example, if the extension
+provides a view function decorator add ``ensure_sync`` before calling
+the decorated function,
+
+.. code-block:: python
+
+    def extension(func):
+        @wraps(func)
+        def wrapper(*args, **kwargs):
+            ...  # Extension logic
+            return current_app.ensure_sync(func)(*args, **kwargs)
+
+        return wrapper
+
+Check the changelog of the extension you want to use to see if they've
+implemented async support, or make a feature request or PR to them.
+
+
+Other event loops
+-----------------
+
+At the moment Flask only supports :mod:`asyncio`. It's possible to
+override :meth:`flask.Flask.ensure_sync` to change how async functions
+are wrapped to use a different library.
--- a/_build/_sources/blueprints.rst.txt
+++ b/_build/_sources/blueprints.rst.txt
@ -0,0 +1,315 @@
+Modular Applications with Blueprints
+====================================
+
+.. currentmodule:: flask
+
+.. versionadded:: 0.7
+
+Flask uses a concept of *blueprints* for making application components and
+supporting common patterns within an application or across applications.
+Blueprints can greatly simplify how large applications work and provide a
+central means for Flask extensions to register operations on applications.
+A :class:`Blueprint` object works similarly to a :class:`Flask`
+application object, but it is not actually an application.  Rather it is a
+*blueprint* of how to construct or extend an application.
+
+Why Blueprints?
+---------------
+
+Blueprints in Flask are intended for these cases:
+
+* Factor an application into a set of blueprints.  This is ideal for
+  larger applications; a project could instantiate an application object,
+  initialize several extensions, and register a collection of blueprints.
+* Register a blueprint on an application at a URL prefix and/or subdomain.
+  Parameters in the URL prefix/subdomain become common view arguments
+  (with defaults) across all view functions in the blueprint.
+* Register a blueprint multiple times on an application with different URL
+  rules.
+* Provide template filters, static files, templates, and other utilities
+  through blueprints.  A blueprint does not have to implement applications
+  or view functions.
+* Register a blueprint on an application for any of these cases when
+  initializing a Flask extension.
+
+A blueprint in Flask is not a pluggable app because it is not actually an
+application -- it's a set of operations which can be registered on an
+application, even multiple times.  Why not have multiple application
+objects?  You can do that (see :doc:`/patterns/appdispatch`), but your
+applications will have separate configs and will be managed at the WSGI
+layer.
+
+Blueprints instead provide separation at the Flask level, share
+application config, and can change an application object as necessary with
+being registered. The downside is that you cannot unregister a blueprint
+once an application was created without having to destroy the whole
+application object.
+
+The Concept of Blueprints
+-------------------------
+
+The basic concept of blueprints is that they record operations to execute
+when registered on an application.  Flask associates view functions with
+blueprints when dispatching requests and generating URLs from one endpoint
+to another.
+
+My First Blueprint
+------------------
+
+This is what a very basic blueprint looks like.  In this case we want to
+implement a blueprint that does simple rendering of static templates::
+
+    from flask import Blueprint, render_template, abort
+    from jinja2 import TemplateNotFound
+
+    simple_page = Blueprint('simple_page', __name__,
+                            template_folder='templates')
+
+    @simple_page.route('/', defaults={'page': 'index'})
+    @simple_page.route('/<page>')
+    def show(page):
+        try:
+            return render_template(f'pages/{page}.html')
+        except TemplateNotFound:
+            abort(404)
+
+When you bind a function with the help of the ``@simple_page.route``
+decorator, the blueprint will record the intention of registering the
+function ``show`` on the application when it's later registered.
+Additionally it will prefix the endpoint of the function with the
+name of the blueprint which was given to the :class:`Blueprint`
+constructor (in this case also ``simple_page``). The blueprint's name
+does not modify the URL, only the endpoint.
+
+Registering Blueprints
+----------------------
+
+So how do you register that blueprint?  Like this::
+
+    from flask import Flask
+    from yourapplication.simple_page import simple_page
+
+    app = Flask(__name__)
+    app.register_blueprint(simple_page)
+
+If you check the rules registered on the application, you will find
+these::
+
+    >>> app.url_map
+    Map([<Rule '/static/<filename>' (HEAD, OPTIONS, GET) -> static>,
+     <Rule '/<page>' (HEAD, OPTIONS, GET) -> simple_page.show>,
+     <Rule '/' (HEAD, OPTIONS, GET) -> simple_page.show>])
+
+The first one is obviously from the application itself for the static
+files.  The other two are for the `show` function of the ``simple_page``
+blueprint.  As you can see, they are also prefixed with the name of the
+blueprint and separated by a dot (``.``).
+
+Blueprints however can also be mounted at different locations::
+
+    app.register_blueprint(simple_page, url_prefix='/pages')
+
+And sure enough, these are the generated rules::
+
+    >>> app.url_map
+    Map([<Rule '/static/<filename>' (HEAD, OPTIONS, GET) -> static>,
+     <Rule '/pages/<page>' (HEAD, OPTIONS, GET) -> simple_page.show>,
+     <Rule '/pages/' (HEAD, OPTIONS, GET) -> simple_page.show>])
+
+On top of that you can register blueprints multiple times though not every
+blueprint might respond properly to that.  In fact it depends on how the
+blueprint is implemented if it can be mounted more than once.
+
+Nesting Blueprints
+------------------
+
+It is possible to register a blueprint on another blueprint.
+
+.. code-block:: python
+
+    parent = Blueprint('parent', __name__, url_prefix='/parent')
+    child = Blueprint('child', __name__, url_prefix='/child')
+    parent.register_blueprint(child)
+    app.register_blueprint(parent)
+
+The child blueprint will gain the parent's name as a prefix to its
+name, and child URLs will be prefixed with the parent's URL prefix.
+
+.. code-block:: python
+
+    url_for('parent.child.create')
+    /parent/child/create
+
+In addition a child blueprint's will gain their parent's subdomain,
+with their subdomain as prefix if present i.e.
+
+.. code-block:: python
+
+    parent = Blueprint('parent', __name__, subdomain='parent')
+    child = Blueprint('child', __name__, subdomain='child')
+    parent.register_blueprint(child)
+    app.register_blueprint(parent)
+
+    url_for('parent.child.create', _external=True)
+    "child.parent.domain.tld"
+
+Blueprint-specific before request functions, etc. registered with the
+parent will trigger for the child. If a child does not have an error
+handler that can handle a given exception, the parent's will be tried.
+
+
+Blueprint Resources
+-------------------
+
+Blueprints can provide resources as well.  Sometimes you might want to
+introduce a blueprint only for the resources it provides.
+
+Blueprint Resource Folder
+`````````````````````````
+
+Like for regular applications, blueprints are considered to be contained
+in a folder.  While multiple blueprints can originate from the same folder,
+it does not have to be the case and it's usually not recommended.
+
+The folder is inferred from the second argument to :class:`Blueprint` which
+is usually `__name__`.  This argument specifies what logical Python
+module or package corresponds to the blueprint.  If it points to an actual
+Python package that package (which is a folder on the filesystem) is the
+resource folder.  If it's a module, the package the module is contained in
+will be the resource folder.  You can access the
+:attr:`Blueprint.root_path` property to see what the resource folder is::
+
+    >>> simple_page.root_path
+    '/Users/username/TestProject/yourapplication'
+
+To quickly open sources from this folder you can use the
+:meth:`~Blueprint.open_resource` function::
+
+    with simple_page.open_resource('static/style.css') as f:
+        code = f.read()
+
+Static Files
+````````````
+
+A blueprint can expose a folder with static files by providing the path
+to the folder on the filesystem with the ``static_folder`` argument.
+It is either an absolute path or relative to the blueprint's location::
+
+    admin = Blueprint('admin', __name__, static_folder='static')
+
+By default the rightmost part of the path is where it is exposed on the
+web. This can be changed with the ``static_url_path`` argument. Because the
+folder is called ``static`` here it will be available at the
+``url_prefix`` of the blueprint + ``/static``. If the blueprint
+has the prefix ``/admin``, the static URL will be ``/admin/static``.
+
+The endpoint is named ``blueprint_name.static``. You can generate URLs
+to it with :func:`url_for` like you would with the static folder of the
+application::
+
+    url_for('admin.static', filename='style.css')
+
+However, if the blueprint does not have a ``url_prefix``, it is not
+possible to access the blueprint's static folder. This is because the
+URL would be ``/static`` in this case, and the application's ``/static``
+route takes precedence. Unlike template folders, blueprint static
+folders are not searched if the file does not exist in the application
+static folder.
+
+Templates
+`````````
+
+If you want the blueprint to expose templates you can do that by providing
+the `template_folder` parameter to the :class:`Blueprint` constructor::
+
+    admin = Blueprint('admin', __name__, template_folder='templates')
+
+For static files, the path can be absolute or relative to the blueprint
+resource folder.
+
+The template folder is added to the search path of templates but with a lower
+priority than the actual application's template folder. That way you can
+easily override templates that a blueprint provides in the actual application.
+This also means that if you don't want a blueprint template to be accidentally
+overridden, make sure that no other blueprint or actual application template
+has the same relative path. When multiple blueprints provide the same relative
+template path the first blueprint registered takes precedence over the others.
+
+
+So if you have a blueprint in the folder ``yourapplication/admin`` and you
+want to render the template ``'admin/index.html'`` and you have provided
+``templates`` as a `template_folder` you will have to create a file like
+this: :file:`yourapplication/admin/templates/admin/index.html`. The reason
+for the extra ``admin`` folder is to avoid getting our template overridden
+by a template named ``index.html`` in the actual application template
+folder.
+
+To further reiterate this: if you have a blueprint named ``admin`` and you
+want to render a template called :file:`index.html` which is specific to this
+blueprint, the best idea is to lay out your templates like this::
+
+    yourpackage/
+        blueprints/
+            admin/
+                templates/
+                    admin/
+                        index.html
+                __init__.py
+
+And then when you want to render the template, use :file:`admin/index.html` as
+the name to look up the template by.  If you encounter problems loading
+the correct templates enable the ``EXPLAIN_TEMPLATE_LOADING`` config
+variable which will instruct Flask to print out the steps it goes through
+to locate templates on every ``render_template`` call.
+
+Building URLs
+-------------
+
+If you want to link from one page to another you can use the
+:func:`url_for` function just like you normally would do just that you
+prefix the URL endpoint with the name of the blueprint and a dot (``.``)::
+
+    url_for('admin.index')
+
+Additionally if you are in a view function of a blueprint or a rendered
+template and you want to link to another endpoint of the same blueprint,
+you can use relative redirects by prefixing the endpoint with a dot only::
+
+    url_for('.index')
+
+This will link to ``admin.index`` for instance in case the current request
+was dispatched to any other admin blueprint endpoint.
+
+
+Blueprint Error Handlers
+------------------------
+
+Blueprints support the ``errorhandler`` decorator just like the :class:`Flask`
+application object, so it is easy to make Blueprint-specific custom error
+pages.
+
+Here is an example for a "404 Page Not Found" exception::
+
+    @simple_page.errorhandler(404)
+    def page_not_found(e):
+        return render_template('pages/404.html')
+
+Most errorhandlers will simply work as expected; however, there is a caveat
+concerning handlers for 404 and 405 exceptions.  These errorhandlers are only
+invoked from an appropriate ``raise`` statement or a call to ``abort`` in another
+of the blueprint's view functions; they are not invoked by, e.g., an invalid URL
+access.  This is because the blueprint does not "own" a certain URL space, so
+the application instance has no way of knowing which blueprint error handler it
+should run if given an invalid URL.  If you would like to execute different
+handling strategies for these errors based on URL prefixes, they may be defined
+at the application level using the ``request`` proxy object::
+
+    @app.errorhandler(404)
+    @app.errorhandler(405)
+    def _handle_api_error(ex):
+        if request.path.startswith('/api/'):
+            return jsonify(error=str(ex)), ex.code
+        else:
+            return ex
+
+See :doc:`/errorhandling`.
--- a/_build/_sources/changes.rst.txt
+++ b/_build/_sources/changes.rst.txt
@ -0,0 +1,4 @@
+Changes
+=======
+
+.. include:: ../CHANGES.rst
--- a/_build/_sources/cli.rst.txt
+++ b/_build/_sources/cli.rst.txt
@ -0,0 +1,556 @@
+.. currentmodule:: flask
+
+Command Line Interface
+======================
+
+Installing Flask installs the ``flask`` script, a `Click`_ command line
+interface, in your virtualenv. Executed from the terminal, this script gives
+access to built-in, extension, and application-defined commands. The ``--help``
+option will give more information about any commands and options.
+
+.. _Click: https://click.palletsprojects.com/
+
+
+Application Discovery
+---------------------
+
+The ``flask`` command is installed by Flask, not your application; it must be
+told where to find your application in order to use it. The ``--app``
+option is used to specify how to load the application.
+
+While ``--app`` supports a variety of options for specifying your
+application, most use cases should be simple. Here are the typical values:
+
+(nothing)
+    The name "app" or "wsgi" is imported (as a ".py" file, or package),
+    automatically detecting an app (``app`` or ``application``) or
+    factory (``create_app`` or ``make_app``).
+
+``--app hello``
+    The given name is imported, automatically detecting an app (``app``
+    or ``application``) or factory (``create_app`` or ``make_app``).
+
+----
+
+``--app`` has three parts: an optional path that sets the current working
+directory, a Python file or dotted import path, and an optional variable
+name of the instance or factory. If the name is a factory, it can optionally
+be followed by arguments in parentheses. The following values demonstrate these
+parts:
+
+``--app src/hello``
+    Sets the current working directory to ``src`` then imports ``hello``.
+
+``--app hello.web``
+    Imports the path ``hello.web``.
+
+``--app hello:app2``
+    Uses the ``app2`` Flask instance in ``hello``.
+
+``--app 'hello:create_app("dev")'``
+    The ``create_app`` factory in ``hello`` is called with the string ``'dev'``
+    as the argument.
+
+If ``--app`` is not set, the command will try to import "app" or
+"wsgi" (as a ".py" file, or package) and try to detect an application
+instance or factory.
+
+Within the given import, the command looks for an application instance named
+``app`` or ``application``, then any application instance. If no instance is
+found, the command looks for a factory function named ``create_app`` or
+``make_app`` that returns an instance.
+
+If parentheses follow the factory name, their contents are parsed as
+Python literals and passed as arguments and keyword arguments to the
+function. This means that strings must still be in quotes.
+
+
+Run the Development Server
+--------------------------
+
+The :func:`run <cli.run_command>` command will start the development server. It
+replaces the :meth:`Flask.run` method in most cases. ::
+
+    $ flask --app hello run
+     * Serving Flask app "hello"
+     * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)
+
+.. warning:: Do not use this command to run your application in production.
+    Only use the development server during development. The development server
+    is provided for convenience, but is not designed to be particularly secure,
+    stable, or efficient. See :doc:`/deploying/index` for how to run in production.
+
+If another program is already using port 5000, you'll see
+``OSError: [Errno 98]`` or ``OSError: [WinError 10013]`` when the
+server tries to start. See :ref:`address-already-in-use` for how to
+handle that.
+
+
+Debug Mode
+~~~~~~~~~~
+
+In debug mode, the ``flask run`` command will enable the interactive debugger and the
+reloader by default, and make errors easier to see and debug. To enable debug mode, use
+the ``--debug`` option.
+
+.. code-block:: console
+
+     $ flask --app hello run --debug
+      * Serving Flask app "hello"
+      * Debug mode: on
+      * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)
+      * Restarting with inotify reloader
+      * Debugger is active!
+      * Debugger PIN: 223-456-919
+
+The ``--debug`` option can also be passed to the top level ``flask`` command to enable
+debug mode for any command. The following two ``run`` calls are equivalent.
+
+.. code-block:: console
+
+    $ flask --app hello --debug run
+    $ flask --app hello run --debug
+
+
+Watch and Ignore Files with the Reloader
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When using debug mode, the reloader will trigger whenever your Python code or imported
+modules change. The reloader can watch additional files with the ``--extra-files``
+option. Multiple paths are separated with ``:``, or ``;`` on Windows.
+
+.. code-block:: text
+
+    $ flask run --extra-files file1:dirA/file2:dirB/
+     * Running on http://127.0.0.1:8000/
+     * Detected change in '/path/to/file1', reloading
+
+The reloader can also ignore files using :mod:`fnmatch` patterns with the
+``--exclude-patterns`` option. Multiple patterns are separated with ``:``, or ``;`` on
+Windows.
+
+
+Open a Shell
+------------
+
+To explore the data in your application, you can start an interactive Python
+shell with the :func:`shell <cli.shell_command>` command. An application
+context will be active, and the app instance will be imported. ::
+
+    $ flask shell
+    Python 3.10.0 (default, Oct 27 2021, 06:59:51) [GCC 11.1.0] on linux
+    App: example [production]
+    Instance: /home/david/Projects/pallets/flask/instance
+    >>>
+
+Use :meth:`~Flask.shell_context_processor` to add other automatic imports.
+
+
+.. _dotenv:
+
+Environment Variables From dotenv
+---------------------------------
+
+The ``flask`` command supports setting any option for any command with
+environment variables. The variables are named like ``FLASK_OPTION`` or
+``FLASK_COMMAND_OPTION``, for example ``FLASK_APP`` or
+``FLASK_RUN_PORT``.
+
+Rather than passing options every time you run a command, or environment
+variables every time you open a new terminal, you can use Flask's dotenv
+support to set environment variables automatically.
+
+If `python-dotenv`_ is installed, running the ``flask`` command will set
+environment variables defined in the files ``.env`` and ``.flaskenv``.
+You can also specify an extra file to load with the ``--env-file``
+option. Dotenv files can be used to avoid having to set ``--app`` or
+``FLASK_APP`` manually, and to set configuration using environment
+variables similar to how some deployment services work.
+
+Variables set on the command line are used over those set in :file:`.env`,
+which are used over those set in :file:`.flaskenv`. :file:`.flaskenv` should be
+used for public variables, such as ``FLASK_APP``, while :file:`.env` should not
+be committed to your repository so that it can set private variables.
+
+Directories are scanned upwards from the directory you call ``flask``
+from to locate the files.
+
+The files are only loaded by the ``flask`` command or calling
+:meth:`~Flask.run`. If you would like to load these files when running in
+production, you should call :func:`~cli.load_dotenv` manually.
+
+.. _python-dotenv: https://github.com/theskumar/python-dotenv#readme
+
+
+Setting Command Options
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Click is configured to load default values for command options from
+environment variables. The variables use the pattern
+``FLASK_COMMAND_OPTION``. For example, to set the port for the run
+command, instead of ``flask run --port 8000``:
+
+.. tabs::
+
+   .. group-tab:: Bash
+
+      .. code-block:: text
+
+         $ export FLASK_RUN_PORT=8000
+         $ flask run
+          * Running on http://127.0.0.1:8000/
+
+   .. group-tab:: Fish
+
+      .. code-block:: text
+
+         $ set -x FLASK_RUN_PORT 8000
+         $ flask run
+          * Running on http://127.0.0.1:8000/
+
+   .. group-tab:: CMD
+
+      .. code-block:: text
+
+         > set FLASK_RUN_PORT=8000
+         > flask run
+          * Running on http://127.0.0.1:8000/
+
+   .. group-tab:: Powershell
+
+      .. code-block:: text
+
+         > $env:FLASK_RUN_PORT = 8000
+         > flask run
+          * Running on http://127.0.0.1:8000/
+
+These can be added to the ``.flaskenv`` file just like ``FLASK_APP`` to
+control default command options.
+
+
+Disable dotenv
+~~~~~~~~~~~~~~
+
+The ``flask`` command will show a message if it detects dotenv files but
+python-dotenv is not installed.
+
+.. code-block:: bash
+
+    $ flask run
+     * Tip: There are .env files present. Do "pip install python-dotenv" to use them.
+
+You can tell Flask not to load dotenv files even when python-dotenv is
+installed by setting the ``FLASK_SKIP_DOTENV`` environment variable.
+This can be useful if you want to load them manually, or if you're using
+a project runner that loads them already. Keep in mind that the
+environment variables must be set before the app loads or it won't
+configure as expected.
+
+.. tabs::
+
+   .. group-tab:: Bash
+
+      .. code-block:: text
+
+         $ export FLASK_SKIP_DOTENV=1
+         $ flask run
+
+   .. group-tab:: Fish
+
+      .. code-block:: text
+
+         $ set -x FLASK_SKIP_DOTENV 1
+         $ flask run
+
+   .. group-tab:: CMD
+
+      .. code-block:: text
+
+         > set FLASK_SKIP_DOTENV=1
+         > flask run
+
+   .. group-tab:: Powershell
+
+      .. code-block:: text
+
+         > $env:FLASK_SKIP_DOTENV = 1
+         > flask run
+
+
+Environment Variables From virtualenv
+-------------------------------------
+
+If you do not want to install dotenv support, you can still set environment
+variables by adding them to the end of the virtualenv's :file:`activate`
+script. Activating the virtualenv will set the variables.
+
+.. tabs::
+
+   .. group-tab:: Bash
+
+      Unix Bash, :file:`.venv/bin/activate`::
+
+          $ export FLASK_APP=hello
+
+   .. group-tab:: Fish
+
+      Fish, :file:`.venv/bin/activate.fish`::
+
+          $ set -x FLASK_APP hello
+
+   .. group-tab:: CMD
+
+      Windows CMD, :file:`.venv\\Scripts\\activate.bat`::
+
+          > set FLASK_APP=hello
+
+   .. group-tab:: Powershell
+
+      Windows Powershell, :file:`.venv\\Scripts\\activate.ps1`::
+
+          > $env:FLASK_APP = "hello"
+
+It is preferred to use dotenv support over this, since :file:`.flaskenv` can be
+committed to the repository so that it works automatically wherever the project
+is checked out.
+
+
+Custom Commands
+---------------
+
+The ``flask`` command is implemented using `Click`_. See that project's
+documentation for full information about writing commands.
+
+This example adds the command ``create-user`` that takes the argument
+``name``. ::
+
+    import click
+    from flask import Flask
+
+    app = Flask(__name__)
+
+    @app.cli.command("create-user")
+    @click.argument("name")
+    def create_user(name):
+        ...
+
+::
+
+    $ flask create-user admin
+
+This example adds the same command, but as ``user create``, a command in a
+group. This is useful if you want to organize multiple related commands. ::
+
+    import click
+    from flask import Flask
+    from flask.cli import AppGroup
+
+    app = Flask(__name__)
+    user_cli = AppGroup('user')
+
+    @user_cli.command('create')
+    @click.argument('name')
+    def create_user(name):
+        ...
+
+    app.cli.add_command(user_cli)
+
+::
+
+    $ flask user create demo
+
+See :ref:`testing-cli` for an overview of how to test your custom
+commands.
+
+
+Registering Commands with Blueprints
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If your application uses blueprints, you can optionally register CLI
+commands directly onto them. When your blueprint is registered onto your
+application, the associated commands will be available to the ``flask``
+command. By default, those commands will be nested in a group matching
+the name of the blueprint.
+
+.. code-block:: python
+
+    from flask import Blueprint
+
+    bp = Blueprint('students', __name__)
+
+    @bp.cli.command('create')
+    @click.argument('name')
+    def create(name):
+        ...
+
+    app.register_blueprint(bp)
+
+.. code-block:: text
+
+    $ flask students create alice
+
+You can alter the group name by specifying the ``cli_group`` parameter
+when creating the :class:`Blueprint` object, or later with
+:meth:`app.register_blueprint(bp, cli_group='...') <Flask.register_blueprint>`.
+The following are equivalent:
+
+.. code-block:: python
+
+    bp = Blueprint('students', __name__, cli_group='other')
+    # or
+    app.register_blueprint(bp, cli_group='other')
+
+.. code-block:: text
+
+    $ flask other create alice
+
+Specifying ``cli_group=None`` will remove the nesting and merge the
+commands directly to the application's level:
+
+.. code-block:: python
+
+    bp = Blueprint('students', __name__, cli_group=None)
+    # or
+    app.register_blueprint(bp, cli_group=None)
+
+.. code-block:: text
+
+    $ flask create alice
+
+
+Application Context
+~~~~~~~~~~~~~~~~~~~
+
+Commands added using the Flask app's :attr:`~Flask.cli` or
+:class:`~flask.cli.FlaskGroup` :meth:`~cli.AppGroup.command` decorator
+will be executed with an application context pushed, so your custom
+commands and parameters have access to the app and its configuration. The
+:func:`~cli.with_appcontext` decorator can be used to get the same
+behavior, but is not needed in most cases.
+
+.. code-block:: python
+
+    import click
+    from flask.cli import with_appcontext
+
+    @click.command()
+    @with_appcontext
+    def do_work():
+        ...
+
+    app.cli.add_command(do_work)
+
+
+Plugins
+-------
+
+Flask will automatically load commands specified in the ``flask.commands``
+`entry point`_. This is useful for extensions that want to add commands when
+they are installed. Entry points are specified in :file:`pyproject.toml`:
+
+.. code-block:: toml
+
+    [project.entry-points."flask.commands"]
+    my-command = "my_extension.commands:cli"
+
+.. _entry point: https://packaging.python.org/tutorials/packaging-projects/#entry-points
+
+Inside :file:`my_extension/commands.py` you can then export a Click
+object::
+
+    import click
+
+    @click.command()
+    def cli():
+        ...
+
+Once that package is installed in the same virtualenv as your Flask project,
+you can run ``flask my-command`` to invoke the command.
+
+
+.. _custom-scripts:
+
+Custom Scripts
+--------------
+
+When you are using the app factory pattern, it may be more convenient to define
+your own Click script. Instead of using ``--app`` and letting Flask load
+your application, you can create your own Click object and export it as a
+`console script`_ entry point.
+
+Create an instance of :class:`~cli.FlaskGroup` and pass it the factory::
+
+    import click
+    from flask import Flask
+    from flask.cli import FlaskGroup
+
+    def create_app():
+        app = Flask('wiki')
+        # other setup
+        return app
+
+    @click.group(cls=FlaskGroup, create_app=create_app)
+    def cli():
+        """Management script for the Wiki application."""
+
+Define the entry point in :file:`pyproject.toml`:
+
+.. code-block:: toml
+
+    [project.scripts]
+    wiki = "wiki:cli"
+
+Install the application in the virtualenv in editable mode and the custom
+script is available. Note that you don't need to set ``--app``. ::
+
+    $ pip install -e .
+    $ wiki run
+
+.. admonition:: Errors in Custom Scripts
+
+    When using a custom script, if you introduce an error in your
+    module-level code, the reloader will fail because it can no longer
+    load the entry point.
+
+    The ``flask`` command, being separate from your code, does not have
+    this issue and is recommended in most cases.
+
+.. _console script: https://packaging.python.org/tutorials/packaging-projects/#console-scripts
+
+
+PyCharm Integration
+-------------------
+
+PyCharm Professional provides a special Flask run configuration to run the development
+server. For the Community Edition, and for other commands besides ``run``, you need to
+create a custom run configuration. These instructions should be similar for any other
+IDE you use.
+
+In PyCharm, with your project open, click on *Run* from the menu bar and go to *Edit
+Configurations*. You'll see a screen similar to this:
+
+.. image:: _static/pycharm-run-config.png
+    :align: center
+    :class: screenshot
+    :alt: Screenshot of PyCharm run configuration.
+
+Once you create a configuration for the ``flask run``, you can copy and change it to
+call any other command.
+
+Click the *+ (Add New Configuration)* button and select *Python*. Give the configuration
+a name such as "flask run".
+
+Click the *Script path* dropdown and change it to *Module name*, then input ``flask``.
+
+The *Parameters* field is set to the CLI command to execute along with any arguments.
+This example uses ``--app hello run --debug``, which will run the development server in
+debug mode. ``--app hello`` should be the import or file with your Flask app.
+
+If you installed your project as a package in your virtualenv, you may uncheck the
+*PYTHONPATH* options. This will more accurately match how you deploy later.
+
+Click *OK* to save and close the configuration. Select the configuration in the main
+PyCharm window and click the play button next to it to run the server.
+
+Now that you have a configuration for ``flask run``, you can copy that configuration and
+change the *Parameters* argument to run a different CLI command.
--- a/_build/_sources/config.rst.txt
+++ b/_build/_sources/config.rst.txt
@ -0,0 +1,836 @@
+Configuration Handling
+======================
+
+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 hard code the
+configuration in the code, which for many small applications is not
+actually that bad, but there are better ways.
+
+Independent of how you load your config, there is a config object
+available which holds the loaded configuration values:
+The :attr:`~flask.Flask.config` attribute of the :class:`~flask.Flask`
+object.  This is the place where Flask itself puts certain configuration
+values and also where extensions can put their configuration values.  But
+this is also where you can have your own configuration.
+
+
+Configuration Basics
+--------------------
+
+The :attr:`~flask.Flask.config` is actually a subclass of a dictionary and
+can be modified just like any dictionary::
+
+    app = Flask(__name__)
+    app.config['TESTING'] = True
+
+Certain configuration values are also forwarded to the
+:attr:`~flask.Flask` object so you can read and write them from there::
+
+    app.testing = True
+
+To update multiple keys at once you can use the :meth:`dict.update`
+method::
+
+    app.config.update(
+        TESTING=True,
+        SECRET_KEY='192b9bdd22ab9ed4d12e236c78afcb9a393ec15f71bbf5dc987d54727823bcbf'
+    )
+
+
+Debug Mode
+----------
+
+The :data:`DEBUG` config value is special because it may behave inconsistently if
+changed after the app has begun setting up. In order to set debug mode reliably, use the
+``--debug`` option on the ``flask`` or ``flask run`` command. ``flask run`` will use the
+interactive debugger and reloader by default in debug mode.
+
+.. code-block:: text
+
+    $ flask --app hello run --debug
+
+Using the option is recommended. While it is possible to set :data:`DEBUG` in your
+config or code, this is strongly discouraged. It can't be read early by the
+``flask run`` command, and some systems or extensions may have already configured
+themselves based on a previous value.
+
+
+Builtin Configuration Values
+----------------------------
+
+The following configuration values are used internally by Flask:
+
+.. py:data:: DEBUG
+
+    Whether debug mode is enabled. When using ``flask run`` to start the development
+    server, an interactive debugger will be shown for unhandled exceptions, and the
+    server will be reloaded when code changes. The :attr:`~flask.Flask.debug` attribute
+    maps to this config key. This is set with the ``FLASK_DEBUG`` environment variable.
+    It may not behave as expected if set in code.
+
+    **Do not enable debug mode when deploying in production.**
+
+    Default: ``False``
+
+.. py:data:: TESTING
+
+    Enable testing mode. Exceptions are propagated rather than handled by the
+    the app's error handlers. Extensions may also change their behavior to
+    facilitate easier testing. You should enable this in your own tests.
+
+    Default: ``False``
+
+.. py:data:: PROPAGATE_EXCEPTIONS
+
+    Exceptions are re-raised rather than being handled by the app's error
+    handlers. If not set, this is implicitly true if ``TESTING`` or ``DEBUG``
+    is enabled.
+
+    Default: ``None``
+
+.. py:data:: TRAP_HTTP_EXCEPTIONS
+
+    If there is no handler for an ``HTTPException``-type exception, re-raise it
+    to be handled by the interactive debugger instead of returning it as a
+    simple error response.
+
+    Default: ``False``
+
+.. py:data:: TRAP_BAD_REQUEST_ERRORS
+
+    Trying to access a key that doesn't exist from request dicts like ``args``
+    and ``form`` will return a 400 Bad Request error page. Enable this to treat
+    the error as an unhandled exception instead so that you get the interactive
+    debugger. This is a more specific version of ``TRAP_HTTP_EXCEPTIONS``. If
+    unset, it is enabled in debug mode.
+
+    Default: ``None``
+
+.. py:data:: SECRET_KEY
+
+    A secret key that will be used for securely signing the session cookie
+    and can be used for any other security related needs by extensions or your
+    application. It should be a long random ``bytes`` or ``str``. For
+    example, copy the output of this to your config::
+
+        $ python -c 'import secrets; print(secrets.token_hex())'
+        '192b9bdd22ab9ed4d12e236c78afcb9a393ec15f71bbf5dc987d54727823bcbf'
+
+    **Do not reveal the secret key when posting questions or committing code.**
+
+    Default: ``None``
+
+.. py:data:: SECRET_KEY_FALLBACKS
+
+    A list of old secret keys that can still be used for unsigning, most recent
+    first. This allows a project to implement key rotation without invalidating
+    active sessions or other recently-signed secrets.
+
+    Keys should be removed after an appropriate period of time, as checking each
+    additional key adds some overhead.
+
+    Flask's built-in secure cookie session supports this. Extensions that use
+    :data:`SECRET_KEY` may not support this yet.
+
+    Default: ``None``
+
+    .. versionadded:: 3.1
+
+.. py:data:: SESSION_COOKIE_NAME
+
+    The name of the session cookie. Can be changed in case you already have a
+    cookie with the same name.
+
+    Default: ``'session'``
+
+.. py:data:: SESSION_COOKIE_DOMAIN
+
+    The value of the ``Domain`` parameter on the session cookie. If not set, browsers
+    will only send the cookie to the exact domain it was set from. Otherwise, they
+    will send it to any subdomain of the given value as well.
+
+    Not setting this value is more restricted and secure than setting it.
+
+    Default: ``None``
+
+    .. warning::
+        If this is changed after the browser created a cookie is created with
+        one setting, it may result in another being created. Browsers may send
+        send both in an undefined order. In that case, you may want to change
+        :data:`SESSION_COOKIE_NAME` as well or otherwise invalidate old sessions.
+
+    .. versionchanged:: 2.3
+        Not set by default, does not fall back to ``SERVER_NAME``.
+
+.. py:data:: SESSION_COOKIE_PATH
+
+    The path that the session cookie will be valid for. If not set, the cookie
+    will be valid underneath ``APPLICATION_ROOT`` or ``/`` if that is not set.
+
+    Default: ``None``
+
+.. py:data:: SESSION_COOKIE_HTTPONLY
+
+    Browsers will not allow JavaScript access to cookies marked as "HTTP only"
+    for security.
+
+    Default: ``True``
+
+.. py:data:: SESSION_COOKIE_SECURE
+
+    Browsers will only send cookies with requests over HTTPS if the cookie is
+    marked "secure". The application must be served over HTTPS for this to make
+    sense.
+
+    Default: ``False``
+
+.. py:data:: SESSION_COOKIE_PARTITIONED
+
+    Browsers will send cookies based on the top-level document's domain, rather
+    than only the domain of the document setting the cookie. This prevents third
+    party cookies set in iframes from "leaking" between separate sites.
+
+    Browsers are beginning to disallow non-partitioned third party cookies, so
+    you need to mark your cookies partitioned if you expect them to work in such
+    embedded situations.
+
+    Enabling this implicitly enables :data:`SESSION_COOKIE_SECURE` as well, as
+    it is only valid when served over HTTPS.
+
+    Default: ``False``
+
+    .. versionadded:: 3.1
+
+.. py:data:: SESSION_COOKIE_SAMESITE
+
+    Restrict how cookies are sent with requests from external sites. Can
+    be set to ``'Lax'`` (recommended) or ``'Strict'``.
+    See :ref:`security-cookie`.
+
+    Default: ``None``
+
+    .. versionadded:: 1.0
+
+.. py:data:: PERMANENT_SESSION_LIFETIME
+
+    If ``session.permanent`` is true, the cookie's expiration will be set this
+    number of seconds in the future. Can either be a
+    :class:`datetime.timedelta` or an ``int``.
+
+    Flask's default cookie implementation validates that the cryptographic
+    signature is not older than this value.
+
+    Default: ``timedelta(days=31)`` (``2678400`` seconds)
+
+.. py:data:: SESSION_REFRESH_EACH_REQUEST
+
+    Control whether the cookie is sent with every response when
+    ``session.permanent`` is true. Sending the cookie every time (the default)
+    can more reliably keep the session from expiring, but uses more bandwidth.
+    Non-permanent sessions are not affected.
+
+    Default: ``True``
+
+.. py:data:: USE_X_SENDFILE
+
+    When serving files, set the ``X-Sendfile`` header instead of serving the
+    data with Flask. Some web servers, such as Apache, recognize this and serve
+    the data more efficiently. This only makes sense when using such a server.
+
+    Default: ``False``
+
+.. py:data:: SEND_FILE_MAX_AGE_DEFAULT
+
+    When serving files, set the cache control max age to this number of
+    seconds. Can be a :class:`datetime.timedelta` or an ``int``.
+    Override this value on a per-file basis using
+    :meth:`~flask.Flask.get_send_file_max_age` on the application or
+    blueprint.
+
+    If ``None``, ``send_file`` tells the browser to use conditional
+    requests will be used instead of a timed cache, which is usually
+    preferable.
+
+    Default: ``None``
+
+.. py:data:: TRUSTED_HOSTS
+
+    Validate :attr:`.Request.host` and other attributes that use it against
+    these trusted values. Raise a :exc:`~werkzeug.exceptions.SecurityError` if
+    the host is invalid, which results in a 400 error. If it is ``None``, all
+    hosts are valid. Each value is either an exact match, or can start with
+    a dot ``.`` to match any subdomain.
+
+    Validation is done during routing against this value. ``before_request`` and
+    ``after_request`` callbacks will still be called.
+
+    Default: ``None``
+
+    .. versionadded:: 3.1
+
+.. py:data:: SERVER_NAME
+
+    Inform the application what host and port it is bound to.
+
+    Must be set if ``subdomain_matching`` is enabled, to be able to extract the
+    subdomain from the request.
+
+    Must be set for ``url_for`` to generate external URLs outside of a
+    request context.
+
+    Default: ``None``
+
+    .. versionchanged:: 3.1
+        Does not restrict requests to only this domain, for both
+        ``subdomain_matching`` and ``host_matching``.
+
+    .. versionchanged:: 1.0
+        Does not implicitly enable ``subdomain_matching``.
+
+    .. versionchanged:: 2.3
+        Does not affect ``SESSION_COOKIE_DOMAIN``.
+
+.. py:data:: APPLICATION_ROOT
+
+    Inform the application what path it is mounted under by the application /
+    web server.  This is used for generating URLs outside the context of a
+    request (inside a request, the dispatcher is responsible for setting
+    ``SCRIPT_NAME`` instead; see :doc:`/patterns/appdispatch`
+    for examples of dispatch configuration).
+
+    Will be used for the session cookie path if ``SESSION_COOKIE_PATH`` is not
+    set.
+
+    Default: ``'/'``
+
+.. py:data:: PREFERRED_URL_SCHEME
+
+    Use this scheme for generating external URLs when not in a request context.
+
+    Default: ``'http'``
+
+.. py:data:: MAX_CONTENT_LENGTH
+
+    The maximum number of bytes that will be read during this request. If
+    this limit is exceeded, a 413 :exc:`~werkzeug.exceptions.RequestEntityTooLarge`
+    error is raised. If it is set to ``None``, no limit is enforced at the
+    Flask application level. However, if it is ``None`` and the request has no
+    ``Content-Length`` header and the WSGI server does not indicate that it
+    terminates the stream, then no data is read to avoid an infinite stream.
+
+    Each request defaults to this config. It can be set on a specific
+    :attr:`.Request.max_content_length` to apply the limit to that specific
+    view. This should be set appropriately based on an application's or view's
+    specific needs.
+
+    Default: ``None``
+
+    .. versionadded:: 0.6
+
+.. py:data:: MAX_FORM_MEMORY_SIZE
+
+    The maximum size in bytes any non-file form field may be in a
+    ``multipart/form-data`` body. If this limit is exceeded, a 413
+    :exc:`~werkzeug.exceptions.RequestEntityTooLarge` error is raised. If it is
+    set to ``None``, no limit is enforced at the Flask application level.
+
+    Each request defaults to this config. It can be set on a specific
+    :attr:`.Request.max_form_memory_parts` to apply the limit to that specific
+    view. This should be set appropriately based on an application's or view's
+    specific needs.
+
+    Default: ``500_000``
+
+    .. versionadded:: 3.1
+
+.. py:data:: MAX_FORM_PARTS
+
+    The maximum number of fields that may be present in a
+    ``multipart/form-data`` body. If this limit is exceeded, a 413
+    :exc:`~werkzeug.exceptions.RequestEntityTooLarge` error is raised. If it
+    is set to ``None``, no limit is enforced at the Flask application level.
+
+    Each request defaults to this config. It can be set on a specific
+    :attr:`.Request.max_form_parts` to apply the limit to that specific view.
+    This should be set appropriately based on an application's or view's
+    specific needs.
+
+    Default: ``1_000``
+
+    .. versionadded:: 3.1
+
+.. py:data:: TEMPLATES_AUTO_RELOAD
+
+    Reload templates when they are changed. If not set, it will be enabled in
+    debug mode.
+
+    Default: ``None``
+
+.. py:data:: EXPLAIN_TEMPLATE_LOADING
+
+    Log debugging information tracing how a template file was loaded. This can
+    be useful to figure out why a template was not loaded or the wrong file
+    appears to be loaded.
+
+    Default: ``False``
+
+.. py:data:: MAX_COOKIE_SIZE
+
+    Warn if cookie headers are larger than this many bytes. Defaults to
+    ``4093``. Larger cookies may be silently ignored by browsers. Set to
+    ``0`` to disable the warning.
+
+.. py:data:: PROVIDE_AUTOMATIC_OPTIONS
+
+    Set to ``False`` to disable the automatic addition of OPTIONS
+    responses. This can be overridden per route by altering the
+    ``provide_automatic_options`` attribute.
+
+.. versionadded:: 0.4
+   ``LOGGER_NAME``
+
+.. versionadded:: 0.5
+   ``SERVER_NAME``
+
+.. versionadded:: 0.6
+   ``MAX_CONTENT_LENGTH``
+
+.. versionadded:: 0.7
+   ``PROPAGATE_EXCEPTIONS``, ``PRESERVE_CONTEXT_ON_EXCEPTION``
+
+.. versionadded:: 0.8
+   ``TRAP_BAD_REQUEST_ERRORS``, ``TRAP_HTTP_EXCEPTIONS``,
+   ``APPLICATION_ROOT``, ``SESSION_COOKIE_DOMAIN``,
+   ``SESSION_COOKIE_PATH``, ``SESSION_COOKIE_HTTPONLY``,
+   ``SESSION_COOKIE_SECURE``
+
+.. versionadded:: 0.9
+   ``PREFERRED_URL_SCHEME``
+
+.. versionadded:: 0.10
+   ``JSON_AS_ASCII``, ``JSON_SORT_KEYS``, ``JSONIFY_PRETTYPRINT_REGULAR``
+
+.. versionadded:: 0.11
+   ``SESSION_REFRESH_EACH_REQUEST``, ``TEMPLATES_AUTO_RELOAD``,
+   ``LOGGER_HANDLER_POLICY``, ``EXPLAIN_TEMPLATE_LOADING``
+
+.. versionchanged:: 1.0
+    ``LOGGER_NAME`` and ``LOGGER_HANDLER_POLICY`` were removed. See
+    :doc:`/logging` for information about configuration.
+
+    Added :data:`ENV` to reflect the :envvar:`FLASK_ENV` environment
+    variable.
+
+    Added :data:`SESSION_COOKIE_SAMESITE` to control the session
+    cookie's ``SameSite`` option.
+
+    Added :data:`MAX_COOKIE_SIZE` to control a warning from Werkzeug.
+
+.. versionchanged:: 2.2
+    Removed ``PRESERVE_CONTEXT_ON_EXCEPTION``.
+
+.. versionchanged:: 2.3
+    ``JSON_AS_ASCII``, ``JSON_SORT_KEYS``, ``JSONIFY_MIMETYPE``, and
+    ``JSONIFY_PRETTYPRINT_REGULAR`` were removed. The default ``app.json`` provider has
+    equivalent attributes instead.
+
+.. versionchanged:: 2.3
+    ``ENV`` was removed.
+
+.. versionadded:: 3.10
+    Added :data:`PROVIDE_AUTOMATIC_OPTIONS` to control the default
+    addition of autogenerated OPTIONS responses.
+
+
+Configuring from Python Files
+-----------------------------
+
+Configuration becomes more useful if you can store it in a separate file, ideally
+located outside the actual application package. You can deploy your application, then
+separately configure it for the specific deployment.
+
+A common pattern is this::
+
+    app = Flask(__name__)
+    app.config.from_object('yourapplication.default_settings')
+    app.config.from_envvar('YOURAPPLICATION_SETTINGS')
+
+This first loads the configuration from the
+`yourapplication.default_settings` module and then overrides the values
+with the contents of the file the :envvar:`YOURAPPLICATION_SETTINGS`
+environment variable points to.  This environment variable can be set
+in the shell before starting the server:
+
+.. tabs::
+
+   .. group-tab:: Bash
+
+      .. code-block:: text
+
+         $ export YOURAPPLICATION_SETTINGS=/path/to/settings.cfg
+         $ flask run
+          * Running on http://127.0.0.1:5000/
+
+   .. group-tab:: Fish
+
+      .. code-block:: text
+
+         $ set -x YOURAPPLICATION_SETTINGS /path/to/settings.cfg
+         $ flask run
+          * Running on http://127.0.0.1:5000/
+
+   .. group-tab:: CMD
+
+      .. code-block:: text
+
+         > set YOURAPPLICATION_SETTINGS=\path\to\settings.cfg
+         > flask run
+          * Running on http://127.0.0.1:5000/
+
+   .. group-tab:: Powershell
+
+      .. code-block:: text
+
+         > $env:YOURAPPLICATION_SETTINGS = "\path\to\settings.cfg"
+         > flask run
+          * Running on http://127.0.0.1:5000/
+
+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 of a configuration file::
+
+    # Example configuration
+    SECRET_KEY = '192b9bdd22ab9ed4d12e236c78afcb9a393ec15f71bbf5dc987d54727823bcbf'
+
+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
+documentation.
+
+
+Configuring from Data Files
+---------------------------
+
+It is also possible to load configuration from a file in a format of
+your choice using :meth:`~flask.Config.from_file`. For example to load
+from a TOML file:
+
+.. code-block:: python
+
+    import tomllib
+    app.config.from_file("config.toml", load=tomllib.load, text=False)
+
+Or from a JSON file:
+
+.. code-block:: python
+
+    import json
+    app.config.from_file("config.json", load=json.load)
+
+
+Configuring from Environment Variables
+--------------------------------------
+
+In addition to pointing to configuration files using environment
+variables, you may find it useful (or necessary) to control your
+configuration values directly from the environment. Flask can be
+instructed to load all environment variables starting with a specific
+prefix into the config using :meth:`~flask.Config.from_prefixed_env`.
+
+Environment variables can be set in the shell before starting the
+server:
+
+.. tabs::
+
+   .. group-tab:: Bash
+
+      .. code-block:: text
+
+         $ export FLASK_SECRET_KEY="5f352379324c22463451387a0aec5d2f"
+         $ export FLASK_MAIL_ENABLED=false
+         $ flask run
+          * Running on http://127.0.0.1:5000/
+
+   .. group-tab:: Fish
+
+      .. code-block:: text
+
+         $ set -x FLASK_SECRET_KEY "5f352379324c22463451387a0aec5d2f"
+         $ set -x FLASK_MAIL_ENABLED false
+         $ flask run
+          * Running on http://127.0.0.1:5000/
+
+   .. group-tab:: CMD
+
+      .. code-block:: text
+
+         > set FLASK_SECRET_KEY="5f352379324c22463451387a0aec5d2f"
+         > set FLASK_MAIL_ENABLED=false
+         > flask run
+          * Running on http://127.0.0.1:5000/
+
+   .. group-tab:: Powershell
+
+      .. code-block:: text
+
+         > $env:FLASK_SECRET_KEY = "5f352379324c22463451387a0aec5d2f"
+         > $env:FLASK_MAIL_ENABLED = "false"
+         > flask run
+          * Running on http://127.0.0.1:5000/
+
+The variables can then be loaded and accessed via the config with a key
+equal to the environment variable name without the prefix i.e.
+
+.. code-block:: python
+
+    app.config.from_prefixed_env()
+    app.config["SECRET_KEY"]  # Is "5f352379324c22463451387a0aec5d2f"
+
+The prefix is ``FLASK_`` by default. This is configurable via the
+``prefix`` argument of :meth:`~flask.Config.from_prefixed_env`.
+
+Values will be parsed to attempt to convert them to a more specific type
+than strings. By default :func:`json.loads` is used, so any valid JSON
+value is possible, including lists and dicts. This is configurable via
+the ``loads`` argument of :meth:`~flask.Config.from_prefixed_env`.
+
+When adding a boolean value with the default JSON parsing, only "true"
+and "false", lowercase, are valid values. Keep in mind that any
+non-empty string is considered ``True`` by Python.
+
+It is possible to set keys in nested dictionaries by separating the
+keys with double underscore (``__``). Any intermediate keys that don't
+exist on the parent dict will be initialized to an empty dict.
+
+.. code-block:: text
+
+    $ export FLASK_MYAPI__credentials__username=user123
+
+.. code-block:: python
+
+    app.config["MYAPI"]["credentials"]["username"]  # Is "user123"
+
+On Windows, environment variable keys are always uppercase, therefore
+the above example would end up as ``MYAPI__CREDENTIALS__USERNAME``.
+
+For even more config loading features, including merging and
+case-insensitive Windows support, try a dedicated library such as
+Dynaconf_, which includes integration with Flask.
+
+.. _Dynaconf: https://www.dynaconf.com/
+
+
+Configuration Best Practices
+----------------------------
+
+The downside with the approach mentioned earlier is that it makes testing
+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
+    different configurations attached which makes unit testing a lot
+    easier.  You can use this to pass in configuration as needed.
+
+2.  Do not write code that needs the configuration at import time.  If you
+    limit yourself to request-only accesses to the configuration you can
+    reconfigure the object later on as needed.
+
+3.  Make sure to load the configuration very early on, so that
+    extensions can access the configuration when calling ``init_app``.
+
+
+.. _config-dev-prod:
+
+Development / Production
+------------------------
+
+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::
+
+    app = Flask(__name__)
+    app.config.from_object('yourapplication.default_settings')
+    app.config.from_envvar('YOURAPPLICATION_SETTINGS')
+
+Then you just have to add a separate :file:`config.py` file and export
+``YOURAPPLICATION_SETTINGS=/path/to/config.py`` and you are done.  However
+there are alternative ways as well.  For example you could use imports or
+subclassing.
+
+What is very popular in the Django world is to make the import explicit in
+the config file by adding ``from yourapplication.default_settings
+import *`` to the top of the file and then overriding the changes by hand.
+You could also inspect an environment variable like
+``YOURAPPLICATION_MODE`` and set that to `production`, `development` etc
+and import different hard-coded files based on that.
+
+An interesting pattern is also to use classes and inheritance for
+configuration::
+
+    class Config(object):
+        TESTING = False
+
+    class ProductionConfig(Config):
+        DATABASE_URI = 'mysql://user@localhost/foo'
+
+    class DevelopmentConfig(Config):
+        DATABASE_URI = "sqlite:////tmp/foo.db"
+
+    class TestingConfig(Config):
+        DATABASE_URI = 'sqlite:///:memory:'
+        TESTING = True
+
+To enable such a config you just have to call into
+:meth:`~flask.Config.from_object`::
+
+    app.config.from_object('configmodule.ProductionConfig')
+
+Note that :meth:`~flask.Config.from_object` does not instantiate the class
+object. If you need to instantiate the class, such as to access a property,
+then you must do so before calling :meth:`~flask.Config.from_object`::
+
+    from configmodule import ProductionConfig
+    app.config.from_object(ProductionConfig())
+
+    # Alternatively, import via string:
+    from werkzeug.utils import import_string
+    cfg = import_string('configmodule.ProductionConfig')()
+    app.config.from_object(cfg)
+
+Instantiating the configuration object allows you to use ``@property`` in
+your configuration classes::
+
+    class Config(object):
+        """Base config, uses staging database server."""
+        TESTING = False
+        DB_SERVER = '192.168.1.56'
+
+        @property
+        def DATABASE_URI(self):  # Note: all caps
+            return f"mysql://user@{self.DB_SERVER}/foo"
+
+    class ProductionConfig(Config):
+        """Uses production database server."""
+        DB_SERVER = '192.168.19.32'
+
+    class DevelopmentConfig(Config):
+        DB_SERVER = 'localhost'
+
+    class TestingConfig(Config):
+        DB_SERVER = 'localhost'
+        DATABASE_URI = 'sqlite:///:memory:'
+
+There are many different ways and it's up to you how you want to manage
+your configuration files.  However here a list of good recommendations:
+
+-   Keep a default configuration in version control.  Either populate the
+    config with this default configuration or import it in your own
+    configuration files before overriding values.
+-   Use an environment variable to switch between the configurations.
+    This can be done from outside the Python interpreter and makes
+    development and deployment much easier because you can quickly and
+    easily switch between different configs without having to touch the
+    code at all.  If you are working often on different projects you can
+    even create your own script for sourcing that activates a virtualenv
+    and exports the development configuration for you.
+-   Use a tool like `fabric`_ to push code and configuration separately
+    to the production server(s).
+
+.. _fabric: https://www.fabfile.org/
+
+
+.. _instance-folders:
+
+Instance Folders
+----------------
+
+.. versionadded:: 0.8
+
+Flask 0.8 introduces instance folders.  Flask for a long time made it
+possible to refer to paths relative to the application's folder directly
+(via :attr:`Flask.root_path`).  This was also how many developers loaded
+configurations stored next to the application.  Unfortunately however this
+only works well if applications are not packages in which case the root
+path refers to the contents of the package.
+
+With Flask 0.8 a new attribute was introduced:
+:attr:`Flask.instance_path`.  It refers to a new concept called the
+“instance folder”.  The instance folder is designed to not be under
+version control and be deployment specific.  It's the perfect place to
+drop things that either change at runtime or configuration files.
+
+You can either explicitly provide the path of the instance folder when
+creating the Flask application or you can let Flask autodetect the
+instance folder.  For explicit configuration use the `instance_path`
+parameter::
+
+    app = Flask(__name__, instance_path='/path/to/instance/folder')
+
+Please keep in mind that this path *must* be absolute when provided.
+
+If the `instance_path` parameter is not provided the following default
+locations are used:
+
+-   Uninstalled module::
+
+        /myapp.py
+        /instance
+
+-   Uninstalled package::
+
+        /myapp
+            /__init__.py
+        /instance
+
+-   Installed module or package::
+
+        $PREFIX/lib/pythonX.Y/site-packages/myapp
+        $PREFIX/var/myapp-instance
+
+    ``$PREFIX`` is the prefix of your Python installation.  This can be
+    ``/usr`` or the path to your virtualenv.  You can print the value of
+    ``sys.prefix`` to see what the prefix is set to.
+
+Since the config object provided loading of configuration files from
+relative filenames we made it possible to change the loading via filenames
+to be relative to the instance path if wanted.  The behavior of relative
+paths in config files can be flipped between “relative to the application
+root” (the default) to “relative to instance folder” via the
+`instance_relative_config` switch to the application constructor::
+
+    app = Flask(__name__, instance_relative_config=True)
+
+Here is a full example of how to configure Flask to preload the config
+from a module and then override the config from a file in the instance
+folder if it exists::
+
+    app = Flask(__name__, instance_relative_config=True)
+    app.config.from_object('yourapplication.default_settings')
+    app.config.from_pyfile('application.cfg', silent=True)
+
+The path to the instance folder can be found via the
+:attr:`Flask.instance_path`.  Flask also provides a shortcut to open a
+file from the instance folder with :meth:`Flask.open_instance_resource`.
+
+Example usage for both::
+
+    filename = os.path.join(app.instance_path, 'application.cfg')
+    with open(filename) as f:
+        config = f.read()
+
+    # or via open_instance_resource:
+    with app.open_instance_resource('application.cfg') as f:
+        config = f.read()
--- a/_build/_sources/contributing.rst.txt
+++ b/_build/_sources/contributing.rst.txt
@ -0,0 +1,8 @@
+Contributing
+============
+
+See the Pallets `detailed contributing documentation <_contrib>`_ for many ways
+to contribute, including reporting issues, requesting features, asking or
+answering questions, and making PRs.
+
+.. _contrib: https://palletsprojects.com/contributing/
--- a/_build/_sources/debugging.rst.txt
+++ b/_build/_sources/debugging.rst.txt
@ -0,0 +1,99 @@
+Debugging Application Errors
+============================
+
+
+In Production
+-------------
+
+**Do not run the development server, or enable the built-in debugger, in
+a production environment.** The debugger allows executing arbitrary
+Python code from the browser. It's protected by a pin, but that should
+not be relied on for security.
+
+Use an error logging tool, such as Sentry, as described in
+:ref:`error-logging-tools`, or enable logging and notifications as
+described in :doc:`/logging`.
+
+If you have access to the server, you could add some code to start an
+external debugger if ``request.remote_addr`` matches your IP. Some IDE
+debuggers also have a remote mode so breakpoints on the server can be
+interacted with locally. Only enable a debugger temporarily.
+
+
+The Built-In Debugger
+---------------------
+
+The built-in Werkzeug development server provides a debugger which shows
+an interactive traceback in the browser when an unhandled error occurs
+during a request. This debugger should only be used during development.
+
+.. image:: _static/debugger.png
+   :align: center
+   :class: screenshot
+   :alt: screenshot of debugger in action
+
+.. warning::
+
+    The debugger allows executing arbitrary Python code from the
+    browser. It is protected by a pin, but still represents a major
+    security risk. Do not run the development server or debugger in a
+    production environment.
+
+The debugger is enabled by default when the development server is run in debug mode.
+
+.. code-block:: text
+
+    $ flask --app hello run --debug
+
+When running from Python code, passing ``debug=True`` enables debug mode, which is
+mostly equivalent.
+
+.. code-block:: python
+
+    app.run(debug=True)
+
+:doc:`/server` and :doc:`/cli` have more information about running the debugger and
+debug mode. More information about the debugger can be found in the `Werkzeug
+documentation <https://werkzeug.palletsprojects.com/debug/>`__.
+
+
+External Debuggers
+------------------
+
+External debuggers, such as those provided by IDEs, can offer a more
+powerful debugging experience than the built-in debugger. They can also
+be used to step through code during a request before an error is raised,
+or if no error is raised. Some even have a remote mode so you can debug
+code running on another machine.
+
+When using an external debugger, the app should still be in debug mode, otherwise Flask
+turns unhandled errors into generic 500 error pages. However, the built-in debugger and
+reloader should be disabled so they don't interfere with the external debugger.
+
+.. code-block:: text
+
+    $ flask --app hello run --debug --no-debugger --no-reload
+
+When running from Python:
+
+.. code-block:: python
+
+    app.run(debug=True, use_debugger=False, use_reloader=False)
+
+Disabling these isn't required, an external debugger will continue to work with the
+following caveats.
+
+-   If the built-in debugger is not disabled, it will catch unhandled exceptions before
+    the external debugger can.
+-   If the reloader is not disabled, it could cause an unexpected reload if code changes
+    during a breakpoint.
+-   The development server will still catch unhandled exceptions if the built-in
+    debugger is disabled, otherwise it would crash on any error. If you want that (and
+    usually you don't) pass ``passthrough_errors=True`` to ``app.run``.
+
+    .. code-block:: python
+
+        app.run(
+            debug=True, passthrough_errors=True,
+            use_debugger=False, use_reloader=False
+        )
--- a/_build/_sources/deploying/apache-httpd.rst.txt
+++ b/_build/_sources/deploying/apache-httpd.rst.txt
@ -0,0 +1,66 @@
+Apache httpd
+============
+
+`Apache httpd`_ is a fast, production level HTTP server. When serving
+your application with one of the WSGI servers listed in :doc:`index`, it
+is often good or necessary to put a dedicated HTTP server in front of
+it. This "reverse proxy" can handle incoming requests, TLS, and other
+security and performance concerns better than the WSGI server.
+
+httpd can be installed using your system package manager, or a pre-built
+executable for Windows. Installing and running httpd itself is outside
+the scope of this doc. This page outlines the basics of configuring
+httpd to proxy your application. Be sure to read its documentation to
+understand what features are available.
+
+.. _Apache httpd: https://httpd.apache.org/
+
+
+Domain Name
+-----------
+
+Acquiring and configuring a domain name is outside the scope of this
+doc. In general, you will buy a domain name from a registrar, pay for
+server space with a hosting provider, and then point your registrar
+at the hosting provider's name servers.
+
+To simulate this, you can also edit your ``hosts`` file, located at
+``/etc/hosts`` on Linux. Add a line that associates a name with the
+local IP.
+
+Modern Linux systems may be configured to treat any domain name that
+ends with ``.localhost`` like this without adding it to the ``hosts``
+file.
+
+.. code-block:: python
+    :caption: ``/etc/hosts``
+
+    127.0.0.1 hello.localhost
+
+
+Configuration
+-------------
+
+The httpd configuration is located at ``/etc/httpd/conf/httpd.conf`` on
+Linux. It may be different depending on your operating system. Check the
+docs and look for ``httpd.conf``.
+
+Remove or comment out any existing ``DocumentRoot`` directive. Add the
+config lines below. We'll assume the WSGI server is listening locally at
+``http://127.0.0.1:8000``.
+
+.. code-block:: apache
+    :caption: ``/etc/httpd/conf/httpd.conf``
+
+    LoadModule proxy_module modules/mod_proxy.so
+    LoadModule proxy_http_module modules/mod_proxy_http.so
+    ProxyPass / http://127.0.0.1:8000/
+    RequestHeader set X-Forwarded-Proto http
+    RequestHeader set X-Forwarded-Prefix /
+
+The ``LoadModule`` lines might already exist. If so, make sure they are
+uncommented instead of adding them manually.
+
+Then :doc:`proxy_fix` so that your application uses the ``X-Forwarded``
+headers. ``X-Forwarded-For`` and ``X-Forwarded-Host`` are automatically
+set by ``ProxyPass``.
--- a/_build/_sources/deploying/asgi.rst.txt
+++ b/_build/_sources/deploying/asgi.rst.txt
@ -0,0 +1,27 @@
+ASGI
+====
+
+If you'd like to use an ASGI server you will need to utilise WSGI to
+ASGI middleware. The asgiref
+`WsgiToAsgi <https://github.com/django/asgiref#wsgi-to-asgi-adapter>`_
+adapter is recommended as it integrates with the event loop used for
+Flask's :ref:`async_await` support. You can use the adapter by
+wrapping the Flask app,
+
+.. code-block:: python
+
+    from asgiref.wsgi import WsgiToAsgi
+    from flask import Flask
+
+    app = Flask(__name__)
+
+    ...
+
+    asgi_app = WsgiToAsgi(app)
+
+and then serving the ``asgi_app`` with the ASGI server, e.g. using
+`Hypercorn <https://github.com/pgjones/hypercorn>`_,
+
+.. sourcecode:: text
+
+    $ hypercorn module:asgi_app
--- a/_build/_sources/deploying/eventlet.rst.txt
+++ b/_build/_sources/deploying/eventlet.rst.txt
@ -0,0 +1,80 @@
+eventlet
+========
+
+Prefer using :doc:`gunicorn` with eventlet workers rather than using
+`eventlet`_ directly. Gunicorn provides a much more configurable and
+production-tested server.
+
+`eventlet`_ allows writing asynchronous, coroutine-based code that looks
+like standard synchronous Python. It uses `greenlet`_ to enable task
+switching without writing ``async/await`` or using ``asyncio``.
+
+:doc:`gevent` is another library that does the same thing. Certain
+dependencies you have, or other considerations, may affect which of the
+two you choose to use.
+
+eventlet provides a WSGI server that can handle many connections at once
+instead of one per worker process. You must actually use eventlet in
+your own code to see any benefit to using the server.
+
+.. _eventlet: https://eventlet.net/
+.. _greenlet: https://greenlet.readthedocs.io/en/latest/
+
+
+Installing
+----------
+
+When using eventlet, greenlet>=1.0 is required, otherwise context locals
+such as ``request`` will not work as expected. When using PyPy,
+PyPy>=7.3.7 is required.
+
+Create a virtualenv, install your application, then install
+``eventlet``.
+
+.. code-block:: text
+
+    $ cd hello-app
+    $ python -m venv .venv
+    $ . .venv/bin/activate
+    $ pip install .  # install your application
+    $ pip install eventlet
+
+
+Running
+-------
+
+To use eventlet to serve your application, write a script that imports
+its ``wsgi.server``, as well as your app or app factory.
+
+.. code-block:: python
+    :caption: ``wsgi.py``
+
+    import eventlet
+    from eventlet import wsgi
+    from hello import create_app
+
+    app = create_app()
+    wsgi.server(eventlet.listen(("127.0.0.1", 8000)), app)
+
+.. code-block:: text
+
+    $ python wsgi.py
+    (x) wsgi starting up on http://127.0.0.1:8000
+
+
+Binding Externally
+------------------
+
+eventlet should not be run as root because it would cause your
+application code to run as root, which is not secure. However, this
+means it will not be possible to bind to port 80 or 443. Instead, a
+reverse proxy such as :doc:`nginx` or :doc:`apache-httpd` should be used
+in front of eventlet.
+
+You can bind to all external IPs on a non-privileged port by using
+``0.0.0.0`` in the server arguments shown in the previous section.
+Don't do this when using a reverse proxy setup, otherwise it will be
+possible to bypass the proxy.
+
+``0.0.0.0`` is not a valid address to navigate to, you'd use a specific
+IP address in your browser.
--- a/_build/_sources/deploying/gevent.rst.txt
+++ b/_build/_sources/deploying/gevent.rst.txt
@ -0,0 +1,80 @@
+gevent
+======
+
+Prefer using :doc:`gunicorn` or :doc:`uwsgi` with gevent workers rather
+than using `gevent`_ directly. Gunicorn and uWSGI provide much more
+configurable and production-tested servers.
+
+`gevent`_ allows writing asynchronous, coroutine-based code that looks
+like standard synchronous Python. It uses `greenlet`_ to enable task
+switching without writing ``async/await`` or using ``asyncio``.
+
+:doc:`eventlet` is another library that does the same thing. Certain
+dependencies you have, or other considerations, may affect which of the
+two you choose to use.
+
+gevent provides a WSGI server that can handle many connections at once
+instead of one per worker process. You must actually use gevent in your
+own code to see any benefit to using the server.
+
+.. _gevent: https://www.gevent.org/
+.. _greenlet: https://greenlet.readthedocs.io/en/latest/
+
+
+Installing
+----------
+
+When using gevent, greenlet>=1.0 is required, otherwise context locals
+such as ``request`` will not work as expected. When using PyPy,
+PyPy>=7.3.7 is required.
+
+Create a virtualenv, install your application, then install ``gevent``.
+
+.. code-block:: text
+
+    $ cd hello-app
+    $ python -m venv .venv
+    $ . .venv/bin/activate
+    $ pip install .  # install your application
+    $ pip install gevent
+
+
+Running
+-------
+
+To use gevent to serve your application, write a script that imports its
+``WSGIServer``, as well as your app or app factory.
+
+.. code-block:: python
+    :caption: ``wsgi.py``
+
+    from gevent.pywsgi import WSGIServer
+    from hello import create_app
+
+    app = create_app()
+    http_server = WSGIServer(("127.0.0.1", 8000), app)
+    http_server.serve_forever()
+
+.. code-block:: text
+
+    $ python wsgi.py
+
+No output is shown when the server starts.
+
+
+Binding Externally
+------------------
+
+gevent should not be run as root because it would cause your
+application code to run as root, which is not secure. However, this
+means it will not be possible to bind to port 80 or 443. Instead, a
+reverse proxy such as :doc:`nginx` or :doc:`apache-httpd` should be used
+in front of gevent.
+
+You can bind to all external IPs on a non-privileged port by using
+``0.0.0.0`` in the server arguments shown in the previous section. Don't
+do this when using a reverse proxy setup, otherwise it will be possible
+to bypass the proxy.
+
+``0.0.0.0`` is not a valid address to navigate to, you'd use a specific
+IP address in your browser.
--- a/_build/_sources/deploying/gunicorn.rst.txt
+++ b/_build/_sources/deploying/gunicorn.rst.txt
@ -0,0 +1,130 @@
+Gunicorn
+========
+
+`Gunicorn`_ is a pure Python WSGI server with simple configuration and
+multiple worker implementations for performance tuning.
+
+*   It tends to integrate easily with hosting platforms.
+*   It does not support Windows (but does run on WSL).
+*   It is easy to install as it does not require additional dependencies
+    or compilation.
+*   It has built-in async worker support using gevent or eventlet.
+
+This page outlines the basics of running Gunicorn. Be sure to read its
+`documentation`_ and use ``gunicorn --help`` to understand what features
+are available.
+
+.. _Gunicorn: https://gunicorn.org/
+.. _documentation: https://docs.gunicorn.org/
+
+
+Installing
+----------
+
+Gunicorn is easy to install, as it does not require external
+dependencies or compilation. It runs on Windows only under WSL.
+
+Create a virtualenv, install your application, then install
+``gunicorn``.
+
+.. code-block:: text
+
+    $ cd hello-app
+    $ python -m venv .venv
+    $ . .venv/bin/activate
+    $ pip install .  # install your application
+    $ pip install gunicorn
+
+
+Running
+-------
+
+The only required argument to Gunicorn tells it how to load your Flask
+application. The syntax is ``{module_import}:{app_variable}``.
+``module_import`` is the dotted import name to the module with your
+application. ``app_variable`` is the variable with the application. It
+can also be a function call (with any arguments) if you're using the
+app factory pattern.
+
+.. code-block:: text
+
+    # equivalent to 'from hello import app'
+    $ gunicorn -w 4 'hello:app'
+
+    # equivalent to 'from hello import create_app; create_app()'
+    $ gunicorn -w 4 'hello:create_app()'
+
+    Starting gunicorn 20.1.0
+    Listening at: http://127.0.0.1:8000 (x)
+    Using worker: sync
+    Booting worker with pid: x
+    Booting worker with pid: x
+    Booting worker with pid: x
+    Booting worker with pid: x
+
+The ``-w`` option specifies the number of processes to run; a starting
+value could be ``CPU * 2``. The default is only 1 worker, which is
+probably not what you want for the default worker type.
+
+Logs for each request aren't shown by default, only worker info and
+errors are shown. To show access logs on stdout, use the
+``--access-logfile=-`` option.
+
+
+Binding Externally
+------------------
+
+Gunicorn should not be run as root because it would cause your
+application code to run as root, which is not secure. However, this
+means it will not be possible to bind to port 80 or 443. Instead, a
+reverse proxy such as :doc:`nginx` or :doc:`apache-httpd` should be used
+in front of Gunicorn.
+
+You can bind to all external IPs on a non-privileged port using the
+``-b 0.0.0.0`` option. Don't do this when using a reverse proxy setup,
+otherwise it will be possible to bypass the proxy.
+
+.. code-block:: text
+
+    $ gunicorn -w 4 -b 0.0.0.0 'hello:create_app()'
+    Listening at: http://0.0.0.0:8000 (x)
+
+``0.0.0.0`` is not a valid address to navigate to, you'd use a specific
+IP address in your browser.
+
+
+Async with gevent or eventlet
+-----------------------------
+
+The default sync worker is appropriate for many use cases. If you need
+asynchronous support, Gunicorn provides workers using either `gevent`_
+or `eventlet`_. This is not the same as Python's ``async/await``, or the
+ASGI server spec. You must actually use gevent/eventlet in your own code
+to see any benefit to using the workers.
+
+When using either gevent or eventlet, greenlet>=1.0 is required,
+otherwise context locals such as ``request`` will not work as expected.
+When using PyPy, PyPy>=7.3.7 is required.
+
+To use gevent:
+
+.. code-block:: text
+
+    $ gunicorn -k gevent 'hello:create_app()'
+    Starting gunicorn 20.1.0
+    Listening at: http://127.0.0.1:8000 (x)
+    Using worker: gevent
+    Booting worker with pid: x
+
+To use eventlet:
+
+.. code-block:: text
+
+    $ gunicorn -k eventlet 'hello:create_app()'
+    Starting gunicorn 20.1.0
+    Listening at: http://127.0.0.1:8000 (x)
+    Using worker: eventlet
+    Booting worker with pid: x
+
+.. _gevent: https://www.gevent.org/
+.. _eventlet: https://eventlet.net/
--- a/_build/_sources/deploying/index.rst.txt
+++ b/_build/_sources/deploying/index.rst.txt
@ -0,0 +1,79 @@
+Deploying to Production
+=======================
+
+After developing your application, you'll want to make it available
+publicly to other users. When you're developing locally, you're probably
+using the built-in development server, debugger, and reloader. These
+should not be used in production. Instead, you should use a dedicated
+WSGI server or hosting platform, some of which will be described here.
+
+"Production" means "not development", which applies whether you're
+serving your application publicly to millions of users or privately /
+locally to a single user. **Do not use the development server when
+deploying to production. It is intended for use only during local
+development. It is not designed to be particularly secure, stable, or
+efficient.**
+
+Self-Hosted Options
+-------------------
+
+Flask is a WSGI *application*. A WSGI *server* is used to run the
+application, converting incoming HTTP requests to the standard WSGI
+environ, and converting outgoing WSGI responses to HTTP responses.
+
+The primary goal of these docs is to familiarize you with the concepts
+involved in running a WSGI application using a production WSGI server
+and HTTP server. There are many WSGI servers and HTTP servers, with many
+configuration possibilities. The pages below discuss the most common
+servers, and show the basics of running each one. The next section
+discusses platforms that can manage this for you.
+
+.. toctree::
+    :maxdepth: 1
+
+    gunicorn
+    waitress
+    mod_wsgi
+    uwsgi
+    gevent
+    eventlet
+    asgi
+
+WSGI servers have HTTP servers built-in. However, a dedicated HTTP
+server may be safer, more efficient, or more capable. Putting an HTTP
+server in front of the WSGI server is called a "reverse proxy."
+
+.. toctree::
+    :maxdepth: 1
+
+    proxy_fix
+    nginx
+    apache-httpd
+
+This list is not exhaustive, and you should evaluate these and other
+servers based on your application's needs. Different servers will have
+different capabilities, configuration, and support.
+
+
+Hosting Platforms
+-----------------
+
+There are many services available for hosting web applications without
+needing to maintain your own server, networking, domain, etc. Some
+services may have a free tier up to a certain time or bandwidth. Many of
+these services use one of the WSGI servers described above, or a similar
+interface. The links below are for some of the most common platforms,
+which have instructions for Flask, WSGI, or Python.
+
+- `PythonAnywhere <https://help.pythonanywhere.com/pages/Flask/>`_
+- `Google App Engine <https://cloud.google.com/appengine/docs/standard/python3/building-app>`_
+- `Google Cloud Run <https://cloud.google.com/run/docs/quickstarts/build-and-deploy/deploy-python-service>`_
+- `AWS Elastic Beanstalk <https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create-deploy-python-flask.html>`_
+- `Microsoft Azure <https://docs.microsoft.com/en-us/azure/app-service/quickstart-python>`_
+
+This list is not exhaustive, and you should evaluate these and other
+services based on your application's needs. Different services will have
+different capabilities, configuration, pricing, and support.
+
+You'll probably need to :doc:`proxy_fix` when using most hosting
+platforms.
--- a/_build/_sources/deploying/mod_wsgi.rst.txt
+++ b/_build/_sources/deploying/mod_wsgi.rst.txt
@ -0,0 +1,94 @@
+mod_wsgi
+========
+
+`mod_wsgi`_ is a WSGI server integrated with the `Apache httpd`_ server.
+The modern `mod_wsgi-express`_ command makes it easy to configure and
+start the server without needing to write Apache httpd configuration.
+
+*   Tightly integrated with Apache httpd.
+*   Supports Windows directly.
+*   Requires a compiler and the Apache development headers to install.
+*   Does not require a reverse proxy setup.
+
+This page outlines the basics of running mod_wsgi-express, not the more
+complex installation and configuration with httpd. Be sure to read the
+`mod_wsgi-express`_, `mod_wsgi`_, and `Apache httpd`_ documentation to
+understand what features are available.
+
+.. _mod_wsgi-express: https://pypi.org/project/mod-wsgi/
+.. _mod_wsgi: https://modwsgi.readthedocs.io/
+.. _Apache httpd: https://httpd.apache.org/
+
+
+Installing
+----------
+
+Installing mod_wsgi requires a compiler and the Apache server and
+development headers installed. You will get an error if they are not.
+How to install them depends on the OS and package manager that you use.
+
+Create a virtualenv, install your application, then install
+``mod_wsgi``.
+
+.. code-block:: text
+
+    $ cd hello-app
+    $ python -m venv .venv
+    $ . .venv/bin/activate
+    $ pip install .  # install your application
+    $ pip install mod_wsgi
+
+
+Running
+-------
+
+The only argument to ``mod_wsgi-express`` specifies a script containing
+your Flask application, which must be called ``application``. You can
+write a small script to import your app with this name, or to create it
+if using the app factory pattern.
+
+.. code-block:: python
+    :caption: ``wsgi.py``
+
+    from hello import app
+
+    application = app
+
+.. code-block:: python
+    :caption: ``wsgi.py``
+
+    from hello import create_app
+
+    application = create_app()
+
+Now run the ``mod_wsgi-express start-server`` command.
+
+.. code-block:: text
+
+    $ mod_wsgi-express start-server wsgi.py --processes 4
+
+The ``--processes`` option specifies the number of worker processes to
+run; a starting value could be ``CPU * 2``.
+
+Logs for each request aren't show in the terminal. If an error occurs,
+its information is written to the error log file shown when starting the
+server.
+
+
+Binding Externally
+------------------
+
+Unlike the other WSGI servers in these docs, mod_wsgi can be run as
+root to bind to privileged ports like 80 and 443. However, it must be
+configured to drop permissions to a different user and group for the
+worker processes.
+
+For example, if you created a ``hello`` user and group, you should
+install your virtualenv and application as that user, then tell
+mod_wsgi to drop to that user after starting.
+
+.. code-block:: text
+
+    $ sudo /home/hello/.venv/bin/mod_wsgi-express start-server \
+        /home/hello/wsgi.py \
+        --user hello --group hello --port 80 --processes 4
--- a/Show more
+++ b/Show more