Important

This article supports both the v1 and v2 programming model for Python in Azure Functions.The Python v1 model uses afunctions.json file to define functions, and the new v2 model lets you instead use a decorator-based approach. This new approach results in a simpler file structure, and it's more code-centric. Choose thev2 selector at the top of the article to learn about this new programming model.

• Get started
• Scenarios
• Hosting options

Tip

Although you can develop your Python-based Azure functions locally on Windows, Python is supported only on a Linux-based hosting plan when it's running in Azure. For more information, see thelist of supported operating system/runtime combinations.

Azure Functions expects a function to be a stateless method in your Python script that processes input and produces output. By default, the runtime expects the method to be implemented as a global method calledmain() in the__init__.py file. You can alsospecify an alternative entry point.

You bind data to the function from triggers and bindings via method attributes that use thename property that's defined in thefunction.json file. For example, the followingfunction.json file describes a simple function that's triggered by an HTTP request namedreq:

{    "scriptFile": "__init__.py",    "bindings": [        {            "authLevel": "function",            "type": "httpTrigger",            "direction": "in",            "name": "req",            "methods": [                "get",                "post"            ]        },        {            "type": "http",            "direction": "out",            "name": "$return"        }    ]}

Based on this definition, the__init__.py file that contains the function code might look like the following example:

def main(req):    user = req.params.get('user')    return f'Hello, {user}!'

You can also explicitly declare the attribute types and return type in the function by using Python type annotations. Doing so helps you to use the IntelliSense and autocomplete features that are provided by many Python code editors.

import azure.functionsdef main(req: azure.functions.HttpRequest) -> str:    user = req.params.get('user')    return f'Hello, {user}!'

Use the Python annotations that are included in theazure.functions.* package to bind the input and outputs to your methods.

Azure Functions expects a function to be a stateless method in your Python script that processes input and produces output. By default, the runtime expects the method to be implemented as a global method in thefunction_app.py file.

Triggers and bindings can be declared and used in a function in a decorator based approach. They're defined in the same file,function_app.py, as the functions. As an example, the followingfunction_app.py file represents a function trigger by an HTTP request.

@app.function_name(name="HttpTrigger1")@app.route(route="req")def main(req):    user = req.params.get("user")    return f"Hello, {user}!"

You can also explicitly declare the attribute types and return type in the function by using Python type annotations. Doing so helps you use the IntelliSense and autocomplete features that are provided by many Python code editors.

import azure.functions as funcapp = func.FunctionApp()@app.function_name(name="HttpTrigger1")@app.route(route="req")def main(req: func.HttpRequest) -> str:    user = req.params.get("user")    return f"Hello, {user}!"

To learn about known limitations with the v2 model and their workarounds, seeTroubleshoot Python errors in Azure Functions.

You can change the default behavior of a function by optionally specifying thescriptFile andentryPoint properties in thefunction.json file. For example, the followingfunction.json tells the runtime to use thecustomentry() method in themain.py file as the entry point for your Azure function.

{  "scriptFile": "main.py",  "entryPoint": "customentry",  "bindings": [      ...  ]}

The entry point is only in thefunction_app.py file. However, you can reference functions within the project infunction_app.py by usingblueprints or by importing.

The recommended folder structure for a Python functions project looks like the following example:

 <project_root>/ | - .venv/ | - .vscode/ | - my_first_function/ | | - __init__.py | | - function.json | | - example.py | - my_second_function/ | | - __init__.py | | - function.json | - shared_code/ | | - __init__.py | | - my_first_helper_function.py | | - my_second_helper_function.py | - tests/ | | - test_my_second_function.py | - .funcignore | - host.json | - local.settings.json | - requirements.txt | - Dockerfile

The main project folder,<project_root>, can contain the following files:

• local.settings.json: Used to store app settings and connection strings when running locally. This file doesn't get published to Azure. To learn more, seelocal.settings.file.
• requirements.txt: Contains the list of Python packages the system installs when publishing to Azure.
• host.json: Contains configuration options that affect all functions in a function app instance. This file does get published to Azure. Not all options are supported when running locally. To learn more, seehost.json.
• .vscode/: (Optional) Contains the stored Visual Studio Code configuration. To learn more, seeVisual Studio Code settings.
• .venv/: (Optional) Contains a Python virtual environment used by local development.
• Dockerfile: (Optional) Used when publishing your project in acustom container.
• tests/: (Optional) Contains the test cases of your function app.
• .funcignore: (Optional) Declares files that shouldn't get published to Azure. Usually, this file contains.vscode/ to ignore your editor setting,.venv/ to ignore the local Python virtual environment,tests/ to ignore test cases, andlocal.settings.json to prevent local app settings from being published.

Each function has its own code file and binding configuration file,function.json.

The recommended folder structure for a Python functions project looks like the following example:

 <project_root>/ | - .venv/ | - .vscode/ | - function_app.py | - additional_functions.py | - tests/ | | - test_my_function.py | - .funcignore | - host.json | - local.settings.json | - requirements.txt | - Dockerfile

The main project folder,<project_root>, can contain the following files:

• .venv/: (Optional) Contains a Python virtual environment that's used by local development.
• .vscode/: (Optional) Contains the stored Visual Studio Code configuration. To learn more, seeVisual Studio Code settings.
• function_app.py: The default location for all functions and their related triggers and bindings.
• additional_functions.py: (Optional) Any other Python files that contain functions (usually for logical grouping) that are referenced infunction_app.py through blueprints.
• tests/: (Optional) Contains the test cases of your function app.
• .funcignore: (Optional) Declares files that shouldn't get published to Azure. Usually, this file contains.vscode/ to ignore your editor setting,.venv/ to ignore local Python virtual environment,tests/ to ignore test cases, andlocal.settings.json to prevent local app settings being published.
• host.json: Contains configuration options that affect all functions in a function app instance. This file does get published to Azure. Not all options are supported when running locally. To learn more, seehost.json.
• local.settings.json: Used to store app settings and connection strings when it's running locally. This file doesn't get published to Azure. To learn more, seelocal.settings.file.
• requirements.txt: Contains the list of Python packages the system installs when it publishes to Azure.
• Dockerfile: (Optional) Used when publishing your project in acustom container.

Blueprints

The Python v2 programming model introduces the concept ofblueprints. A blueprint is a new class that's instantiated to register functions outside of the core function application. The functions registered in blueprint instances aren't indexed directly by the function runtime. To get these blueprint functions indexed, the function app needs to register the functions from blueprint instances.

Using blueprints provides the following benefits:

• Lets you break up the function app into modular components, which enables you to define functions in multiple Python files and divide them into different components per file.
• Provides extensible public function app interfaces to build and reuse your own APIs.

The following example shows how to use blueprints:

First, in anhttp_blueprint.py file, an HTTP-triggered function is first defined and added to a blueprint object.

import logging import azure.functions as func bp = func.Blueprint() @bp.route(route="default_template") def default_template(req: func.HttpRequest) -> func.HttpResponse:     logging.info('Python HTTP trigger function processed a request.')     name = req.params.get('name')     if not name:         try:             req_body = req.get_json()         except ValueError:             pass         else:             name = req_body.get('name')     if name:         return func.HttpResponse(             f"Hello, {name}. This HTTP-triggered function "             f"executed successfully.")     else:         return func.HttpResponse(             "This HTTP-triggered function executed successfully. "             "Pass a name in the query string or in the request body for a"             " personalized response.",             status_code=200         )

Next, in thefunction_app.py file, the blueprint object is imported and its functions are registered to the function app.

import azure.functions as func from http_blueprint import bpapp = func.FunctionApp() app.register_functions(bp)

Import behavior

You can import modules in your function code by using both absolute and relative references. Based on the previously described folder structure, the following imports work from within the function file<project_root>\my_first_function\__init__.py:

from shared_code import my_first_helper_function #(absolute)

import shared_code.my_second_helper_function #(absolute)

from . import example #(relative)

The following __app__ import and beyond top-level relative import are deprecated, because they're not supported by the static type checker and not supported by Python test frameworks:

from __app__.shared_code import my_first_helper_function #(deprecated __app__ import)

from ..shared_code import my_first_helper_function #(deprecated beyond top-level relative import)

Inputs are divided into two categories in Azure Functions: trigger input and other input. Although they're different in thefunction.json file, their usage is identical in Python code. Connection strings or secrets for trigger and input sources map to values in thelocal.settings.json file when they're running locally, and they map to the application settings when they're running in Azure.

For example, the following code demonstrates the difference between the two inputs:

// function.json{  "scriptFile": "__init__.py",  "bindings": [    {      "name": "req",      "direction": "in",      "type": "httpTrigger",      "authLevel": "anonymous",      "route": "items/{id}"    },    {      "name": "obj",      "direction": "in",      "type": "blob",      "path": "samples/{id}",      "connection": "STORAGE_CONNECTION_STRING"    }  ]}

// local.settings.json{  "IsEncrypted": false,  "Values": {    "FUNCTIONS_WORKER_RUNTIME": "python",    "STORAGE_CONNECTION_STRING": "<AZURE_STORAGE_CONNECTION_STRING>",    "AzureWebJobsStorage": "<azure-storage-connection-string>"  }}

# __init__.pyimport azure.functions as funcimport loggingdef main(req: func.HttpRequest, obj: func.InputStream):    logging.info(f'Python HTTP-triggered function processed: {obj.read()}')

When the function is invoked, the HTTP request is passed to the function asreq. An entry is retrieved from the Azure Blob Storage account based on theID in the route URL and made available asobj in the function body. Here, the specified storage account is the connection string that's found in the<*_CONNECTION_STRING> app setting. For more information, see For more information, seeConnections.

Inputs are divided into two categories in Azure Functions: trigger input and other input. Although they're defined using different decorators, their usage is similar in Python code. Connection strings or secrets for trigger and input sources map to values in thelocal.settings.json file when they're running locally, and they map to the application settings when they're running in Azure.

As an example, the following code demonstrates how to define a Blob Storage input binding:

// local.settings.json{  "IsEncrypted": false,  "Values": {    "FUNCTIONS_WORKER_RUNTIME": "python",    "STORAGE_CONNECTION_STRING": "<AZURE_STORAGE_CONNECTION_STRING>",    "AzureWebJobsStorage": "<azure-storage-connection-string>"  }}

# function_app.pyimport azure.functions as funcimport loggingapp = func.FunctionApp()@app.route(route="req")@app.blob_input(arg_name="obj", path="samples/{id}",                connection="STORAGE_CONNECTION_STRING")def main(req: func.HttpRequest, obj: func.InputStream):    logging.info(f'Python HTTP-triggered function processed: {obj.read()}')

When the function is invoked, the HTTP request is passed to the function asreq. An entry is retrieved from the Azure Blob Storage account based on theID in the route URL and made available asobj in the function body. Here, the specified storage account is the connection string found in the<*_CONNECTION_STRING> app setting. For more information, see For more information, seeConnections.

`> [!IMPORTANT]

Using SDK type bindings requires thePython v2 programming model.

Prerequisites

• Azure Functions runtime version version 4.34, or a later version.
• Python version 3.10, or a latersupported version.

SDK Types

¹ For output scenarios in which you would use an SDK type, you should create and work with SDK clients directly instead of using an output binding.² The Cosmos DB trigger uses theAzure Cosmos DB change feed and exposes change feed items as JSON-serializable types. The absence of SDK types is by-design for this scenario.

Output can be expressed both in return value and output parameters. If there's only one output, we recommend using the return value. For multiple outputs, you must use output parameters.

To use the return value of a function as the value of an output binding, thename property of the binding should be set to$return in thefunction.json file.

To produce multiple outputs, use theset() method provided by theazure.functions.Out interface to assign a value to the binding. For example, the following function can push a message to a queue and also return an HTTP response.

{  "scriptFile": "__init__.py",  "bindings": [    {      "name": "req",      "direction": "in",      "type": "httpTrigger",      "authLevel": "anonymous"    },    {      "name": "msg",      "direction": "out",      "type": "queue",      "queueName": "outqueue",      "connection": "STORAGE_CONNECTION_STRING"    },    {      "name": "$return",      "direction": "out",      "type": "http"    }  ]}

import azure.functions as funcdef main(req: func.HttpRequest,         msg: func.Out[func.QueueMessage]) -> str:    message = req.params.get('body')    msg.set(message)    return message

Output can be expressed both in return value and output parameters. If there's only one output, we recommend using the return value. For multiple outputs, you'll have to use output parameters.

To produce multiple outputs, use theset() method provided by theazure.functions.Out interface to assign a value to the binding. For example, the following function can push a message to a queue and also return an HTTP response.

# function_app.pyimport azure.functions as funcapp = func.FunctionApp()@app.write_blob(arg_name="msg", path="output-container/{name}",                connection="CONNECTION_STRING")def test_function(req: func.HttpRequest,                  msg: func.Out[str]) -> str:    message = req.params.get('body')    msg.set(message)    return message

Note

To use the OpenCensus Python extensions, you need to enablePython worker extensions in your function app by settingPYTHON_ENABLE_WORKER_EXTENSIONS to1. You also need to switch to using the Application Insights connection string by adding theAPPLICATIONINSIGHTS_CONNECTION_STRING setting to yourapplication settings, if it's not already there.

The HTTP trigger is defined in thefunction.json file. Thename of the binding must match the named parameter in the function.In the previous examples, a binding namereq is used. This parameter is anHttpRequest object, and anHttpResponse object is returned.

From theHttpRequest object, you can get request headers, query parameters, route parameters, and the message body.

The following example is from theHTTP trigger template for Python.

def main(req: func.HttpRequest) -> func.HttpResponse:    headers = {"my-http-header": "some-value"}    name = req.params.get('name')    if not name:        try:            req_body = req.get_json()        except ValueError:            pass        else:            name = req_body.get('name')    if name:        return func.HttpResponse(f"Hello {name}!", headers=headers)    else:        return func.HttpResponse(             "Please pass a name on the query string or in the request body",             headers=headers, status_code=400        )

In this function, you obtain the value of thename query parameter from theparams parameter of theHttpRequest object. You read the JSON-encoded message body by using theget_json method.

Likewise, you can set thestatus_code andheaders for the response message in the returnedHttpResponse object.

The HTTP trigger is defined as a method that takes a named binding parameter, which is anHttpRequest object, and returns anHttpResponse object. You apply thefunction_name decorator to the method to define the function name, while the HTTP endpoint is set by applying theroute decorator.

This example is from the HTTP trigger template for the Python v2 programming model, where the binding parameter name isreq. It's the sample code that's provided when you create a function by using Azure Functions Core Tools or Visual Studio Code.

@app.function_name(name="HttpTrigger1")@app.route(route="hello")def test_function(req: func.HttpRequest) -> func.HttpResponse:     logging.info('Python HTTP trigger function processed a request.')     name = req.params.get('name')     if not name:        try:            req_body = req.get_json()        except ValueError:            pass        else:            name = req_body.get('name')     if name:        return func.HttpResponse(f"Hello, {name}. This HTTP-triggered function executed successfully.")     else:        return func.HttpResponse(             "This HTTP-triggered function executed successfully. Pass a name in the query string or in the request body for a personalized response.",             status_code=200        )

From theHttpRequest object, you can get request headers, query parameters, route parameters, and the message body. In this function, you obtain the value of thename query parameter from theparams parameter of theHttpRequest object. You read the JSON-encoded message body by using theget_json method.

Likewise, you can set thestatus_code andheaders for the response message in the returnedHttpResponse object.

To pass in a name in this example, paste the URL that's provided when you're running the function, and then append it with"?name={name}".

You can use Web Server Gateway Interface (WSGI)-compatible and Asynchronous Server Gateway Interface (ASGI)-compatible frameworks, such as Flask and FastAPI, with your HTTP-triggered Python functions. This section shows how to modify your functions to support these frameworks.

First, thefunction.json file must be updated to include aroute in the HTTP trigger, as shown in the following example:

{  "scriptFile": "__init__.py",  "bindings": [    {       "authLevel": "anonymous",       "type": "httpTrigger",       "direction": "in",       "name": "req",       "methods": [           "get",           "post"       ],       "route": "{*route}"    },    {       "type": "http",       "direction": "out",       "name": "$return"    }  ]}

Thehost.json file must also be updated to include an HTTProutePrefix, as shown in the following example:

{  "version": "2.0",  "logging":   {    "applicationInsights":     {      "samplingSettings":       {        "isEnabled": true,        "excludedTypes": "Request"      }    }  },  "extensionBundle":   {    "id": "Microsoft.Azure.Functions.ExtensionBundle",    "version": "[4.*, 5.0.0)"  },  "extensions":   {    "http":     {        "routePrefix": ""    }  }}

Update the Python code fileinit.py, depending on the interface that's used by your framework. The following example shows either an ASGI handler approach or a WSGI wrapper approach for Flask:

app = fastapi.FastAPI()@app.get("hello/{name}")async def get_name(name: str):  return {"name": name}def main(req: func.HttpRequest, context: func.Context) -> func.HttpResponse:    return func.AsgiMiddleware(app).handle(req, context)

app = Flask("Test")@app.route("hello/<name>", methods=["GET"])def hello(name: str):    return f"hello {name}"def main(req: func.HttpRequest, context) -> func.HttpResponse:  logging.info("Python HTTP trigger function processed a request.")  return func.WsgiMiddleware(app).handle(req, context)

You can use Asynchronous Server Gateway Interface (ASGI)-compatible and Web Server Gateway Interface (WSGI)-compatible frameworks, such as Flask and FastAPI, with your HTTP-triggered Python functions. You must first update thehost.json file to include an HTTProutePrefix, as shown in the following example:

{  "version": "2.0",  "logging":   {    "applicationInsights":     {      "samplingSettings":       {        "isEnabled": true,        "excludedTypes": "Request"      }    }  },  "extensionBundle":   {    "id": "Microsoft.Azure.Functions.ExtensionBundle",    "version": "[4.*, 5.0.0)"  },  "extensions":   {    "http":     {        "routePrefix": ""    }  }}

The framework code looks like the following example:

# function_app.pyimport azure.functions as func from fastapi import FastAPI, Request, Response fast_app = FastAPI() @fast_app.get("/return_http_no_body") async def return_http_no_body():     return Response(content="", media_type="text/plain") app = func.AsgiFunctionApp(app=fast_app,                            http_auth_level=func.AuthLevel.ANONYMOUS)

# function_app.pyimport azure.functions as func from flask import Flask, Response flask_app = Flask(__name__) @flask_app.get("/return_http") def return_http():     return Response("<h1>Hello World™</h1>", mimetype="text/html") app = func.WsgiFunctionApp(app=flask_app.wsgi_app,                            http_auth_level=func.AuthLevel.ANONYMOUS)

In Azure Functions,application settings, such as service connection strings, are exposed as environment variables when they're running. There are two main ways to access these settings in your code.

Both of these ways require you to declareimport os.

The following example usesos.environ["myAppSetting"] to get theapplication setting, with the key namedmyAppSetting:

import loggingimport osimport azure.functions as funcdef main(req: func.HttpRequest) -> func.HttpResponse:  # Get the setting named 'myAppSetting'  my_app_setting_value = os.environ["myAppSetting"]  logging.info(f'My app setting value:{my_app_setting_value}')

For local development, application settings aremaintained in thelocal.settings.json file.

In Azure Functions,application settings, such as service connection strings, are exposed as environment variables when they're running. There are two main ways to access these settings in your code.

Both of these ways require you to declareimport os.

The following example usesos.environ["myAppSetting"] to get theapplication setting, with the key namedmyAppSetting:

import loggingimport osimport azure.functions as funcapp = func.FunctionApp()@app.function_name(name="HttpTrigger1")@app.route(route="req")def main(req: func.HttpRequest) -> func.HttpResponse:  # Get the setting named 'myAppSetting'  my_app_setting_value = os.environ["myAppSetting"]  logging.info(f'My app setting value:{my_app_setting_value}')

For local development, application settings aremaintained in thelocal.settings.json file.

First, create a<project_root>/my_second_function/function.json file, and then define this function as an HTTP trigger.

{  "scriptFile": "__init__.py",  "entryPoint": "main",  "bindings": [    {      "authLevel": "function",      "type": "httpTrigger",      "direction": "in",      "name": "req",      "methods": [        "get",        "post"      ]    },    {      "type": "http",      "direction": "out",      "name": "$return"    }  ]}

Next, you can implementmy_second_function andshared_code.my_second_helper_function.

# <project_root>/my_second_function/__init__.pyimport azure.functions as funcimport logging# Use absolute import to resolve shared_code modulesfrom shared_code import my_second_helper_function# Define an HTTP trigger that accepts the ?value=<int> query parameter# Double the value and return the result in HttpResponsedef main(req: func.HttpRequest) -> func.HttpResponse:  logging.info('Executing my_second_function.')  initial_value: int = int(req.params.get('value'))  doubled_value: int = my_second_helper_function.double(initial_value)  return func.HttpResponse(    body=f"{initial_value} * 2 = {doubled_value}",    status_code=200    )

# <project_root>/shared_code/__init__.py# Empty __init__.py file marks shared_code folder as a Python package

# <project_root>/shared_code/my_second_helper_function.pydef double(value: int) -> int:  return value * 2

You can start writing test cases for your HTTP trigger.

# <project_root>/tests/test_my_second_function.pyimport unittestimport azure.functions as funcfrom my_second_function import mainclass TestFunction(unittest.TestCase):  def test_my_second_function(self):    # Construct a mock HTTP request.    req = func.HttpRequest(method='GET',                           body=None,                           url='/api/my_second_function',                           params={'value': '21'})    # Call the function.    resp = main(req)    # Check the output.    self.assertEqual(resp.get_body(), b'21 * 2 = 42',)

Inside your.venv Python virtual environment folder, install your favorite Python test framework, such aspip install pytest. Then runpytest tests to check the test result.

First, create the<project_root>/function_app.py file and implement themy_second_function function as the HTTP trigger andshared_code.my_second_helper_function.

# <project_root>/function_app.pyimport azure.functions as funcimport logging# Use absolute import to resolve shared_code modulesfrom shared_code import my_second_helper_functionapp = func.FunctionApp()# Define the HTTP trigger that accepts the ?value=<int> query parameter# Double the value and return the result in HttpResponse@app.function_name(name="my_second_function")@app.route(route="hello")def main(req: func.HttpRequest) -> func.HttpResponse:    logging.info('Executing my_second_function.')    initial_value: int = int(req.params.get('value'))    doubled_value: int = my_second_helper_function.double(initial_value)    return func.HttpResponse(        body=f"{initial_value} * 2 = {doubled_value}",        status_code=200    )

# <project_root>/shared_code/__init__.py# Empty __init__.py file marks shared_code folder as a Python package

# <project_root>/shared_code/my_second_helper_function.pydef double(value: int) -> int:  return value * 2

You can start writing test cases for your HTTP trigger.

# <project_root>/tests/test_my_second_function.pyimport unittestimport azure.functions as funcfrom function_app import mainclass TestFunction(unittest.TestCase):  def test_my_second_function(self):    # Construct a mock HTTP request.    req = func.HttpRequest(method='GET',                           body=None,                           url='/api/my_second_function',                           params={'value': '21'})    # Call the function.    func_call = main.build().get_user_function()    resp = func_call(req)    # Check the output.    self.assertEqual(        resp.get_body(),        b'21 * 2 = 42',    )

Inside your.venv Python virtual environment folder, install your favorite Python test framework, such aspip install pytest. Then runpytest tests to check the test result.

Unit testing by invoking the function directly

Withazure-functions >= 1.21.0, functions can also be called directly using the Python interpreter. This example shows how to unit test an HTTP trigger using the v2 programming model:

# <project_root>/function_app.pyimport azure.functions as funcimport loggingapp = func.FunctionApp(http_auth_level=func.AuthLevel.ANONYMOUS)@app.route(route="http_trigger")def http_trigger(req: func.HttpRequest) -> func.HttpResponse:    return "Hello, World!"print(http_trigger(None))

Note that with this approach, no additional package or setup is required. The function can be tested by callingpython function_app.py, and it results inHello, World! output in the terminal.

Important

Files written to the temporary directory aren't guaranteed to persist across invocations. During scale out, temporary files aren't shared between instances.

Note

If your function app'srequirements.txt file contains anazure-functions-worker entry, remove it. The functions worker is automatically managed by the Azure Functions platform, and we regularly update it with new features and bug fixes. Manually installing an old version of worker in therequirements.txt file might cause unexpected issues.

Note

If your package contains certain libraries that might collide with worker's dependencies (for example, protobuf, tensorflow, or grpcio), configurePYTHON_ISOLATE_WORKER_DEPENDENCIES to1 in app settings to prevent your application from referring to worker's dependencies.

Important

Third-party Python worker extension libraries aren't supported or warrantied by Microsoft. You must make sure that any extensions that you use in your function app is trustworthy, and you bear the full risk of using a malicious or poorly written extension.

• Application-level
• Function-level

# <project_root>/requirements.txtapplication-level-extension==1.0.0

# <project_root>/Trigger/__init__.pyfrom application_level_extension import AppExtensionAppExtension.configure(key=value)def main(req, context):  # Use context.app_ext_attributes here

# <project_root>/requirements.txtfunction-level-extension==1.0.0

# <project_root>/Trigger/__init__.pyfrom function_level_extension import FuncExtensionfunc_ext_instance = FuncExtension(__file__)def main(req, context):  # Use func_ext_instance.attributes here